Login fails using IE 11

[andreaswig]

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]

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

[andreaswig]

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]

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

[jackmagielse]

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]

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]

I added header('X-UA-Compatible: IE=8'); after header('X-Frame-Options: SAMEORIGIN'); In \templates\includes\header.php and this seems to work. I can login in explorer with no problems now. Met vriendelijke groet, Jack Magielse 3BM IT-Solutions BV Bergrand 218 4707 AT Roosendaal Tel: 0031 (0)165 595030 Fax: 0031 (0)165 595031 Mobiel: 0031 (0)6 20030749 Email: jack.magielse@3bm.nl<mailto:jack.magielse@3bm.nl> Van: Tim van Dijen [mailto:notifications@github.com] Verzonden: dinsdag 5 maart 2019 20:51 Aan: simplesamlphp/simplesamlphp CC: Jack Magielse; Mention Onderwerp: Re: [simplesamlphp/simplesamlphp] Login fails using IE 11 (#908) Googling brought me this interesting post on StackOverflow: https://stackoverflow.com/questions/38435119/state-information-lost-simplesamlphp @jackmagielse<https://github.com/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 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#908 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/At3aLEXDNLud9F2HwEy4o4OtMcIXJaLMks5vTsqcgaJpZM4V1qkI>.

[thijskh]

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.

[timconner]

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]

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.

[restena-sw]

We are using 1.18 with usenewui and still see this behaviour (Invalid AuthToken cookie in log file, happening only in Intenet Explorer latest).
Interestingly enough this is not always happening. Users get hit by this 50% of time and bounce back to loginuserpass; the rest of the time they continue to the service.

I have seen this on multiple machines (well, all Win 10 1909 VMs running in Fusion).

Since twig sets type=submit, this seems not sufficient.

I would set the X-UA-Compatible: IE=8 if I knew where to inject headers when using newui...

[tvdijen]

Hi Stefan! Have you tried adding the onsubmit to the <form>-tag as suggested in the initial post?
Adding the X-UA header should not be the answer...

[restena-sw]

This helped, sort of. After doing the change, a full reload and verifying that the loaded page contains the JS, I still saw it happening occasionally for a few minutes after the change (so did my colleague on his device).
But then after a bit of wait we can't reproduce it any more.
I know that this sounds strange. But that's how it is :-/

[tvdijen]

It's been strange from the start, that's why there's no real fix yet.,
Given the fact the Microsoft actively discourages the use of IE in favor of Edge, I'm not sure we should put any effort in it..

[restena-sw]

Agree. I like the "fix" because it makes less people who still love IE turn up at our helpdesk but I'm not prepared for a much deeper investigation. If there's no easy fix, our advice is to move on to a real browser.

[tvdijen]

Am I invited to sit at your helpdesk with a bucket of popcorn? 🤣 ...

[restena-sw]

So far I can confirm that people with IE still have the same problem despite the form disable fix. They aren't many, and surprisingly enough, they typically don't mind switching browsers. We've also sent a broadcast mail that "ancient browsers" are not to be used. No uproar on that either.

[cg-lux]

I think ran into this problem as well. I'm using SSP for federating Office 365.

I have the same problem unsing SSP with our O365 tenant. @timconner do you have found a working solution with the Microsoft products?

[timconner]

I think ran into this problem as well. I'm using SSP for federating Office 365.

I have the same problem unsing SSP with our O365 tenant. @timconner do you have found a working solution with the Microsoft products?

@cg-lux I believe I just added type="submit" to the submit button in /modules/core/templates/loginuserpass.php.

[tvdijen]

We have already added the type in 1.17