Context: Currently, in auth pipeline, we use a rule to check the user’s password validity with a validity period sets to 90 days. If the user’s password is expired, an HTTP code “401 Unauthorized” is returned with an error message indicating that the user’s password is expired. Based on this error, the portal proposes to the user to change his current password.
Rule code extract:
return callback(new UnauthorizedError(‘Password expired. Please change your password!’));
Constraint: Rules will reach the end of life on November 18, 2024. All current rules shall be migrated to Action.
Impact: The “user password validity chacking” rule needs to be migrated in action.
Concern: Action Login Flow: In the action, there is no way to return an HTTP 401 Unauthorized.
When something wrong happens within an action, api.access.deny() is used to inform on the problem such as:
api.access.deny(‘Password expired. Please change your password!’);
The problem of api.access.deny() is that it generates an HTTP code “500 Internal Server Error”. This HTTP code “500 Internal Server Error” does not contain the error message set in api.access.deny(). In this case, it’s impossible to know what’s happening.
Request for support: Are there any ways to generate other HTTP codes with a dedicated error message in the response body by using action in action login flow?
Note: This concern is another blocking point in the migration from rules to actions.
Unfortunately, it is not possible to generate other HTTP codes with the api.access.deny() method. For now, you can only specify the reason with this method and throw the error.
Here is a helpful resource to help you with your migration to Actions:
I give a try to the “Password Rotation Integration” action as suggested and this one does a little bit more than what we do. This is action is great with a possibility for us to use it as a replacement of our own one.
But as you highlighted the HTTP code which is generated remains “HTTP 500 Internal Server Error” even for the “Password Rotation Integration”.
Same behaviour for both Password Rotation Integration action and our action.
This is not what we expected. As a temporary solution, we will try to work on a workaround by analysing the URL query of the response to see what’s going on.
Looking forward to a real solution from Auth0 to this concern.