Red Hat Bugzilla – Bug 1270436
Could not log in when client clock is > 5 minutes ahead of server clock
Last modified: 2017-11-28 16:51:43 EST
Description of problem:
Login with correct username and password on web console for IE 11.0.9, 11.0.14 and 11.0.19 failed, it stays on the login page instead of directing to home page. But on IE 11.0.7, login is successful
Version-Release number of selected component (if applicable):
Version:11.0.9600.17420 Update Versions:11.0.14
Version:11.0.9600.17801 Update Versions:11.0.19
Version:11.0.9600.16428 Update Versions:11.0.9
Steps to Reproduce:
2.Open web console
3.Login with correct username and password
The console didn't go to home page, instead it stays on the login page and waits for another login, see attachments
Should login successfully
Created attachment 1081510 [details]
This VM is got from Microsoft http://dev.modern.ie/tools/vms/linux/
Created attachment 1081511 [details]
Created attachment 1081512 [details]
Not sure about other versions, only have environment cover version 11.0.7, 11.0.9, 11.0.14 and 11.0.19
I can't reproduce on IE 11.0.9... login works fine (see screenshot)
Can you verify the security and privacy settings are at their defaults?
Tools > Internet Options > Security
Tools > Internet Options > Privacy
Created attachment 1081845 [details]
IE 11.0.9 working.png
Actually, I misread... I have 11.0.14, but it is working fine as far as I can tell.
(In reply to Jordan Liggitt from comment #7)
> Actually, I misread... I have 11.0.14, but it is working fine as far as I
> can tell.
Hi Jordan, I performed "Reset all zones to default level" for "Internet Options -> Security" setting, and compared the "Privacy" setting with 11.0.7 on my machine, they're the same.
But I still can't login, see screen-shots. Any chances to tell me your settings?
All defaults for security and privacy.
Can you capture a fiddler trace of the login flow using the fiddler proxy on the IE VM (http://www.telerik.com/fiddler)?
You'll need to run the installer, start fiddler, set it to capture traffic, and enable the option to decrypt HTTPS traffic (Options > HTTPS > Decrypt). Follow the prompts to create/install a local CA.
Then, with a cleared cache, go through the login flow, then export the fiddler data and attach it.
Created attachment 1081872 [details]
Login captures with fiddler
Created attachment 1081890 [details]
Clean login captures
Can you check if the times in your IE VMs are in sync with your OpenShift server? The session cookies getting sent from the server (which are valid for 5 minutes) are not being returned by IE, and I'm wondering if it's a timestamp sync issue.
times in my failure IE VM are the same with my local machine, take an example
Time in failure IE VM: 10:33 am, 10/13/2015
Time on local machine: 10:33 am, 10/13/2015
Corresponding time in Openshift Server: Tue Oct 13 02:33:24 UTC 2015
I have IE installed on two different VMs, these two VMs keeps the same time, but one could login successful while the other not.
Created attachment 1082223 [details]
Successful login capture
Can you check the timezones in the IE vms match each other? I still wonder if the issue is time related
Good news, found the root cause, here are steps
1)Change the timezones in two IE VMs to "UTC +08:00"，keep the same with my local machine.
In this step, I found that time in failure IE VMs are different with the correct time.
2) So I manually adjusted the time to correct time
After these steps, could login successfully.
Any reason for this time syncing problem?
The session cookie required for login is set to expire after 5 minutes. If the browser's OS is more than 5 minutes ahead of the server, it will expire the cookie immediately and login will fail.
May need to set the cookie for a longer expiration, and an internal timestamp for the short expiration and check session validity ourselves.
Updated title to reflect cause.
Fixed in https://github.com/openshift/origin/pull/13180
Checked on v3.7.0-0.125.0
The issue on IE is fixed, move to VERIFIED
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.