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
Related
Okay, so I know about middleware hence the "From Controller" specification in the title but basically, the issue I have is this, I have a SaaS app that I'm adding a gifting feature i.e give someone a plan as a gift and so I need to force login on a regular user while allowing either way on one gifting the plan to make it easier. Makes sense? Anyway, for that reason, I cannot use the auth middleware since I have, and want, only 1 checkout page.
So, how can I force login from my Checkout Controller like the way the auth middleware does it on routes?
Since I haven't gotten a suggestion, I'll post the workaround I came up with and the potential solution I simply have no time to study up on at present:
Likely solution:
Use Auth::guard('guard name here') and you can learn more about this here.
My workaround:
I created another route pointing to the same controller function but one is going through middleware('auth') while the other isn't. Practical example below.
Route::get('checkout/summary', [CheckoutController::class, 'summary'])->middleware('auth')->name('summary');
Route::get('checkout/gift-a-sub', [CheckoutController::class, 'summary'])->name('gift-a-sub');
With this, I only require one page to prevent complications while forcing authentication for regular users while those just opting to gift a plan aren't required to do so and all I have to do then is save the data based on a flag created at the Pricing page.
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.
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 wrote a plugin for joomla that adds custom fields to the user/register component. There are 3 different registration forms for different user groups.
The plugin acts on onUserAfterSave() and works fine, but there is one problem. When there is an error in the original user component, for example: "the username has already been taken" the form is redirected and neither onUserAfterSave() or onUserBeforeSave() is ever called.
I want to change that redirection, but without changing the core, but since neither plugin events are called, im not sure how to. Can you guys help me? Maybe I am missing something!
Is it possible to maybe override the save() function?
THANKS
I had same problem many times, so i can share a solution i use myself. If you don't want to edit Joomla core files, you can do the following:
Create your own template override of registration view.
Duplicate the components/com_users/controllers/registration.php file and lets say name it registration2.php
In your registration form override change hidden input's "task" value from registration.register to registration2.register
Feel free to override registration2.php classes how you like.
It's totally Joomla update proof, so you can update your joomla version witht worrying about errors.
I think you might need to do the checks that joomla is doing in your plugin and redirect in your plugin itself in the case that it wont pass. I see your predicament and I don't know a better way but I would pick a different event to run it on maybe even after page load and then on UI event in javascript.
The only clean way to extend the user registration/profile is to create a profile plugin like this one
https://github.com/joomla/joomla-cms/blob/master/plugins/user/profile/profile.php
You can extend com_users forms in backend and frontend.