I have at least one model in my Yii project that will need to reference a particular user ID. In my SQL for the model I have something like CONSTRAINT FOREIGN KEY (user_id) REFERENCES User(id). I was going to go ahead and create a User model when I came across the docs for CUserIdentity. I have to admit I am confused. Is a CUserIdentity a user or a state associated with a particular user-case? I would like to use as much of the built-in Yii features as possible since they handle a lot of security-related issues from what I understand, and I am aware of the existence of some modules like srbac that handle user authentication and registration management. Please guide me in the right direction. (Also at issue: what is the relationship between models and components?)
First off, do go ahead and create a User model, you will need it.
With that out of the way: CUserIdentity represents the concept of "who the user is", while the User model represents "information about a user of my application". CUserIdentity is applicable in all cases where there is more than one kind of user (i.e. guest), while the User model is only applicable when you are storing information about the users yourself. Admittedly, in most cases both will be applicable and this is what creates the confusion.
Usually, the relation between the two is that CUserIdentity, in order to answer questions such as "who the user is", "is the user allowed to access this resource" etc. queries the User model from the database to get the information it needs to answer these questions. This relationship between the two concepts is also documented in the definitive guide to Yii. After e.g. authenticating the user, it would expose some or all of the information on the User model through its own properties (which you would have to define).
To give an example of a scenario where there would be no User model, think about a website that lets you log in using your LDAP user account. When the CUserIdentity::authenticate method is called, the component would authenticate the credentials against the LDAP server and after a successful authentication would again grab any other relevant information and expose it through its own properties.
Related
I'm writing a timesheet application which would be used by employees and approved/rejected by supervisors. A timesheet has various permissions and only people with certain roles can do certain actions (like for example only a supervisor can approve a timesheet and only if it belongs to an employee under the supervisor's list of employees).
I'm trying to figure out how to structure my list of business objects (models). There are various validations I need to do before I can invoke methods like GetTimesheet or SaveTimesheet or ApproveTimesheet. See the following psuedo-code for an understanding of how my app should work:
GetTimesheetByUserIdAndMonth:
-Validate parameters like UserId, Month-Year value
-Check Permissions:
- If Logged In User is A Supervisor, then see if Timesheet belongs to either this user or to a user under Supervisor's list of Employees
- Else, check if Timesheet belongs to logged in User
SaveTimesheet
-Validate parameters like UserId, Month-Year value
-Check Permissions (same as above)
-Check if user has write ability for timesheet (for example if user had already submitted timesheet before then he can't re-save or re-submit)
SubmitTimesheet
-See if user has a supervisor assigned
ApproveTimesheet, RejectTimesheet
-Logged in User must be a Supervisor, otherwise throw an error
I'm thinking I would need a MyAccount class for the person who is logged in, a User class to represent the person who the timesheet belongs to, a Timesheet class, and maybe some sort of Validation class.
Can someone tell me how best to architect this code and what sort of classes and validation methods I should have? I already have this code working in 100% procedural code...it is very difficult to read and maintain. I'm not looking for full implementation details, just an overall class achitecture/structure. Please give me some ideas and provide me some psuedo-code how to accomplish the above tasks. I can provide more details if necessary.
Thanks in advance.
In your question I can understand 3 different kinds of problems to solve.
The hierarchical structure
Permissions
Validations
A possible pattern to solve this problem is Composite pattern. Some general guidelines to follow can be listed as below.
Use an abstraction which can be used to refer all kinds of users (supervisors, peers etc). Something like 'User'.
Use composite to maintain hierachy.
The abstraction 'User' should have methods like getWritePermission: boolean to provide permissions.
Validations should be decoupled from the core structure. You should maintain those logic using a separate worker class, which will be called at the very higher level of the api call.
I take it you are using an mvc approach. If so you are already on the right track.
Each User action needs a controller. What you already wrote down suits this scheme.
The tricky part is how you store the user:supervisor relation? And is it 1:n or m:n? Anyway I'd go with a User and a Timesheet model (backed by a database) and then go as needed. You don't need to differentiate between user myself and other users on a class object level.
Inside you are your own judge. A Timesheet validator class and a class for checking user rights seem to be needed (additionally to the login system).
Think the following
UploadTimesheetController -> TimesheetValidatorClass -> TimesheetModel -> Database
ViewTimesheetController -> CheckUserHasAccess -> TimesheetModel -> TimesheetView
It's a bit simplistic and not formally correct but I hope you get the idea.
I know this is a duplicate question but i think it will help others because there are a lot of similar apps that have these kind of table relationships:
So the question is what would be the optimal solution for all relationships in this schema using the Eloquent?
How many Models and Controllers to make?
First of all, you need to understand that not all tables in a database represent an entity.
For example, tables like users, posts, comments are entities. Whereas posts_users, comments_posts are not: they are here for technical reason, to materialize the relation between 2 entities.
Only entities need a model: it makes no sense to have a model for a relation table.
Even if a table holds information like date_created, it does not make it an entity. This is just a data related to the relation. For example, the table users_roles may have a column named date_assigned, to know when a given user was assigned a given role. It's not entitity for all that.
Second, you need to understand what a controller is for. The role of a controller is to handle a request and provide a result. Result can be a view, an error (HTTP 404), or just the fact that an action has been successfully done.
You must also make the difference between the class called Controller (or any child that extends this base class) and an actual controller. The actual controller is the code that will handle the request. A Controller class can have more than one method to handle requests.
It's all a question of organization: generally, Controller classes are used to group methods within the same scope: user login, logout, subscription, password reminder are all the same scope. All these controllers could be in different classes or functions. It does not matter. Each method is a controller. They are grouped in the same class because they have the same needs (check user is logged in, to know if login is required, if subscription page can be displayed, etc.) and they are in the same scope, which just make sense when you think of it. That's just logical: you know where to search when you need to change something about user identification (even if you are new on the project).
So you need a model for these entities:
User
Offer
Invoice
Category
The controllers you'll need depends on what you want/need to do with this data. There's no ready-to-use answer to this part of your question.
Use a Controller class for:
user authentication (if you need some)
user management (backoffice)
invoice management (edit, mark paid, list of late payments, etc.)
categories management (create, edit, delete)
offers management
But depending on your application, you may need more. Only you can really say. There's no bad answer to this question: if you think some controllers should be separated for better organization, do it. If you think you should group 2 or more, do it. There's no rule. You have to keep your code clear and well organized. It must suit your needs. That's all.
I have used this tutorial for creating my user login in Laravel: Laravel Authentication Essentials. So I have a SessionController that contains the methods create, store and destroy, for showing the form, logging in and out respectively.
But there is no model in this tutorial, the validation and Auth::attempt is in the controller. And that doesn't feel right. I can not create a Session model, since the Session class already exists.
Should I put the login/out logic in the User model, or is there another way to do this that complies with the MVC architectural pattern?
First, remember (or know) that you can change everything in Laravel. If you need a Session model using a sessions table, go to app/config/session.php and change the Laravel sessions table to laravel_sessions:
'table' => 'laravel_sessions',
People are doing things differently these days, methods are improving on a daily basis and the way you do your code must be confortable to you. If you feel it is not right the way you are seeing people doing it, change it, Laravel give you the power to change and do things your way. And if you feel you just found a better way of doing it, share it.
This is a 2013 video and today Jeffrey is doing authentication in a completly different way. Sign up for a Laracasts account and take the full Build a Larabook video series to see how he's doing it now.
There's no Session model in this tutorial because he's not storing sessions (successful logins) in a sessions table.
In the tutorial he never touches the User model, so there is no login in the user model. The only thing he's using to do authentication is Auth::attempt(), a Laravel facade method which uses internally the user model (M), to find a user and check if the password matches. He's working with a Session controller (C) and everything related to login (or sign in) and showing login views (V) is done inside that particular controller.
If it is easier to you, you can rename SessionsController to LoginController, I, myself, don't really like the Sessions name for login, but that's a matter of taste not code correctness.
That being said I don't see an MVC (or whatever name people like to call it this week) problem in that video.
EDIT Answering the comment:
The purpose of the model is towards data, no data, no model. In the context of Laravel and a database management system, yes, no table, no model. In the context, for instance, of a client-server API, your server API (Laravel, Rails...) will provide data for your client model (Angular, EmberJS...), so, there will be no table directly related to the client model, but still a model.
But in that particular case you are accessing a model, the user model, via a service, the Authentication service.
Given a website site has different web pages that can only be accessed by different group of users. Say guest users can only access welcome page/search page, while, administrator users can access pages that update the DB, etc.
I have little experience on this field and would like to adopt some best practice with clean/simple/secure implementation.
If possible, I would like to see some concrete examples/tutorials, even a book resource.
Thank you for your helps
I have found that many applications available online (Wordpress, Joomla, and many other), are very poorly organized in this field (poorer than what I do, in any case).
Take a look at how it's done for MVC frameworks like Zend Framework, CakePHP, Symfony. MVC is mostly used for bigger projects that tend to be much more organized, so I am betting that they have worked a lot on authentication too.
In 2 words, for this to work properly, all your page generation classes (I advise the use of OOP) must be derived from a parent class, which will hold access control methods. Or you could have a class with static functions for access control. Before any action, simply call these functions to check whether the user has access to this functionality. Functionality can be grouped into Classes, with many Methods (in MVC - Controllers and Actions). You can store access information in the database as follows: groupID, Class, Method, Permission, where permission could be a boolean Grant or Deny. To promote speed, extract all user's permissions at first query, store it in an array or object, so as not to generate a query for each permission verification in the user request, but parse the saved data instead..
Each user can have a role or roles in your application / website. Imagine you have an application where some people can edit users and others can insert tasks while others can solve the tasks. Create three roles: user managers, task assigners and task solvers.
Then give users their roles.
Some people call roles groups. You group people to give them permissions. I prefer calling it role because user acts as HR manager or website publisher etc.
This is just a simple example, it's always based on requirements you have. There can be team-based permissions, department-based permissions etc.
http://en.wikipedia.org/wiki/Role-based_access_control
Personally, I have an application broken down to modules. Each module has objects and these objects have actions. Example: user.department.list = in module user, there's an object department and action list (departments). When you create role or group, assign these permissions to that role (group) and users. For role User managers, there're permissions user.user.list, user.user.edit, user.department.list, user.department.edit. After you authenticate a user (to know who's he) load roles he's assigned to. Each page (controller) or each method can check user's permissions - is this user permitted to list departments?
That's kinda vague so here's the meaty stuff:
I have seen authentication systems that do one of the following
have a separate role table for each roles, and a separate permissions table, all users in one table
have a separate table for administrators
there's a lot that I have missed, I know. But what I'm trying to really ask is:
How should I design my database in a website that I have a lot of kinds of users and each with different access?
How will I make it so that my script is flexible enough if I decide to add another type of user with another type of permissions?
I currently have a User class and am planning to make my Administrator class which extends that User class. Or is that a bit of an overkill when I can have them all in a single class and just assign necessary permissions?
you can have tables -
user (user_id, name ...)
permission (perm_id, name, desc)
role (role_id, title)
user_role (user_id, role_id)
user_permission (user_id, perm_id)
role_permission (role_id, perm_id)
This way you can have as many roles in the system as you require, and you have both role level permissions, user level permissions.
you can add an additional level of abstraction. basically you add a table in your database to manage user groups, and assign group permissions to those groups. different users can have multiple groups.
this way you can quickly change permissions to a predefined set of rules, without needing to change every user separately. you can also change the permissions for a group of users at once
I think you need to think about several concepts here. The first would be an access control list (ACL) and then second would be authentication.
In an ACL, you define resources, which are objects that you want to restrict access to and roles, which are objects that may request access to a resource.
The way I implement my ACL, is using Zend_Acl. I have a table called user_roles
user_roles('user_role_id', 'name', 'permissions', 'parent_role_id')`
I also have a table called user_role_maps that maps a user's ID to a user role ID. (You could just have this as a column on the user table, but that just depends on how you feel about normalisation ;-) .) I can then construct my Zend_Acl object from this table and then, when a user is authenticated, I can determine which resources they have permission to and what actions they can perform on a resource. (A resource implements Zend_Acl_Resource_Interface so it is identifiable by Zend_Acl as a resource.
As for authentication, this is a simpler concept (in my opinion), you've probably already figured out some form of token matching authentication system yourself. The crucial aspect is using the authenticated user's ID to determine their role. The Zend Framework also provides a package for this in Zend_Auth.
I've used a lot of Zend Framework recommendations here, the reason for this is that their packages have very few dependencies on other packages, making it quite simple to plug components in. I'm sure other frameworks provide ACL packages that you could use, or roll out your own if you have the time and understanding.
Good Luck.