Field label in page editor not shown for Password field type

[bracketfire]

I stumbled upon something last night that tripped me up for an hour or so.  I'm using 2.3.

I've added a field, temporary_password, to the system's User template to hold the temporary one sent when they click forgot password (from the front end).

It's label is "Temporary Password".

But when editing a User, I see two "Set Password" fields, one is the standard password and one is the new one I added.

I had been setting the wrong one by mistake and then couldn't figure out why that user couldn't log in.

It looks like for some field types the label set in the field's setup isn't shown?  Does a Password field always show "Set Password" ?

The Description is shown properly once the field is pulled down, so they can be distinguished now that I know.  But it seemed inconsistent that some field show their Label and others appear to show some standard one?

[ryan]

I'm thinking you probably don't want to use FieldtypePassword for your temporary password. I'm not sure PW will even support two of them in the same template. For a temporary password, I'd probably keep it in the $session rather than in a page field (session variables are temporary server side storage, with the data not present in the cookie). Since it's temporary, you don't really need it to have a permanent representation in the DB. This would also ensure the temporary password automatically expires with the session. Just don't ever show the user that password from the session, only use it to compare with one you've sent to them by some other means like email. 

[bracketfire]

I agree with what you've said.  In fact, after reading this insanely exhaustive write-up about password reset techniques, http://www.troyhunt.com/2012/05/everything-you-ever-wanted-to-know.html, I think it might be best to send the user a reset link that's only active for a few hours, and have them pick a new password rather than emailing them a temporary one.

[ryan]

I'm not sure there's really much difference in sending them a reset URL or a password, as neither is encrypted once it goes out in an email. Though I prefer to use a unique reset URL, as it's less work for the user. Expiring that URL is definitely a good idea. I don't see it often used, but I also like to limit the usage of that URL or password to the session that initiated the request. Meaning, when you request the password reset, you get a unique token set in the session, along with a timestamp of when it was set (so you can determine when it should no longer be valid). This token can be the same as the unique URL you sent them. When the user comes back from the URL they clicked on in the email, the request is only honored if the token you set in the session is still active and matches with the URL they requested. Using this method provides a better accounting for the fact that email is inherently insecure.