So i have two models
clients
employees
The main difference between these two are that employees has some different more advanced controls.
Now regardless of what user that logs in i need to set a cookie (what the cookie does doesnt matter just to give you an idea).
Now since my employees has more options and actions than clients there is a seperate index view for the.
Now to my question since both types of users has to set a cookie is it possible to do this from the client login controller meaning that "unknown person tries to log in" -> "checks client model if user exists" if not "check employees controler if user exists" if true -> "set cookie " ->"go to employee view index"
Is this possible and is it a good way to do it. Note that the reason why i need to do this is because i want to create a God like user in the clients table. My client table consists of alot of joins and it would be easier to create a "God like" user that will look the same as a normal client (kind of like a proxy).
I think you’ve gone about this the wrong way.
Ideally, you should have a users table and a corresponding User model, and then use ACL to determine what a user can and can’t do. You can create roles for clients and employees, and set permissions on these groups, and assign each user to a group.
If you have client- and employee-specific data you wish to store, then you can always create these tables/models and set them to belong to a User.
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'm making a school management system using CodeIgniter framework of PHP.
I'm stuck in a situation where I want to make super user that the Principal of school will use and manage new students and teachers and other stuff related to school. He will obviously login first and then manage other details.
i. I want to know where should I place this super user. In database or hard coded it's username and password? (I know it is not good to make a table which would have just one row)
ii. And if I should "hard code" it then where should I write it's login detail so that it's secure.
You should keep the data in database keeping relation with multiple tables which wil help you later for givings roles to the users. Such as:
tbl_user -> Will contain users information
tbl_roles -> Contains the roles of the user
tbl_user_permission -> Would contain the user given permission to certain user.
Hence, the super user/ admin will have all the contained permissions whereas the super admin has also the facility to gib certain permission to other users as well.
Depending upon your SMS it will contain multiple users and different levels of users, so it is probably best to entry the data into database. Dividing into multiple tables.
I'm building a PHP application where users can design products and then check out to a shopping cart if they want to.
To let the user create a design, I need to assign a user ID and design ID to store it in the database.
There are two types of users who can build designs:
registed users. To take care of this, I have no problem.
non-registered users. These are guest visitors who might play around with product designs, and then when they hit check out, only then will I ask them to sign up. But in order to store their designs, I do need to have some kind of user ID.
I thought of using a timestamp as this user's ID, but what if two users in different parts of the world create designs at the same time? What's a good strategy for generating IDs for temporary/guest user accounts? I don't just mean temporary in the php session sense, because I want them to be able to access their partially saved designs later on if they visit the site again, just like any other registered user. I will only ask them to sign up before checking out for payment.
A simple approach might be:
Use a single user table (for registered users and guests)
Assign a "user_type" flag. E.g. registered/guest
Use the table primary key or other unique value for both "types" of user
When guests check out later on, switch their "user_type".
Store other related customer details in a separate table.
I've 2 tables, Users and Customers and 2 different actions for them. so I need 2 authentication system. Users login with username and password, and customers login with and id and password.
I know cake default AuthComponent can handle just 1 model, User model. because 'userModel' can be string not array (isn't it?).
How can I use it with 2 models (and tables) with 2 login pages and 2 .... .
(note: I can't combine the 2 tables. they have different schemas)
Instead of trying to maintain 2 different Auth systems, I highly recommend you look into ACLs and AROs. This will allow you to associate users with different access groups - in your case you could have groups like 'Internal'1 and 'Customers', and each new user account is a member of one group or the other.
You can then grant permissions at a group level. Customer users have access to their content, Internal users have access to different content.
There is a good tutorial in the new CakePHP book: Simple Acl controlled Application
1 I assume when you refer to 'users' generically you mean internal users, but feel free to adapt the terminology and group names to your particular situation.
I would presume 2 separate logins areas or a radio button to suggest which login they are attempting.
Use that input as which table to auth against then your code should follow the same path.
if (customer) {
do customer stuff;
} elseif (user) {
do user stuff;
} else {
you didn't login;
}
When you create the registration forms for them try to get their data into different databases. So that you can treat them differently. For this purpose check the submit button ids and direct the data to appropriate tables. When inserting put id's as auto increments.
I would advise against discriminating users from customers in this situation. These issues can be resolved using roles. Before jumping to design, please read about Authentication, Authorization and Audit and Role-Based Access Control.
From my understanding, this is an overview of the authentication process (note that I am not a security expert):
The identification phase is concerned with obtaining user credentials. A simple form that retreives user's name and password would suffice.
The authentication phase represents the process that maps user credentials to an user. Basically, it identifies a identity provider and uses it to obtain an user id for the user credentials provided.
Viewed like services, they look something like this:
// You can have many IdentityProviders. This mecanism allows you to extend your
// authentication system so you can use any mechanism (WebDav, Kerberos, etc).
IIdentityProvider
{
// Returns a pozitive id if the user is found and the credentials are valid
// or zero if user credentials are invalid (or negative numbers that represent
// error codes).
UserID GetUser(UserCredentials)
}
IAuthenticationService
{
Session SignIn(UserCredentials)
void SignOut(Session)
}
DefaultIdentityProvider : IIdentityProvider
{
// Search the user in your database.
UserID GetUser(UserCredentials credentials)
}
AuthenticationService : IAuthenticationService
{
IIdentityProvider[] identityProviders
Session SignIn(UserCredentials credentials)
{
IIdentityProvider provider = identityProviders[credentials.Type]
Session session = null
if (provider)
{
UserID userID = provider.GetUser(credentials)
if (userID > 0)
{
session = new Session
session.UserID = userID
}
}
return session
}
void SignOut(Session session)
{
delete session
}
}
The autorization system says what can a user do with a resource. Resources can be any entity that your application manages. They have a type and an ID. Optionally, they can be part of one or more categories. Users can execute certain operations on a resource, depending on its type and categories. This is defined by a permission. Permissions are grouped in roles. You can assign zero or more roles to an user.
In your example, a customer is a role. A resource is, for example, a product. A product is represented by the Product type, it has an ID and can have some categories associated ("Electronics" and "Dangerous"). Operations can be viewed as variations of Create/Read/Update/Delete verbs. Now, the Customer role would contain a set of permissions that explicitely states what a user having this role can do with the managed resources. For example, a Customer can only Read certain informations about the product, but cannot Create, Update or Delete a product. Note that if a user has more than one role associated, it gains all the permissions from that roles (an union operation, not an intersection).
This only scratches the surface. For further reading, you can find on the Internet more articles that explain these concepts alot better. This is meant to point you in the right direction.
My RealEstate PHP Application have following user groups,
Admins,
Moderators
Agents
i want to specify following permission to the following users.
Admins - >
Can Create Moderators,
Can Create Agents,
Can Insert Properties,
Can Update Properties,
Can Delete Properties
Hence an Admin will have all the privileges in short an Admin here will be superAdmin
I want to assign limited privileges to the moderator and hence to the agents.
i am confused on how to Create a Database for this and also on how to implement it in my PHP Application.
thank you
It sounds like you are going to need a role-based access control system. Developing one is not
really a trivial task, so as already suggested, finding a framework or ready-made class that does
the job would be a worth while start.
Role Based Access Control
http://www.tonymarston.net/php-mysql/role-based-access-control.html
http://www.sqlrecipes.com/database_design/fine_grained_role_based_access_control_rbac_system-3/
http://www.sitepoint.com/forums/showthread.php?threadid=162027
You should create a table wher you have to define all type of role.
and one table for users
relate different roles to different user Via linking two tables.
and some thing like this ......
The way that I have done this in the past was to create a users table in the database that had an access level (Admin, Moderator, and agents).
Then if you have a menu system, implement a check to see what privileges are needed for what links... Admins will see all links, Moderator will only see links he/she is supposed to, and agents will only see what they are supposed to see.
Also on the pages that you may want to restrict users you will want to check for the users access level. If they pass, they will see the page, if not, they will be redirected or a javascript error will need to pop up.
Something like the access level may do you some good to store it in a cookie as you can cut down your calls to your database.
Hope this helps,
Mike