Prevent repeated login attempts
Description
Environment
is related to
Activity
r7920
Slightly more portable way to do it, though I think Safari is still not really fixable. It has timing issues with buttons and I think it triggers the submit before the event has a chance to fire.
Actually that's not a standard DOM feature, so no, that won't fly. I'll play a bit, and park otherwise.
r7919
Changing the button text on an example page is harmless enough I'd say.
Noting that I should run the proposed changes through the Sauce Labs browser tests, it would be nice to catch the same error as described in comment #1.
The (large) institution that was affected by the issue above now also has some experience with the proposed solution of disabling the login button. Their finding was that apparently the solution did not working reliably for all web browsers (they got reports from users that had issues). Therefore, they modified the code above to:
<button onclick="document.getElementById('LoginButtonText').innerHTML='Signing in, please wait...';">
<span id="LoginButtonText">Sign in</span>
</button>
This won't disable the button but changes the text of the button by giving the user an immediate feedback of what is going on after the click. Apparently, this seems to work quite well. No user reports or other problems anymore. Therefore, I suggest to use this text change as well for the default login page but not disable the login button.
Copied from IdPv2 issues (https://issues.shibboleth.net/jira/browse/SIDP-617#comment-17688) on request from Scott:
We recently debugged a case where many users got a Shibboleth error message after authenticating at the IdP. All we found is: In the Shibboleth IdP there were many "No login context available, unable to return to authentication engine" even though the users used the correct login links and they most certainly had at a valid session cookie just before they entered their credential. But there were no error messages.
The cause of this seems to be that - due to many users logging in at the same time due to an online exam - the authentication and redirect back to the SP took several seconds. Probably the SP has not responded for several seconds after the click on the login button and the redirect but the login page of the IdP still was shown in the user's web browser.
Therefore, some impatient users clicked again on the login button even though they already were authenticated by the IdP and their IdP login context already was destroyed by the IdP.
To prevent this potential error, one simple workaround could be to disable the submit button on the login page after the form was submitted.
This could be implemented and added to the default templates for v3 with something like:
<button class="form-element form-button" type="submit" name="_eventId_proceed" onclick="this.disabled=true;this.innerHTML='Logging in, please wait...';">Login</button>