Remove Valid Password Constraints from DatabaseAuthenticatable Concern #5048
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Overview
PR #4261 and subsequently #4970 were added to address issue #4245. In doing so, a hard requirement for having a non-nil, non-blank password was injected into
DatabaseAuthenticatable
. As many of us are upgrading from version < 4.6 to 4.6.1 to address #4981 we are unable to do so because we have a pre-existing implementation that allows the creation of a Devise model with no password. A common use case of this is pre-creating an account when a user submits an email for marketing purposes.However, in my opinion, a valid use case is irrelevant to what this change did. It broke the nice separation of concerns that existed in Devise prior to version 4.6.0.
DatabaseAuthenticatable
should not be deciding what constitutes validity for a password, that is what theValidatable
concern is for. Given thatValidatable#password_required?
exists, which allows implementations to override default behavior and explicitly not require a password, is further evidence why this change was a mistake.Furthermore, the original issue that sparked this change, #4245, was either inaccurate to begin with, or had been properly fixed in 2+ years since being reported and the change being merged. I have run the same "test" on an implementation using this branch:UPDATE: A colleague of mine pointed out that my change was different than the pre-4.6 behavior and that is why the test case from #4245 was passing. I updated my change to set
encrypted_password
to a blank string if the passed password argument is blank as well. This should mimic the pre-4.6 behavior as well as keeping the "default"encrypted_password
value the same as defined in the schema.Changelog
Changes
nil
fromDatabaseAuthenticatable#password_digest
if the passed password argument isnil
orblank
''
if a blank password argument is passedRemoved