Password field is not compared to repeat password field in Signup form about openstreetmap-website HOT 9 CLOSED

There's probably not much point spending time on this if we're about to get rid of the intermediate page.

from openstreetmap-website.

I discovered this by testing the signup page in #4455 , but the bug is inherited from master. I am not too sure how to fix it.

from openstreetmap-website.

Well normally it would be discovered when the record is saved but that won't happen for a two phase signup like this so I think the first phase is supposed to run an explicit validation on the record but as I say that is about to go away and then the record save should catch it in the normal way.

from openstreetmap-website.

I found the problem:

after_initialize :encrypt_password is invoked before the first time the form is validated in users_controller.create. This function modifies both password related fields, and effectively disables validations for them.

I will address this in #4455.

from openstreetmap-website.

Ah that's my fault, and is a recent change as it used to be before_save but that was breaking other things :-(

from openstreetmap-website.

Specifically aaed886 was the change - the before_save is in fact still there.

I'm not quite sure why it needed to hash it - the critical thing was including both copies in the session. Possibly I was just trying to avoid keeping unhashed passwords lying around.

from openstreetmap-website.

So b155313 was the original fix - to preserve the second copy in the hash so that the before_save filter could work.

Apparently I then fairly quickly decided to try that alternative approach but I'm not sure if that was because the first one didn't work or I just thought it was better to hash earlier.

The original problem was that the change to storing attributes instead of user records in the sessions in 898a388 had broken password recording for new users because only one copy made it to the filter.

from openstreetmap-website.

I think this has something to do that these two alternatives do not produce the same results:

self.current_user = User.new(user_params)
user1 = current_user
# user1.pass_crypt_confirmation is preserved

self.current_user = User.new(user_params)
user2 = User.new(current_user.slice(...,"pass_crypt_confirmation"))
# user2.pass_crypt_confirmation == nil, even though hash contains the key

I updated #4455 with fix for this issue.

from openstreetmap-website.

Yes it's because the confirmation field is not real field that is in the database so attributes doesn't include it and moving the encryption earlier was my attempt to fix that at one in the morning when I was trying to get to bed...

from openstreetmap-website.