CAS login page is no longer password manager friendly

[Sam Hough]

Hi,

We upgraded to 5.1.x yesterday and I've received this issue from a user:

The new 'login' button is trying to be too clever - it prevents you from clicking on it when you haven't 'typed' something in the password box.

This makes it fail to log in when you use a password manager (which we should be encouraging everyone to do).

The only way I can get the CAS login page to work is to type an extra character after my password manager enters my password, then delete that character.

The CAS login page should be fixed to accept enter as 'login with these credentials' as it did before.

Could this be a local installation problem or could we turn it off somehow? My only current idea is to replace the disableEmptyInputFormSubmission function with something empty.

Any tips?

Cheers

Sam

[Andrew Marker]

Hi all,

When the IOS password safe inserts values into the username/password fields it doesn't trigger the onChange JavaScript code that is intended to re-enable the submit button.

https://github.com/apereo/cas/blob/5.2.x/webapp/resources/static/js/cas.js#L137

We've overridden the theme for our CAS 5.2.X login form with our University Look and Feel.  We do however use the delivered JavaScript form validation for users.  We have a large population of  users that leverage the IOS and among those, many use the iOS password safe.  They are have trouble signing into services through CAS.  If the user clicks into the actual fields and re-enters or changes the username or password manually, the button will enable.

-----

For the time being, I've just disabled this JS logic and added HTML5 validation to the form.  There is a server side validation workflow to catch this it seems too.  

The HTML 5 validation works fine with the standard browsers most people use on desktops and even phones, but I have discovered that some mobile apps that use some type of webkits to execute these browser based log in actions don't support the HTML 5 validation strategy.  In this case the server side validation satisfy the need, but doesn't stop the extra traffic.

An example of this would be the Blackboard Mobile app.

----

I like what the CAS provided validation is doing, but it may be a better strategy to execute this on the submit action rather than having an onChange registered for the inputs themselves to change the button state. I too would like to know if others have resolved this in a better way.

Thanks,

Andrew Marker