Poor error messages on login and reset password pages if forms are submitted blank

[r0bby (Robby O'Connor)]

I just reported and promptly closed two reports ID-96 and ID-97 which dealt with poor error message and just weird logic. I coded both of them to fail hard using the flash error message to convey the proper error messages to the user. I felt that these errors were pretty bad. We’ll release the fix as part of 2.1 I think? Optionally, we can cherrypick out these changes and do a 2.0.2 release?

• In the case of the login page, it was querying ldap regardless…if no username or password is given…querying ldap is pointless…it now fails fast and displays the appropriate message to the user. – Login Fix
• In the case of the reset password page, it was handled similarly and failing fast using a flash error message… – Reset Password Fix

In both fixes, these functions were added as an async call. the first thing done is we check for empty inputs…and if empty…we fail better than we were.

I am working on refactoring how validation errors are conveyed to the user. This is only tangentially related.

[michael (Michael Downey)]

For the password reset, let’s make sure the difference in error message does not reveal whether or not an account exists. In other words, the same appearance and text (“If an account exists with this information, an email will be sent with instructions”) for all cases.

However if LDAP is not available, I think we should first be checking before displaying the form, and provide an alternative message informing them that self-service password resets are not currently available & instructing them to open a helpdesk case instead.

[r0bby (Robby O'Connor)]

@michael

For the password reset, let’s make sure the difference in error message does not reveal whether or not an account exists. In other words, the same appearance and text (“If an account exists with this information, an email will be sent with instructions”) for all cases.

That behavior doesn’t not change – I didn’t touch that code. This only happened when I submitted an empty form…which is why I added the more accurate error message. That behavior didn’t make sense to me.

@michael

However if LDAP is not available, I think we should first be checking before displaying the form, and provide an alternative message informing them that self-service password resets are not currently available & instructing them to open a helpdesk case instead.

I suppose we could check that and display a better error message in that case.

That said, do you want me to revert this – very easy to do…

[michael (Michael Downey)]

I think it’s probably annoying for someone to fill out the form, and then find out that they’re not able to use the form because of some back end dependency. We could check this before or after the form is submitted, but it seems like it might be smart in this case to check it before. I don’t feel too strongly one way or the other.

However I do feel pretty strongly about the error message consistency not revealing user IDs.

[r0bby (Robby O'Connor)]

@michael

I think it’s probably annoying for someone to fill out the form, and then find out that they’re not able to use the form because of some back end dependency. We could check this before or after the form is submitted, but it seems like it might be smart in this case to check it before. I don’t feel too strongly one way or the other.

That’s easy to fix.

@michael

However I do feel pretty strongly about the error message consistency not revealing user IDs.

My change is only triggered if either username or password is blank…it doesn’t expose user IDs…