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
Expected Behaviour
I have maximum_attempts set to 10 and last_attempt_warning is set to TRUE, so I expect that:
A pre-lock warning is returned after the 9th failed sign-in attempt.
An account-locked message is returned after the 10th failed sign-in attempt.
Actual Behaviour
After the 9th and 10th failed sign-in attempts, I see the bad_credentials message.
After the 11th failed sign-in attempt, I see a message that the account is now locked.
When users sees the bad_credentials message after the 10th failed sign-in attempt, they still expect to be able to sign-in. However, they cannot, because the account is already locked.
The user never sees a pre-lock warning.
I was able to bypass this behaviour with the following override to the sessions controller, but this is obviously not an ideal solution:
def render_create_error_bad_credentials
if @resource.respond_to?(:locked_at) && @resource.failed_attempts == Devise.maximum_attempts - 1
render_error(401, I18n.t('devise.failure.last_attempt'))
elsif @resource.respond_to?(:locked_at) && @resource.failed_attempts >= Devise.maximum_attempts
render_create_error_account_locked
else
super
end
end
The text was updated successfully, but these errors were encountered:
Hello!
Thank you very much for this gem. I use it a lot and it saves me so much time and effort.
I think I have found a bug in the sessions controller, surrounding how it handles the Lockable strategy.
Version
devise_token_auth (1.2.2)
devise (4.9.2)
Configuration
config.lock_strategy = :failed_attempts
config.maximum_attempts = 10
config.unlock_keys = [:email]
config.unlock_strategy = :time
config.unlock_in = 30.minutes
config.last_attempt_warning = true
Expected Behaviour
I have maximum_attempts set to 10 and last_attempt_warning is set to TRUE, so I expect that:
Actual Behaviour
I was able to bypass this behaviour with the following override to the sessions controller, but this is obviously not an ideal solution:
The text was updated successfully, but these errors were encountered: