You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 30, 2024. It is now read-only.
if not devise_controller?and not ignore_password_expire?and not request.format.nil?andrequest.format.html?
In other words, if the request is an html-request, then go and check if a password change is needed. And if it's not an html-request, then skip the password change check.
This was a surprise to me: we have some sort of API endpoint, and one API client (curl/postman) was allowed through even when their password was expired, while another API client (powershell) was blocked. After much headscratching and debugging I found out that the trigger for being blocked or not was the presence or absence of an Accept: */* HTTP header. That was surprising to me, I did not expect password expiry to be linked to Accept-headers.
I was unable to determine if this is intended behavior for :password_expirable. This behavior is not mentioned in the README, nor in comments in code, not in the commit message that introduced this behavior. (2063e05)
So the issue here is: Is this intended behavior?
If it is not, then this is a bug and a security flaw, since it allows users to bypass :password_expirable under some circumstances.
If it is, then it would be nice to mention this in the documentation (README.md) (see also !137).
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
I've found that devise_security_extension does not enforce password expiration for non-html-requests.
devise_security_extension/lib/devise_security_extension/controllers/helpers.rb
Line 32 in b2ee978
In other words, if the request is an html-request, then go and check if a password change is needed. And if it's not an html-request, then skip the password change check.
Where
request
is anActionDispatch::Request
, andrequest.format
is this one:http://api.rubyonrails.org/classes/ActionDispatch/Http/MimeNegotiation.html#method-i-format
This was a surprise to me: we have some sort of API endpoint, and one API client (curl/postman) was allowed through even when their password was expired, while another API client (powershell) was blocked. After much headscratching and debugging I found out that the trigger for being blocked or not was the presence or absence of an
Accept: */*
HTTP header. That was surprising to me, I did not expect password expiry to be linked to Accept-headers.I was unable to determine if this is intended behavior for
:password_expirable
. This behavior is not mentioned in the README, nor in comments in code, not in the commit message that introduced this behavior. (2063e05)So the issue here is: Is this intended behavior?
If it is not, then this is a bug and a security flaw, since it allows users to bypass
:password_expirable
under some circumstances.If it is, then it would be nice to mention this in the documentation (README.md) (see also !137).
The text was updated successfully, but these errors were encountered: