Bug 1575849 - Meet 'Client state could not be verified' error when reloading pages
Summary: Meet 'Client state could not be verified' error when reloading pages
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Management Console
Version: 3.10.0
Hardware: Unspecified
OS: Unspecified
medium
low
Target Milestone: ---
: 3.11.0
Assignee: Samuel Padgett
QA Contact: Yadan Pei
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-05-08 05:47 UTC by Yadan Pei
Modified: 2019-09-05 16:25 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-06-04 20:15:06 UTC
Target Upstream Version:


Attachments (Terms of Use)
JSError (213.83 KB, image/png)
2018-05-08 05:48 UTC, Yadan Pei
no flags Details

Description Yadan Pei 2018-05-08 05:47:49 UTC
Description of problem:
Get error "Client state could not be verified" when reloading pages using FF58/59

Version-Release number of selected component (if applicable):
Reproduces on FF58 & 59
v3.10.0-0.32.0

How reproducible:
Always

Steps to Reproduce:
1.Open OpenShift web console URL and login at the first time(if you've already login, logout and then login again)
2.After successful login, CTRL +R to reload the page

Actual results:
2. Got error page
Error
Invalid request
Client state could not be verified
And js errors in LocalStorageUserStore, find details in attachment

Expected results:
2. No errors

Additional info:

Comment 1 Yadan Pei 2018-05-08 05:48:32 UTC
Created attachment 1432988 [details]
JSError

Comment 2 Samuel Padgett 2018-05-08 19:19:08 UTC
This is a problem on only one browser, and it's not a normal user flow. It also doesn't break anything since clicking "Return to console" works around the problem. It's also not a regression. Given all of the above, lowering the severity.

Best I can tell this is an AngularJS bug with $location.replace() in Firefox. Reloading the page uses the previous URL instead of the new URL in the history, which results in the error.

Comment 3 Yadan Pei 2018-05-09 01:43:51 UTC
Make sense

Comment 4 Aleksandar Kostadinov 2018-05-11 15:33:10 UTC
> problem on only one browser

This one browser is quiet popular and the only one we support in RHEL.

Comment 5 Samuel Padgett 2018-05-11 16:04:55 UTC
> This one browser is quiet popular and the only one we support in RHEL.

What is the use case for logging in and then immediately refreshing the page?

This appears to be a bug in either Firefox or AngularJS that I'm not sure we can work around.

Comment 6 Aleksandar Kostadinov 2018-05-11 17:07:19 UTC
I actually hit the issue trying to login for the first time. But it is probably related to bug 1573826 that I learned for after my first comment.

I agree that the described workflow is a weird one. The question is whether this is just a simple reproducer while issue is occasionally hit during other interactions. I'll defer to Ya Dan Pei to say whether this is the case.

For me the issue boils down to the following:
1. Console URL in master config is different from domain name used by user to access it (it can happen due to different resons).
2. user enters login credentials
3. the error message occurs
4. user clicks return to console
5. again enters credentials
6. things now work with the updated console URL

It would be nicer if this extra error is spared for the users. And they can login from the first time even though it can be argued that's a user/config error. Whether console redirects automatically to the configured hostname or keeps user provided hostname - perhaps that's not so important.

I agree it is not a critical issue but I think it's worth making UX smoother at it. I don't know about score presently given, maybe it was the right one.

Comment 7 Samuel Padgett 2018-05-11 17:11:39 UTC
> The question is whether this is just a simple reproducer while issue is occasionally hit during other interactions.

They're two different underlying causes.

> Console URL in master config is different from domain name used by user to access it 

You're running into bug 1488394. The way we implement login, there isn't a good way for us to support this. You must use the public URL.

> (it can happen due to different resons).

Is there a use case for it?

Comment 8 Aleksandar Kostadinov 2018-05-11 17:41:26 UTC
Thanks for pointing me at bug 1488394. I think that we should try to detect mismatch and correct it. As in the example there with using http instead of https. When typing, user usually only uses hostname and that defaults to HTTP for browsers. This is one example. Or using www or not in front of url.

Another use case is changing domain of a service but you want to still support original domain name until users are educated.

I've seen many services redirect to canonical URL and *not* failing on login.

Comment 9 Samuel Padgett 2019-06-04 20:15:06 UTC
We've replaced the console in 4.1 with a new version, which does not have this problem. We do not plan to fix this issue in the 3.10/3.11 console.


Note You need to log in before you can comment on or make changes to this bug.