-
-
Notifications
You must be signed in to change notification settings - Fork 437
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow user to be guest when using the @can directive #431
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you please add comprehensive tests for the behaviour you added? Not merging this as is.
Hi @spawnia 😄 plus the test will fail if the version of Laravel is less than 5.7, because this is the new behavior as of ver 5.7. https://github.com/laravel/framework/blob/5.7/src/Illuminate/Auth/Access/Gate.php#L365-L407 |
This is looking pretty good, can you add a few lines to the Possibly with a hint that guest user functionality requires Laravel 5.7. |
@spawnia Done! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @yaquawa
Excellent work @yaquawa, thank you! |
PR Type
refactor + behavior change
Changes
currently, if we use the
@can
directive, the current user must be authenticated.while Laravel itself allow the
$user
to be either a guest or an authenticated user by specifying the first argument ($user
) as a nullable argument or an argument with the default value withnull
in the policy class's methods. This PR make it aligned to the Laravel'scan
method.The authentication check logic should be separate from this directive, for example the
@middleware
is the best place to do that.Additionally, I found use the keyword
ability
is more understandable in most of cases(aligned to Laravel's naming convention) than usingif
, so I added an option to allow user to useability
instead ofif
.Last thing that might worth to mention is that I separated the validation logic into the
validate
method to get more extensibility. I found validation logic can varies quite differently in some cases. Making the validation logic stay in a method so one can make a new directive by extending the CanDirective class and change it's behavior very easily.