-
Notifications
You must be signed in to change notification settings - Fork 143
feat: User activation checks and utility functions. #580
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
Conversation
| return redirect()->to('/login'); | ||
| return service('response') | ||
| ->setStatusCode(Response::HTTP_FORBIDDEN) | ||
| ->setJson(['message' => lang('Auth.badToken')]); |
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.
This is a breaking change. It is better to document it.
#433 suggests 401, not 403. Which is better?
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.
+1 for 401. For example, I already using it in few deployments with own api-filter. I would like to switch to this one if it's will be suitable for me.
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.
401 Unauthorized is the status code to return when the client provides no credentials or invalid credentials. 403 Forbidden is the status code to return when a client has valid credentials but not enough privileges to perform an action on a resource.
Receiving a 403 response is the server telling you, “I’m sorry. I know who you are–I believe who you say you are–but you just don’t have permission to access this resource. Maybe if you ask the system administrator nicely, you’ll get permission. But please don’t bother me again until your predicament changes.”
In summary, a 401 Unauthorized response should be used for missing or bad authentication, and a 403 Forbidden response should be used afterwards, when the user is authenticated but isn’t authorized to perform the requested operation on the given resource.
@lonnieezell Here we are mixing authentication and authorization. Maybe we need to first check if a client provided a valid token and if not, return 401 and after that, check, scopes and if there is no valid scope, return 403.
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.
The HyperText Transfer Protocol (HTTP) 401 Unauthorized response status code indicates that the client request has not been completed because it lacks valid authentication credentials for the requested resource.
This status code is similar to the 403 Forbidden status code, except that in situations resulting in this status code, user authentication can allow access to the resource.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/401
The HTTP 403 Forbidden response status code indicates that the server understands the request but refuses to authorize it.
This status is similar to 401, but for the 403 Forbidden status code, re-authenticating makes no difference. The access is tied to the application logic, such as insufficient rights to a resource.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/403
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.
These make sense. First check will result in a 401, with the not-activated check being a 403.
| /** | ||
| * Activates the user. | ||
| */ | ||
| public function activate(): bool |
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 change the return type to void?
The UserModel::update() throws an exception when the update fails.
So returning bool does not make sense.
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.
Unless it's changing in a PR, update() currently returns a boolean. Changing this to void throws errors.
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.
I sent a PR #626
| /** | ||
| * Deactivates the user. | ||
| */ | ||
| public function deactivate(): bool |
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.
The same above.
|
We have a new language file 'activationBlocked' => '(to be translated) You must activate your account before logging in.',Also conflict in file src/Entities/User.php. |
Co-authored-by: Pooya Parsa Dadashi <pooya_parsa_dadashi@yahoo.com>
Co-authored-by: kenjis <kenji.uui@gmail.com>
8e10faa to
8ab2d6f
Compare
datamweb
left a comment
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.
@kenjis, we can address your opinion separately in PR. This PR has taken too long.
|
Thanks! |
Fixes #459
Previously, the
activecolumn for the user was not being used except that theEmailActivatorflow would set it. This PR addresses this by:Activatabletrait that is used on theUserentity. This provides methods to check if a user is activated or not, and utility methods to activate/deactivate that user.SessionAuthandTokenAuthfilters are updated to check the user's active status and redirect to login/return a 403 status code, respectively, when they aren't active. This takes into account if no activator is required after registration.