Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Login fails using IE 11 #908

Closed
andreaswig opened this issue Aug 9, 2018 · 9 comments

Comments

@andreaswig
Copy link

commented Aug 9, 2018

As described in forum thread Q5RxNnzblI8, IE 11 has a problem with the current implementation of the form-submission in "/modules/core/templates/loginuserpass.php". The login form is acutally submitted twice, causing the authentication process to fail.

Proposed solution: The form-tag should be changed to

<form action="?" method="post" name="f" onsubmit="document.getElementById('samlloginbutton').setAttribute('disabled', 'disabled');">

and the button-tag should be changed to

<button class="btn" id="samlloginbutton" type="submit" tabindex="6">

(FYI: Changing the "value"-attribute of the button in its "onclick"-event does not have any effect since it does not change the text between the opening and closing "button"-tag. That's why this is not covered by the proposed solution...)

@tvdijen

This comment has been minimized.

Copy link
Member

commented Aug 23, 2018

I'm on IE11 and I can't reproduce this...

@tvdijen tvdijen added the needsinfo label Oct 13, 2018
@andreaswig

This comment has been minimized.

Copy link
Author

commented Nov 3, 2018

This issue is tagged as 'needsinfo', so please let me know what you need from me. Can you at least reproduce in the log that the IdP receives the call twice?

FYI: In my company, IE11 is the chosen standard browser (I know...) and the bug was reported to me by about 10 different people. Plus I had the same problem from my private laptop running IE11. After I changed the template as described above, the issue has not occured again. It's strange that you can't reproduce the problem. But since someone commented on my solution that it saved his day, I suppose I'm not the only one...

@thijskh

This comment has been minimized.

Copy link
Member

commented Nov 21, 2018

it needs someone to be able to reproduce the issue so they can decide on a proper fix and test it.

@jackmagielse

This comment has been minimized.

Copy link

commented Feb 28, 2019

I have the same problem. I use version 1.16.2 See logging below. It seems that in explorer the submit is triggered twice at the same time. The loading state line appears twice. The first is with the original session number. The second is with a new session number.

Logging of succesfull attempt in firefox
Feb 28 14:43:15 simplesamlphp DEBUG [144b9de545] </samlp:Response>
Feb 28 14:43:15 simplesamlphp DEBUG [144b9de545] Localization: using old system
Feb 28 14:43:15 simplesamlphp DEBUG [144b9de545] Loading state: '_282b346407aff5ca52a29970d54895117ecc9f7e1e:https://bla.bla.nl'

Logging of unsuccesfull attempt in Explorer
Feb 28 14:27:39 simplesamlphp DEBUG [f1af7a463e] </samlp:Response>
Feb 28 14:27:39 simplesamlphp DEBUG [f1af7a463e] Localization: using old system
Feb 28 14:27:39 simplesamlphp DEBUG [f1af7a463e] Loading state: '_ae3aafb0c64828c8826cb560d5fa7e888339ab3127:https://bla.bla.nl'
Feb 28 14:27:39 simplesamlphp DEBUG [a7a3e90c27] Loading state: '_ae3aafb0c64828c8826cb560d5fa7e888339ab3127:https://bla.bla.nl'
Feb 28 14:27:39 simplesamlphp WARNING [a7a3e90c27] Missing AuthToken cookie.
Feb 28 14:27:40 simplesamlphp DEBUG [a7a3e90c27] Session: 'example-sql' not valid because we are not authenticated.

@tvdijen

This comment has been minimized.

Copy link
Member

commented Mar 5, 2019

Googling brought me this interesting post on StackOverflow: https://stackoverflow.com/questions/38435119/state-information-lost-simplesamlphp

@jackmagielse Your case may also be a case of IE handling cookie domains differently than other browsers.. Subdomains may cause issues: https://stackoverflow.com/questions/18492576/share-cookie-between-subdomain-and-domain

Perhaps more interesting is: does Andreas' proposed fix work for you?

@jackmagielse

This comment has been minimized.

Copy link

commented Mar 6, 2019

@thijskh

This comment has been minimized.

Copy link
Member

commented Mar 7, 2019

Good to know that it helps, but the idea add X-UA-Compatible: IE=8 to our pages does not strike me as a future proof solution.

I would be curious to know if it still happens in 1.17. And whether it happens when enabling the usenewui config option in 1.17.

tvdijen referenced this issue Jul 30, 2019
Make it a bit better for those with javascript disabled, and add a CSP.
@timconner

This comment has been minimized.

Copy link

commented Sep 14, 2019

I think ran into this problem as well. I'm using SSP for federating Office 365. Anytime a non-browser application on Windows needs to authenticate (PowerShell, Outlook desktop app) it pops up a chromeless browser window which I am fairly certain is using IE. Well, there is no way to submit the form on loginuserpass.php. Pressing enter nor clicking Login works. I was able to fix this by changing the Login button.

Current:
<button id="submit_button" class="btn" tabindex="6"><?php echo $this->t('{login:login_button}'); ?></button>

My Edit:
<input type="submit" id="submit_button" class="btn" tabindex="6" value="<?php echo $this->t('{login:login_button}'); ?>" />

I haven't had a chance to test usenewui.

@timconner

This comment has been minimized.

Copy link

commented Sep 14, 2019

Looking at this again, it might be all that's needed is to add type="submit" to the button. And it looks like that is done in the newer twig file.

@jaimeperez jaimeperez added this to the 1.18 milestone Sep 16, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.