So, I am fairly new to Laravel and cannot figure out the best way to establish this relationship. I have created a restaurant management system, and successfully created a login system with certain roles. Users can have the four roles: Admin, Waiter, Cashier and General.
Admin can access most of the system, waiter and cashier certain parts and "General" users only the timesheet module. This works, however I want the admin to be able to view its employees.
The problem is that I want the admin to be able to create Employees without the requirement for a user account on the system, but I also want that every User account is automatically either an Admin (Admin role) or Employee (Waiter, Cashier and General).
So basically every user is either an Employee or Admin, but every Employee does not have to be a User. And then I want to connect my Timesheet Module to the Employee Module, instead of the User module.
If I'm doing this in a very complicated way and you know something better, please let me know. Or otherwise post a solution :-)
Hi roles can apply in two different ways. A role can be an authentication method and it could be a type of employee.
It all depends on what you are planning to do with an employee. I believe that you need to sort that out first. Since Roles mostly are defining access to an App, because they have a relationship to Abillities/Permissions.
Connecting you timesheet to the Employee is a correct step. Since Employees do not always need to logon. But it needs to be plannable.
So the timesheet would be timeable_type with a timeable_id. I would do the following, i would create a EmployeeType::class containing the types: Weighter, Cashier, General. And the timesheet table i would use the following.
employee_id since the timesheet belongs to an employee
and employee_type_id since you want to be able to differentiate the type of employee.
you could even do a morphable relation ship for even more flexibillity
So the User::class had the abilities(permissions) and is an active user in your app.
The Employee::class does not have abilities but is an administrative value in your app. So an employee basically can only logon when it has a User::class
So the employee belongs to the User so the employee has a belongs to relation to the user.
and the user hasOne relation to the employee
Related
I am in the process of designing a Blazor Server app that sits on top of a single MSSQL db.
I have done a fair amount of research and learning on the subject but I am still very new to Core Identity, so I need to better understand how it is meant to be used so that I can properly design the Authentication and Authorization pieces.
The app will consist of organizations. Users can belong to one or more organizations and within each organization, can belong to one of two roles: Coach or Student. But the Coach in one organization could be a student in another organization, and a student could be a student of more than one organization. But all of this should be tied to a single user account/login. If a user belongs to more than one organization, they will be presented with a screen to select which organization they want to access after completing the login process. Once they have selected the organization, their activity and access will be limited to that organization.
What would be the proper way to handle this type of arrangement? Since one user could be a coach in one org and a student in another, are roles the proper way to handle that? Or would those be claims where for example I would store the ID of the organization as the value of a claim called "Coach" or "Student"? Or some other way?
Initially, I was planning to only use Identity for Authentication and then use my own custom logic to perform Authorization based on these criteria, but I don't want to reinvent the wheel if I don't have to.
Thanks in advance for your guidance and recommendations on this.
I'm trying to analyse FusionAuth as possible Identity manager for our current solution.
Our current solution is deployed at customer premisses or cloud, and helps them manage their processes (with their company users).
Our current solution is in early-transformation for micro-service solution, and we're trying to extract the user + authentication flow first. We thought maybe using some JWT solution for authentication could be a thing.
We have the use case that companies may have different root-level departments, and an user may belong to more than one department (or its children departments)
How currently is solved, is that at login time if such an user is making the login then it has to choose which root-level department he wants to login into.
We would expect that our new solution with JWT would contain such high-level department on the token information
Users logged-in for a root-level department can't access all data from other departments (only some base data)
I'm trying to understand if such use case could be acomplished by tenants / applications / groups, but I don't see how the same user could belong to many of them and have the possibility to choose one of them at login time
Would anyone suggest an approach to the problem, and if Fusion Auth could solve it?
Also some of our customers do use LDAP, and ask us to integrate the login through their AD (we make the login with AD, and import / synchronize the users). I've seen an open issue for AD integration, but not sure if that is going to be adopted?
One way to handle this is to present the user with a Department Select Screen prior to sending them to FusionAuth. This screen would list out the Departments and the user would select one. Once they select the Department, they would be redirected to FusionAuth's OAuth where the Department is the client_id. This also means that you need a FusionAuth Application for each Department.
Once the user has logged into FusionAuth, the JWT that FusionAuth creates will contain the Application id. This will allow you to identify the Department that they logged into.
I have three roles: admin, instructor (combination of teacher and course creator) and student.
I created a child theme based from clean theme. In my child theme, I customize the layout of the login page. In my login page, there are three buttons: Login as Admin, Login as Instructor and Login as Student.
How can I force the login to be as specific role? I did check out the /login/index.php but I'm having a hard time understanding the flow of the login process.
For an additional info, the dashboard content and design depends on what role the user logged in.
First, San is wrong. There are very much global roles in Moodle. You can access these under:
Site Administration -> Users -> Permissions -> Assign system roles
Second, you talk about 'forcing' a role when you login. This makes no sense in Moodle terms. This is how Moodle works:
Create a user.
Assign them a system role (by default they will be under the role 'All Users')
Login as that user and they will have that role.
Why bother creating three different login buttons? All you need to do is create three accounts, each with different login details, and assign them each a separate role.
If this does not answer your question please give me more details on what you are trying to achieve?
First, there is no global role in Moodle for any user.
User roles are assigned to course level in Moodle.
For dashboard content and design you can check user course level role and show data as per user role.
If a user is a student in any course then, I consider it as a student and show data related to a student only for a course in which user is a student.
I am facing a problem trying to develop an application in Yii (v=1.1). Client wants the application to has multiple databases (one per his customer). That means that we will have unknown number of databases. Also He wants to have only one user authentication system - regard of it, users would have the choise (and the privilleges) to belong in many databases. So I am considering about the way which it could be developed.
Do you have faced something like this?
Well you should first better define your goal because it is not that clear to me what you want to accomplish, but how I see it.
Decide where you want to store the users:
Should the same user be able to connect using the same login info to two different customer databases?
Do you need to manage all users of all customers from one single place?
You could have the following situations:
Store users only in one common database, not in customer databases:
when logging in tell Yii to use the "common" database for the User model
you could have also a common application that handles user management
you could also provide the customer with the possibility to manage his own users
you could either have a "customer" field in the Users table to indicate to what customer it belongs, or you could have a "users_customers" table and after the login screen prompt the user with a "choose customer" screen, so one unique User can login to multiple Customers
Store users only in the customer databases:
if you don't need for a common place to manage users, or don't need to share them between customers, simply have a User table in every Customer database, this way user "alex" could exist in both databases with different login information
here you could simply add another field in the Login form (yes I've saw one application that does it) for example instead of Username and Password fields, ask for "Office, Username and Password", and the Office would be the name of the Customer database. Or you could even use only Username field and force users to enter something such as "alex#office" as Username, then you split that by "#" and you know to what office it belongs.
then simply use that information both on Login screen and on session to tell Yii what customer database to connect to
So as you see it could be done in different ways. Once you choose your way, you would need a implementation.
If you don't know how to do the implementation maybe I could provide more technical information related to Yii.
I'm working on a site, which will have several modules that either fully available to certain users, semi available to other users, and unavailable to the rest.
For example:
An 'employee' is able to respond to the customer support tickets assigned to him.
A 'Manager' is able to manage all employees and support tickets in his team, including viewing the tickets of a specific employee.
An 'Admin' is able to manage all managers, employees, and tickets in all teams, as well as some other core functionality.
In addition, on some pages there will be some additional fields shown if the current user is an admin or manager. (E.g links to delete/flag things). These won't be shown to employees.
I want to create one 'Permissions' model which will handle the logic for:
Determining if a user can access the current page or not.
Determining whether a particular part of a page should be displayed or not. (E.g special links for editing/deleting to be shown to admins and managers only).
I need some recommendations/advice for designing this class, particularly what methods it should have in order to accomplish the 2nd requirement.
The way I have approached this problem when it has come up is to give each action that can be taken or piece of information that can be shown it's own Permission. Each User then has a collection of Permissions. From this, you can add other layers of structure to help manage the huge number of permissions that will exist, such as hierarchies or categories of permissions.
Once that is in place, you can either have the various parts ask the User if they have the needed permission(s), or you can have a PermissionManager take a User and a set of Permissions and determine if the given user has the needed Permissions. Either way will work fine, but which one you choose has an impact on dependencies and the architecture of your system.
The PermissionManager approach has the advantage that your application pieces don't need to depend on a User, so you could use a different PermissionManager that always returns False if no permissions is appropriate, or True if all permissions is appropriate.
For simple situations, this approach can be overkill, and it often seems like it is at first, but I've gone the route of using basic hierarchical or coarse-grained Roles and fond that virtually every system I've worked on quickly got too complicated for most vanilla, pre-built Roles-based permission systems.
My approach to this problem from database point of view would be to have a user table which holds the list of users, a role table for the list of roles, e.g.: employee, manager, admin; and permission table which stores all of the values of every action/feature available in the system and its permission for a specific role, e.g.: say for admin, the values for actions/features like create, edit, delete, view are all true. The relationships can be seen below whereas (N) ---- (N) is a many-to-many relationship.
Users (N) ------- (N) Roles (N) -------- (N) Permission
My impression is that you would require to make use of roles e.g. employee, Manager, and Admin. So a roles table with these would do. Then for the particular actions/permisions you would have to make use of branching logic i.e. for example for the employee you will have
if User.IsInRole("employee")
// insert logic to deal with customer support tickets
else if User.IsInRole("manager")
// insert logic to deal with manager responsibilities
and finally logic to deal with admin responsibilities
So you need both the users table and the roles table to achieve this.
Hope it helps