I agree with you that consistency is more important than patterns. That being said, my personal preference is that each request should be authorised first before validation happens. As such, I use the can method at the routes level. This has the added advantage of centralizing all validation rules in one place (at the routes declaration). All requests are authorised before they get to the controller whether or not that route uses a FormRequest class. Once again, this is a personal preference, and consistency throughout a codebase is much more important than "patterns."
I also usually customize stubs to make it true by default whenever I start a new project. But I think removing the method will be better, as I never use authorization in form request class rather in controller or policy.
consistency should be maintained: if you use GATE in the controller, then in each required action, not once in the controller and once in the formrequest
I work on large Laravel codebase where we have multiple API routes, each of them having form request. Every method in controller has each own form request imported and we use authorise method heavily throughout the code. Personally I find it useful and meaningful that we do authorisation in the form request rather than method in the controller where we might have other logic that processes the data further. But at the end of the day it is a matter of preference and consistency.
Hard lesson and many debug hours indeed. I ended up removing the method in the stub in most of my projects. But I wonder: when having a Gate in the controller, you will get the validation errors (when you can see the add/edit form and you do something wrong). Only when you fill in all the fields correctly you get a forbidden because only than you make it into the controller. That’s why I prefer the authorize method. Thanks for sharing Povilas!
Hello Povilas, I have a request if you get time can you make an updated video for laravel sanctum, fortify with vue api mainly the setup of the api, there is not many video guide for this. Thanks as always for the amazing work you do.
Because no one really uses Fortify that much. It was popular only when Laravel 8 was released and the ONLY reason for Fortify to exist was to be used in two different Starter kits. I haven't used it directly since then.
Interesting, I have always just assumed FormRequests are good, "use the framework", but the documentation says they are "For more complex validation scenarios". So, maybe its OK to just move both validation and auth into the controller method 🤔 I think you can still have "thin controllers". with this approach.
Do I understand correct that besides the Request's authorize() method and checking the Policy from the Controller, we also have the third option to put the authorization logic? It is Middleware. Can anyone explain the choice between the three?
I agree with you that consistency is more important than patterns.
That being said, my personal preference is that each request should be authorised first before validation happens. As such, I use the can method at the routes level.
This has the added advantage of centralizing all validation rules in one place (at the routes declaration). All requests are authorised before they get to the controller whether or not that route uses a FormRequest class.
Once again, this is a personal preference, and consistency throughout a codebase is much more important than "patterns."
In my opinion avoiding validation to be performed in case of unauthrized is a good reason to keep using FormRequest authorize method
Good point!
Yeah! it makes really sense to remove authorize() due to consistency in the code. Cool, Thanks
I also usually customize stubs to make it true by default whenever I start a new project. But I think removing the method will be better, as I never use authorization in form request class rather in controller or policy.
Thank you very mush this add an information to me
It would be possible to create an abstract class that extends FormRequest and insert authorize() inside it.
Thank you
consistency should be maintained: if you use GATE in the controller, then in each required action, not once in the controller and once in the formrequest
Informative stuff thanks ❤.
I work on large Laravel codebase where we have multiple API routes, each of them having form request. Every method in controller has each own form request imported and we use authorise method heavily throughout the code. Personally I find it useful and meaningful that we do authorisation in the form request rather than method in the controller where we might have other logic that processes the data further. But at the end of the day it is a matter of preference and consistency.
Hard lesson and many debug hours indeed. I ended up removing the method in the stub in most of my projects.
But I wonder: when having a Gate in the controller, you will get the validation errors (when you can see the add/edit form and you do something wrong). Only when you fill in all the fields correctly you get a forbidden because only than you make it into the controller. That’s why I prefer the authorize method.
Thanks for sharing Povilas!
Yes those methods are executed at a different time in the lifecycle, indeed sometimes it's important.
Whenever I create a request, I just delete the whole method instead of making it true.
Hello Povilas, I have a request if you get time can you make an updated video for laravel sanctum, fortify with vue api mainly the setup of the api, there is not many video guide for this. Thanks as always for the amazing work you do.
Because no one really uses Fortify that much. It was popular only when Laravel 8 was released and the ONLY reason for Fortify to exist was to be used in two different Starter kits. I haven't used it directly since then.
The Laravel offical channel published recently a video on how to setup a custom Fortify auth
@@julienSibille really, I need to check that out. Thanks for the info, unfortunately its mainly Laravel based not api based
@@LaravelDaily that is understandable...
I personally check for a user in all forms after login as
public function authorize(): bool
{
return (bool) auth()->user();
}
For that, it's better to have Middleware 'auth' in the routes, for the route group.
and it's auth()->check() then
Interesting, I have always just assumed FormRequests are good, "use the framework", but the documentation says they are "For more complex validation scenarios".
So, maybe its OK to just move both validation and auth into the controller method 🤔 I think you can still have "thin controllers". with this approach.
Do I understand correct that besides the Request's authorize() method and checking the Policy from the Controller, we also have the third option to put the authorization logic? It is Middleware. Can anyone explain the choice between the three?
The choice is totally up to you, whatever you prefer.
Personaly, I always delete it !
I always remove it and it definitely should be true by default 🤮
Since Laravel 11 we shouldnt use FormRequest anymore
Why?
why?