I have always chosen method Role. In this project, which I would like to do, there will be about 5 registration methods and in each registration the fields will change. And each type of registration can be called a role, it will have its own ORM structure. and another html. I tried to find the answer in Google and found 2 options (WITH ROLES OR GUARDS). I would like to hear advice from experienced developers which option is better? Thanks all!
For your approach guard will be helpfull. because
You can set any column as an identifier.
You can use your different guard on different route.
You can use your guard in stateful ans stateless environment.
Related
Before you read the title and vote as duplicate, hear me out. I haven't been able to find another example of what I am after.
I have a Laravel 5.5 application that uses the built in Laravel Auth class for user management.
If a user tries to perform an action I want to stop/allow the action based on the user's level.
I have gone through the docs and found that I can write my own custom validation rules by implementing the \Illuminate\Contracts\Validation\Rule interface and call it in the controller but I want to, basically, pass the validator the user level and the level required and validate from that.
Can someone please point me in the right direction to do so?
I dont think the form validation is the best way to make what you want. If you want to restrict actions depending on user permission (here level), you have to create the levels and then check for it before try to validate the form.
I recommend you tu use the Authorization part of Laravel which is well explained in the doc
Where should the authorization code in Laravel? We have a lot of options and a lot of plugins to manage this situation but and I'm not really sure where I should put all logic. Let's see:
I know that there are a lot of possibilities with a correct result but I want to know which is the optimal solution for you or know your techniques in this situations.
Imagine we have a help desk application done in vuejs and Laravel as API, so we have users, groups, roles, permissions. And maybe a user will only able to see its tickets.
Should we do a TicketPolicy with view, update, create methods? Maybe should we use repositories? Maybe a is_user_allowed method in Ticket's model?
Should we use middleware in routes files and do something like Route::get('tickets/{ticket}', 'TicketsController#show')->middleware('can:show')? Or should we call $this->authorize($ticket) in show, edit, update and store methods of the controller?
Or maybe should we use FormRequest#authorize method and then use something like $user->authorize('show', $ticket)?
What if we want groups or roles? Should we use some plugin like Entrust and/or policies?
What do you think, what do you do?
Best place I found to put classes that group specific logic that do not fit in standard MVC pattern is completely new folder for Laravel. I name mine Services, probably because I read it somewhere. One of the great things in Laravel (and probably other modern frameworks) is flexibility, you can just pop a folder, add a new namespace and have it contain whatever you need.
As for your example, I would implement a class App\Services\Permissions that would contain all necessary logic for accessing different resources in your application. Then call it's methods wherever you need them, be it Requests, Middlewares or Eloquent Models.
I'm having a bit of trouble understanding the proper times to use ACL or middleware in Laravel. I do understand the examples on their site and Laracasts, but they're rather simple examples.
This isn't anymore complicated by any means, but I didn't see examples for these. Let's say I have two routes that allow a user to create a task. The first being the GET request to fill out the information, and the second being the POST to store the information. There are some users that are not allowed to create tasks based on their role. In both cases, there isn't a particular object that exists, which is what the ACL requires as far as I understand. So would I use middleware for something like that? And when an object exists, use ACL for that?
An alternative I've been trying to fit in is the use of Form Requests too, but then I'd have to create a Form Request object for each route (although I don't really mind personally).
What is a good approach to limiting acccess to actions, when there isn't a specific action to act upon?
Thanks in advance.
Notice: I was going to post this as a comment, but it got a little too extent. Feel free to wait for better answers and maybe consider this just a comment.
I think that you're missing the whole point here. You can have a middleware that consults the ACL or you can use the FormRequest to consult the ACL or use each of them separately. For instance, at the authorize method of the CreateTaskRequest, you can check the ACL to see if the user has the proper role to create a task.
You might be getting too hooked up when Jeff tries to check if the user owns the post. That kind of ACL is record-oriented, but you can have a role that just takes the user as a parameter (and no other entity) and see if that user just has a specific role. By returning true, the action is authorized, otherwise it's denied.
A middleware have more to do with the route instead of the request. You can also have a middleware that gets the authenticated user and check if it has the role to create a task. Those are different ways to achieve the same thing (which is one of the benefits of Laravel, having lots of ways to achieve the same goal).
Your specific action to act upon is the "Create new Task" action. Who do you want to be able to do that? Users that have the role manager? Users that have the permission create-task?
At the end of the day, what I would consider is:
Are there lots of routes that will have the same rule? Maybe a middleware would be a good choice.
Are there specific rules for each kind of operation? Can an user that did not create a task be able to edit one? Form Requests might be easier to achieve this kind of specification
Which $this environment would make my life easier? $this from the Form Request or $this from a middleware?
One thing I learned from Jeff's class are that he teaches too much cool stuff and sometimes I end up missing one point or two. Try re-watching the basic steps again and maybe stop when you think you found something that would work. Then implement that and see what your case differs from his and how you think he'd write that feature.
I am planning to make a collaborative website where there are project admins and regular participants which are both users of the site but have separate tables in the database, and I was wondering what was the best approach to make this one.
From online research I found out that the best approach for a regular Laravel 4 Auth system would be to use Morph relationships between user types and main user model. I also found that by duplicating ServiceProvider in Sentry can solve this but I don't think this is a a good practice.
So I was wondering if it is viable to use Morph relationships on Sentry 2, or is there a better practice I am not aware of yet.
The Morph relation seems a good idea to me. It also allows to "extend" Sentry2 aswell as other Eloquent models at the same time.
So what you really need is a polymorphic relationship with the User Model and not the Sentry one since extending Sentry model is a real pain, but there is a hack you can do.
Since User and Sentry models share the same id for a single user you can do the following:
User::find(Sentry::getUser()->id)
Hope this helps.
I would like to have two types of users, let's say Teacher and Student.
A lot of the content of the app will be shown to both types of users, but "Teacher" users will see some stuff that "Student" users won't be able to see.
The approach I was thinking to take was to have a ROLE_Teacher and a ROLE_Student instead of a ROLE_User, but I am not sure that would be the best practice, plus, I would have to modify every JSP to make the tests when I want to display specific content.
Did someone try to solve the same kind of problem before? Does Spring contains some mechanism to accomplish this already?
I think defining different roles is pretty much the standard way to solve the problem. Spring Security provides support to constrain the content generated by JSPs based on the roles of the currently authenticated user. (The related documentation: http://static.springsource.org/spring-security/site/docs/3.1.x/reference/taglibs.html) And, of course you will have to modify every JSP to serve only the content which is appropriate to the user's role. I don't think there is some kind of magic that would do that job for you. :)