I am working on an admin dashboard for 5 services using Laravel. It is really complicated to do so in admin. We, for example, want to show a list of transactions with user name for each row. Both of the users and transactions tables are in different databases. We had to make another request to fetch the user name form the other service.
I am wondering about when it comes to statistics and writing complex queries to get data from all of theses services in a report. How can I handle such a case?
Can I make multiple connections to the databases with the admin dashboard project?
Is there any available pattern that facilitate the work for me?
Thanks
Related
Please help me as I'm new to REST API, ASP.NET MVC and developing an application from scratch. I have a requirement from client to build a ASP.NET WEB API application with SQL Server database. I'm new to development so I need help on the queries raised by my client.
The application will have 3 groups of users: admin users, group 1 users and group 2 users. Since each of these groups will have different functionalities, the database tables are also going to be different for each group.
The query raised by my client is that group 1 users should not be able to access the tables of group 2 users and vice-versa even from outside the application.
I know at the application level, we can use an [Authorize] attribute in REST API calls so that access to each request is authenticated.
Apart from this, can we do anything at the database level so that users who know the database name, login will not be able to access 100's of SQL Server tables which they don't have to deal with by any other means. The connection string used in application will be having a login which will be using SQL Server authentication mode. Can multiple connection strings in my application be a solution to deal with this scenario?
Let's assume below scenario.
There can be multiple tenants. Each tenant offers different services based on their business to clients. Depending on the size of the client, they may have their own database as well (ex:- Large clients prefer their data to be isolated).
Arranging tenants to fulfill above scenario is possible with the AspNetBoilerplate out of the box.
Then comes the customers who consumes various services provided by multiple businesses (tenants). There is a single mobile app for these customers. Once they login, they should be able to get services from any tenant unless a tenant has blocked a user.
Note that the point here is these customers are NOT registering for each tenant separately.
What are my options to get this setup done properly using AspNetBoilerplate? My initial thoughts are;
1) Have a separate table - MyCustomers - All mobile users will get authenticated against this table. For this should i create a separate auth pipeline ?
2) Current AspNetBoilerplate demo; you choose the tenant and login. But in my case; they log in and they will choose a service provider (tenant). At this point;
Should I create a new user automatically IF the selected tenant is in a different database (For large businesses having their own database)?
If the selected service provider is a small customer, who are in the same database differentiated with a TenantId I will have to additionally have a --> (many) relationship maintained so when a new service is selected a new record goes to this table?
At the end of the day, MyCustomers will only be using a single mobile app to get any service from any business after they login. Once they login, they should have access to all tenants (unless they are blocked).
Is there a better way to do this using AspNetBoilerplate existing architecture?
I am using ASP.NET Boilerplate for its multi-tenancy support. When a user log in, I would like to present to the user the list of tenants it has access to. For instance, if a user with email admin#example.com is part of Tenant-A and Tenant-B, would like to offer the choice to switch between tenants.
This does not seem to be easily doable. Each user can be mapped to a single Tenant (AbpUsers table).
What would be the best way to allow a user to access multiple tenants? The only way I think this can be done is by adding a N:M table between User and Tenant, but then will ABP allow me to do context switching between tenants?
By design, tenant data (including users, roles...) are completely isolated from each other and can not be shared easily.
We solved this issue with "Account linking" feature in AspNet Zero. With this feature, you can connect your accounts in different tenants and then switch between accounts with a single click. It basically maps those accounts (users) in database and logs out & logs in automatically when you want to switch. See more info: https://aspnetzero.com/Documents/Development-Guide-Core#user-menu
I have just developped a Human Ressource WebApp in Laravel.
So in this app, I have my user database.
Now, I have 2 old apps, that I'm about to rewrite / Migrate to Laravel.
The first one is to manage employee payments.
The second app is for monitoring my salesforce in field.
So, Basically, I will basically rewrite them.
My Question is about architecture. I will develop those 2 apps separating APIs in Lumen / Laravel for each app, individually, and then writing clients in Angular2.
I will use OAuth2.0 to set authorization and scopes between apps.
Now, My indecision resides on Database part.
Should I keep database separated, include database in the same schema, or how should I deal with my databases.
Today, I have 1 DB per app, but also, I have redundancy in users: Each App works with the same users, and so duplicate this info.
Right now, When User is created in App1, it calls APIs to create it in app2 and app3. This is not so nice, IMHO.
So, I think I would like to have a single User Database, but I don't really have experience of that:
should I extract User's info in a central database for all users, should
should I keep User's info duplicated between my DB?
if I keep it in 3 differents DB, how should I make JOINs, transactions, Foreign Keys, etc.
I know there is not 1 answer, it depends of what I want, but this is also my problem, I don't know which question should I be asking to make my decision???
It is important to mention that I don't have so much traffic, max 1000 users, and they all belongs to my enterprise, it will not increase to much. So, really, make a scallable app should not be my priority right now.
Any Advice will be appreciated!!!
Since you have shared databases between your apps, the common practice is to have it in the same Laravel/Lumen app.
The way you can achieve this is separating the apps inside route groups, namespacing the controllers hierarchies of each app and declaring inside each model the connection you will be using for this model.
This way you can use the same DB connections for all of your apps, and share the same data without the need of duplicating it.
I'm evaluating CRM 2011 to replace an existing app and and have some questions about security and segregating information by Client (or Account).
I have a custom entity for 'Client'. There are lot of custom entities that are related to 'Client' which consitute the data needed to be captured.
I would like to limit specific teams/users to work on specific clients and see only the data for those clients that they have access to.
I'm seeing that individual entities can be assigned to teams/users but I need all related entities to be locked down by Client so that regular users
Dont see records in views or searches that belong to other clients.
Can't create or access records for other clients.
Can this be done in CRM 2011? How?
Also - is it possible to limit processes/workflows to operate or trigger on records of specific clients only?
Probably the easiest thing to do would be do base your security on business units. Groups of clients an their related records would all be in the same business unit, and as long as you set their security roles to only allow access to records in their own business unit, that would work.
For workflows that only trigger on particular clients, it depends on the exact requirements. You could certainly check the business unit of the client as the first step in the workflow and continue or exit based on that. If it's something more complex, you can write a custom workflow assembly to do the check for you.