Che: Workspace does not open - stuck in "Loading a runtime token..."

[philipreimer]

Describe the bug

Opening a workspace doesn't work. It is stuck in "Loading a runtime token...".

Che version

• [ ] latest
• [ ] nightly
• [x] other: 7.3.2

Steps to reproduce

1. Go to https://www.eclipse.org/che/getting-started/
2. Click "Create free account"
3. Select any of the pre-defined workspace templates, e.g. angular
4. After setting up your account, try to open the workspace
5. Loading / Opening the workspace is stuck in "Loading a runtime token...".

Expected behavior

Workspace should open, I assume I should see some kind of code editor.

Runtime

• [ ] kubernetes (include output of kubectl version)
• [ ] Openshift (include output of oc version)
• [ ] minikube (include output of minikube version and kubectl version)
• [ ] minishift (include output of minishift version and oc version)
• [ ] docker-desktop + K8S (include output of docker version and kubectl version)
• [x] other: https://che.openshift.io/

Screenshots

Installation method

• [ ] chectl
• [ ] che-operator
• [ ] minishift-addon
• [x] I don't know

Environment

• [ ] my computer
  
  
  
  • [ ] Windows
  
  
  • [ ] Linux
  
  
  • [ ] macOS
  
  
• [x] Cloud
  
  
  
  • [ ] Amazon
  
  
  • [ ] Azure
  
  
  • [ ] GCE
  
  
  • [x] other https://che.openshift.io/
  
  
• [ ] other: please specify

Additional context

[mikeysb2]

Exactly the same problem here

[got4416]

I use Google Chrome.
Same problem, but fixed when reset the experimental features.
If it's the same situation, try it.

chrome://flags/ -> "Reset all to default"

[got4416]

And "*.openshiftapps.com" cookie blocked?
Try allow it.

[amisevsk]

Please also double check that your adblockers/privacy extensions aren't blocking connections -- since workspace routes have semi-randomly generated names, it can trigger some heuristics.

[ibuziuk]

yeah, please take a look at FAQ - https://github.com/redhat-developer/rh-che/blob/master/FAQ.adoc#can-not-login-to-che-openshift-io-authorization-token-is-missed

[philipreimer]

I use Firefox and I block 3rd party cookies. After allowing cookies from openshiftapps.com the workspace is now loading.

There should be some kind of error message indicating what the problem is.
Just showing a progressbar forever is poor user experience.

BTW, the FAQ does not mention anything about openshiftapps.com

[sttyerase]

I had the same issue using Chrome. It would be helpful to have the FAQ updated when the requirements change. I added the following to my Settings for Cookies and Site Data in Chrome and it worked.

[sleshchenko]

Workspace loader failed to do something, right? Then it must clearly say it and in addition, give a hint that it might be blocked cookies issue.

[sttyerase]

However, the loader did not fail outright. It got stuck in a loop. Perhaps it can perform a pre-check, or we can clarify the documentation.

[JPinkney]

I've just tried opening a workspace on che.openshift.io and I get the Loading a runtime token loop as well.

In the console I've found:

Access to XMLHttpRequest at 'https://routectlqpqce-jpinkney-12-che.8a09.starter-us-east-2.openshiftapps.com/jwt/auth' from origin 'https://che.openshift.io' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

[sleshchenko]

@JPinkney It's another issue. jwtproxy for your workspace seems to be unavailable. Pleasem register a new issue and put devfile there.

[Wisedemic]

This is still happening on: Chromium to 85.0.4183.121.

It's repeat-looping through the authentication cycle, flashing the "Loading a runtime token..." message.

[sttyerase]

@Wisedemic: I'm no longer experiencing the problem after making the adjustment shown in my comment above. However, it would be nice to know this up front as opposed to having to discover it via Google searches. I suppose most developers just accept third party cookies by default.

[philipreimer]

1. as far as a I know, all major browsers already block 3rd party cookies by default or are going in this direction.
2. the workaround to allow cookies from openshiftapps.com is not mentioned in the documentation. You have to google and find this github issue.

Keeping these 3rd party cookies will only turn potential users away from che because it "doesn't work" from their point of view.