nil password should be allowed #3887
Conversation
|
I think this can be misleading and it can be a cause of subtle bugs, if you just pass the params without a password, nil will be used and validation will pass, while it should not. This could be achieved by providing some kind of options, like |
|
@drogus My intention is following:
Sometimes, I want to have a user who has nil password and can not be authenticated as a kind of place holder. Think of the case that the user registration process goes like this:
That said, I admit my commit can introduce unintentional changes of behavior into existing Rails applications. I will think more deeply on this theme. Thanks a lot for your comment. |
With this option set to true, you can have a valid user whose password_digest is nil. Such a user can't be authenticated, but can be saved as a kind of place holder. This option is useful when users are required to input their password at the later stage of registration process.
|
@drogus I added |
|
I've discussed this with some of the core team members and the problem is the thing that I put in my last comment: "it was supposed to be implementation for simple case". If we start merging things like that, we will end up with full featured authentication system and this is not the intention with has_secure_password. Thank you very much for your contribution, but please use some kind of authentication plugin or implement such module by yourself to make it fit your needs. |
|
OK. I see. Thanks. |
|
I think it's a little ridiculous to not be open to this simple addition to has_secure_password. @drogus, @josevalim do you really think this would be the start of a slippery slope toward inclusion of an RBAC for has_secure_password? RLY?! Be reasonable, there are simple use cases where this is desired for a site where simple password authentication is necessary (which has_secure_password is perfect for). Example: a site where invitations are sent by user X to user Y and user Y confirms by filling out a password/password confirmation. The invited user should persist without without a valid password until user Y clicks a link in an email and completes registration. A not-so-terrible workaround is to manually validate the minimum required data, manually populate the errors and, if all goes well, save without validations. :allow_nil, please. kthx! |
|
I see fermion's argument. |
User registration process can be divided into several steps.
If the user registration form No. 1, for example, does not have
password field, validation never succeeds with current implementation.