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
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
2. Got error page
Client state could not be verified
And js errors in LocalStorageUserStore, find details in attachment
2. No errors
Created attachment 1432988 [details]
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.
> problem on only one browser
This one browser is quiet popular and the only one we support in RHEL.
> 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.
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.
> 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?
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.
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.