5

I'm currently learning Laravel and I'm creating a register form. When the form has errors I want to repopulate the input fields with their old values.

My form looks like this:

<form method="post" action="/users/store">
    @csrf
    <input type="text" name="username" value="{{ old('username') }}">
    <input type="email" name="email" value="{{ old('email') }}">
    <input type="password" name="password" value="{{ old('password') }}">
    <input type="password" name="password_confirmation" value="{{ old('password_confirmation') }}">
    <button class="btn btn-outline-warning" id="registerConfirm">Confirm</button>
</form>

For readibility I removed all labels, classes and ids from the input files.

It looks like Laravel doesn't 'want' to repopulate input fields with the old password filled in. The reason I feel this is true is because the username and email do work but both password fields don't. Whenever I change the password fields to text fields and change the name from password to something like 'asdasd' it does work.

My question is: Is my theory correct and if so, why does Laravel do this? Is it security related? Thanks in advance!

I looked at the docs for the old method but it doesn't say anything about passwords.

Kerwin Sneijders
  • 750
  • 13
  • 33

2 Answers2

19

Laravel intentionally blocks password and password_confirmation. Generally it is good practice not to return the password back to the user. It does this in it's exception handler.

If you really want to include it, update your app/Exceptions/Handler.php file to remove password and password_confirmation from the dontFlash array.

George Hanson
  • 2,940
  • 1
  • 6
  • 18
  • 2
    Thanks! That was the information I was looking for! I didn't know it was a *bad practice* in general. Won't be removing it from the array. (Waiting for SO to allow me to mark this as the answer...) – Kerwin Sneijders Apr 23 '19 at 14:42
  • No problem. I'm glad it helped – George Hanson Apr 23 '19 at 14:48
  • 1
    It would be good if it was available on a case by case basis. I've just run into this, and normally wouldnt display passwords as yes, that makes sense, but at the same time storing logins and passwords for other things then gets hit by this issue. For now I'll rename the field, but the point is this particular case was requiring the form to store and display passwords for an external use. Might also talk to the team and find out if they need to store this info in the site I'm making or if it would be better stored elsewhere. – rbnzdave Feb 26 '20 at 02:00
  • Is it possible to prevent this in the controller? What about creating a user with a password in the backend with a typo (not matching) and you have to retype it again. In that case, it would be handy to the administrator to not flash the passwords - or is this also bad practice? – SiL3NC3 Mar 18 '22 at 08:54
2

Yes, that's correct. It is security related. password is a special field type, and as such, it should neither display the value nor populate the field with the old value. In fact, I would strongly recommend against overriding this default behavior, for security reasons.

Your browser, on the other hand, may store and pre-populate password fields for you, depending on settings.

MrMoxy
  • 392
  • 4
  • 13
  • Thanks for the answer, I generally never override default behaviour if it's security related so won't be changing this either. That said, changing the field type to `text` doesn't change the output. Like George Hanson said in his answer, password and password_confirmation are 'blacklisted' from this feature. – Kerwin Sneijders Apr 23 '19 at 14:46