Rails simple_form remember password input

Question

With rail's simple_form gem:

If I have = f.input :password, :required => true then whenever I submit the form and it contains errors, my input for the password is gone on page reload. If I use = f.input :password, :required => true, :as => :text it all works like expected, so clearly there's a different handling for password fields.

How to remember values for password fields?

EDIT: some people don't seem to understand that I'm talking about redisplaying the same form with values previously entered. This question has NOTHING to do with database, in fact nothing is even saved in the database in that scenario. For the PHP people, this is the equivalent of <input name="pass" type="password" value="<?= $_POST['pass']; ?>">

Answer 1

About the question, the answer is to use input_html: { value: @user_password }

Like this:

<%= f.input :password, :required => true, input_html: { value: @user_password } %>
<%= f.input :password_confirmation, :required => true, input_html: { value: @user_password } %>

About the secondary topic on restoring password value, after investiguation it's really more like an extra little security bump. The real security is done by using HTTPS, or by having the password hashing done client side with javascript that way the server doesn't even knows about the password.

For examples, even websites as big as https://github.com/join seems to do it the way I'm doing it (fill the password but input an invalid email and see the password being filled as a plain HTML value element).

The corresponding route and controller can look like:

routes.rb :

devise_for :users, :controllers => {registrations: 'users/registrations' }

registrations_controller.rb :

class Users::RegistrationsController < Devise::RegistrationsController
  # build_resource is called inside the new and create methods
  def build_resource(*args)
    if params[:user]
      # So that the password isn't blanked out when the other validations fail. User shouldn't have to retype the password.
      @user_password = params[:user][:password]
    end
    super
  end
end

Answer 2

This is not a SimpleForm behavior, it's in the way Rails treats inputs of password type (see http://api.rubyonrails.org/classes/ActionView/Helpers/FormHelper.html#method-i-password_field).

SimpleForm uses the rails password_field method which defaults to a blank value. The API clearly says to set the value through options parameter.

Answer 3

I don't know exactly how Rails handles this but if I were writing this manually, say in PHP, then to get entered form data back into the form, after a validation error, then I would have to render the data back into each input's value attribute.

There is nothing technically preventing me from doing that with password inputs but it would mean that I would have to pass their own password back to them, in plain text. This, I think, is a deal breaker, because it provides another opportunity for the password to get intercepted.

After reading around on this subject, it seems that a number of people consider this to also be a form of "storing" the password in plain text which is clearly bad. However, it is not at all clear to me why it is considered "storing" a password as the server clearly would not need to store the plain text password anywhere, beyond in the very same variable that was used to receive the plain text password in the first place. However, it may be that they mean that the password is stored in the HTTP response which is then essentially the same concern that I raise above.

Another reason I have seen is that to insert the password back into the password input would require using the value attribute. Whilst this would obscure the password in the rendered input, the password would be visible when inspecting the source using e.g. Firebug. For me, this is a non-issue because it is trivial to turn the type of an input from password to text and reveal the password anyway, or just use JS. It is absolutely incorrect to think that a password field provides much built in security beyond obscuring the password visually.

What you could do is:

1. Hash the password (presuming it, itself, passes validation) and store that even if the rest of the data fails validation
2. Disable the password fields on the returned form or otherwise indicate to the user that the password they have submitted has been accepted but the rest of the form data needs to be fixed.
3. Optionally provide a way for the user to reactivate the password fields, if they decide they want a different password.
4. Run a cron task that regularly cleans the database of any orphaned password entries where a user, for whatever reason, didn't bother to continue signing up but did submit the form with errors, at least once.

I can't immediately see how that would compromise security in any way.

Another approach would be to have a multi-step form and have the password and password confirmation inputs on their own, in the last step. That way, you can ensure the rest of the data is valid by the time the user has reached the password stage and if they have any errors in their passwords (for example the password and password confirmation do not match) then you could argue it is reasonable to then render both fields blank as the user won't be able to easily fix the problem with the passwords obscured.