Scenario
I am working on a multitenant solution in yii2 following the Multi-Tenant Strategy walkthrough.
Currently, I have separated concerns for the tenants. Let's call tenants "organizations". Organizations are able to view only their data.
I am currently trying to make a signup for users under organizations. In order for the user to signup under an organization, normally, it would have to select which organization it's signing up under. If I use a dropdown, this would mean every incoming user would know all organizations using this solution which I do not want.
Question
How do I make a user signup under his/her organization automatically without having to select the organization?
What do I need to put in place to achieve this?
What I tried
Using a dropdown to select the organization: I dropped this idea for reasons listed above
Having each organization use a give a code to their users. This would work for the organization's employees, not for the organizations clients as they cannot possibly know all their clients beforehand.
I have based my multi-tenant application on the fact that tenancy selective element are associated to the user.
In my case during the sign-on phase an administrator assign which organisation ( or organisations) are available for this user..
Then if the user is assigned at one only organisation the multi-tenancy configuration is directly assigned by application otherwise, if the user is related to more organisations, after login in a combo are provided only the proper organisations for the user.
In the case of client organisation tipically is provided a sign-in for each organisation or a subsequent invite by admin or by app to access to other organisation .. depending of the kind or organisation are related to the client
Related
I have done a lot of reading on this but nothing stands out. I already have a authentication and authorisation system that can handle multiple guards and user roles (user, admin, super admin etc.)
I am trying to find out what is the best way to separate the system into totally separate accounts which have the following;
No login section
Landing page. Anyone can see without login.
Admin Section
Admin side of the system has a super-admins and then multiple admin-users.
These users can see all data from every user who has an account on the client side.
Client Section
Each user account has an owner who deals with billing, their own user admin etc.
Each client account also has a number of users (admin-users, editor-users etc.) with varying permissions.
Users on this side should only ever be able to see their own accounts data. They should not be able to ever see other accounts data.
Before Laravel, I would have an accounts table and assign a unique key to each account. Then a separate users table would contain the user along with their account key.
All database tables from this point onwards (posts, products, shipments etc.) would also have this key to ensure that the user account could only see their own data.
On top of this there would be permission tables, for granular control of what each user from either side can see.
Is my original way still suited to Laravel or is there a better way?
To separate out the accounts into their own "ecosystems" within the same code base is called multi tenancy. Basically, you scope your applications queries based on the user id and/or role which limits the available data to any given user.
Have a look at the Landlord Package.
In a very basic summary, what it does is add a where('tenant_id, auth()->id()) clause to every applicable query.
You can of course either omit the clause entirely for super admins to access all data, or apply even tighter constraints, say by adding a check for the user's role in addition to the clause, further limiting what a user can access within their respective account/organization/group etc.
Scoping can be done by any kind of relationship, you're not necessarily limited to the authenticated user's id. If your application has organizations for multiple user's you can use the organization id.
Multiple tenant ids is also possible, where a user must belong to an organization and a certain division within that organization.
Another package I've used previously is Hyn's multi-tenant.
We have same project as you mention . We create a company table and put it on the top of the hierarchy.
Then add new field all tables as company_id
And manage models over Policy -> https://laravel.com/docs/5.8/authorization
I hope this help
I am quite new to Laravel, but get most of the basics by now.
Currently, I build an application, where multiple companies each get an account that represents their main user, let's call him CompanyAdmin.
This user is allowed to create new users for this company and able to view all quotes from the company.
The newly created users, call them CompanyEmployee, can not create new users and only view the quotes they created themselves, as well as creating new quotes.
Now there is of course one SuperAdmin, which sits on the other side of the table. He views all quotes from all companies, is able to do create users as he pleases and can accept/edit quotes.
My current approach to do this would be to attach a user_id to all quotes and attach the users to a company, as well as giving them a role.
All the logic would take place in the controller, where I would check the role of the user and therefore read/save only the quotes, the user is able to edit.
However, it feels very dirty to do so and sounds like a lot of effort to maintain. If you would e.g. make another role for an employee of the SuperAdmin, you would need to change every controller.
I could not find a way to define the access rights per role per model, so when I call Quotes::all() it only retrieves the legal ones (same goes for saving of course).
Please guide me to a Laravel feature (or even package, but I have not used one before) that helps me get things done.
Looking forward to possible solutions that lead to low maintainance.
Best regards!
For authenticating different types of users and protecting group of routes that particular type can access you can use guards, for authorizing CRUD actions you can use FormRequest, I think you have everything you need under these 2 links, ofcourse you will need to read up on these, this is a good starting point. As for tables, you can have these:
users, roles, companies, user_role, user_company
And models:
User, Role, Company
from the doc
In addition to providing authentication services out of the box,
Laravel also provides a simple way to authorize user actions against a
given resource. Like authentication, Laravel's approach to
authorization is simple, and there are two primary ways of authorizing
actions: gates and policies.
Laravel has 2 concepts called Gates and Policies which we can inject it on models,(specially Gates), So when ever the queries are called upon the Model, the Gates make sure that the user has appropriate permissions.
You can read more here
I'm working on a project in Laravel for learning the framework.
I create a basic register/login and after that I customize the register part.
What am I planning to achieve is the point where an user can act in multiple roles.
For example:
user1 can be normal user and administrator(with special access to the application) at the same time.
How should I design this from database point of view ?
Personally, I wouldn't create another "user" type entity for companies, but add another table for company data and connect it to a user. That way you are able to keep the default registration and login process.
If you wanted a slightly different form to register companies, I'd add another route & form to gather the "user" information as well as "company" information (company name, phone, fax, etc). Then when the registration is processed you can create the user entity, along with the company relationship with the given information.
However, if you still wanted to create completely different entities with login/registration flows, you'd have to build your own User Providers and implement the contracts needed.
Some basics:
I am using a user authenticated login to an admin system that allows users to add customers, and an array of info about customers, including geo-location information for use with GMap API. My goal is to allow users to add each other for networking purposes in regards to their customer clientele. I am wondering what the best approach at building the database/table structure should be.
At the moment, I have a database called pbud1 with a users table and a customers table. For networking, my idea is to use the users unique id-> uid as an identifier for their network. Then add a table when a network is instantiated by the user, naming the table network_+the id from their 'users' table, ex: network_uid where pbud1.network_uid = pbud1.users.uid. So if the user has an id of 6 it would be network_6. Then within the new table "network_6", place relevant information on each row about each user that is added to that users network, ie; nid(key/ai) net_user_id(uid), geo_location, business, name, etc...
Goal: Allow each user within their parent network to access that specific user.parent customers information. Suggest users to user.parent due to geo_location of customer base between related users.
Honestly the semantics are not so important here as the structure and build of the DB table relationship in regards to the ability for networked users to access each others customers information.
Any assistance on approach would be greatly appreciated!
hi im trying to grasp cake(been thrown in to the deep end, without much help and tutorials seem to be a little scarce)
My question is we have three different types of users - business, businessUser, individual, we have created a table,model and controller for each three of the users. Is it possible to create one login page when using three types of controllers or do we need to combine everything into one controller and go from there?
sorry for such a beginner question but at this point I'm getting kind of desperate.
business - has many businessusers btw
Sounds like your models need a bit of tweeking. I'd suggest the following schema:
users table (User model)
- Contains information shared by all user types (name, password, etc.)
business table (Business model)
- Contains information unique to a business
business_users (BusinessUser)
- Contains information unique to a business user
individuals (Individual)
- Contains information unique to an individual (can this be combined with the User model?)
Now, you can link them up like this:
User hasOne Business
User hasOne BusinessUser
User hasOne Individual
Business belongsTo User
BusinessUser belongsTo User
Individual belongsToUse
A business would be defined as a User with an associate Business model, etc.
You could create three separate logins, if they are three completely different systems that will never share data or need to interact.
But it would probably be a better idea to rework your thinking.
User hasMany UserGroups.
UserGroup - id, role (e.g. BusinessUser, Individual). This approach allows you to extend should you ever need to without creating new controllers for different roles. It does depend really on what you are trying to achieve with these "user groups".
Handle the login in your user controller, and then depending on the user group, control access accordingly.
Or even just give the user a role, and again, depending on role, control access.
The cookbook offers a similar example