Redirects in Che plugin registry not covered by Access-Control-Allow-Origin header

[filipkroupa]

Describe the bug

Che plugin registry configuration provides some redirections, eg.
http://<plugin-registry-che>/plugins/ redirects to http://<plugin-registry-che>/v3/plugins/

Using the redirect address would result in CORS violation

Access to XMLHttpRequest at 'http://che-plugin-registry-che.10.108.127.216.nip.io//plugins/' from origin 'http://che-che.10.108.127.216.nip.io' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

Reason is that the redirect address response does not have the Access-Control-Allow-Origin header.

[root@czprapd-chenext ~]# curl --head http://plugin-registry-che.10.108.127.216.nip.io/plugins/
HTTP/1.1 302 Found
Server: openresty/1.15.8.2
Date: Fri, 21 Feb 2020 13:56:57 GMT
Content-Type: text/html; charset=iso-8859-1
Connection: keep-alive
Location: http://plugin-registry-che.10.108.127.216.nip.io/v3/plugins/

Only request directly to v3/plugins has the right header

[root@czprapd-chenext ~]# curl --head http://plugin-registry-che.10.108.127.216.nip.io/v3/plugins/
HTTP/1.1 200 OK
Server: openresty/1.15.8.2
Date: Fri, 21 Feb 2020 13:56:47 GMT
Content-Type: application/json
Content-Length: 74388
Connection: keep-alive
Vary: Accept-Encoding
Accept-Ranges: bytes
Access-Control-Allow-Origin: *
Access-Control-Allow-Headers: Authorization
Pragma: no-cache
Cache-Control: max-age=0, no-cache, no-store, must-revalidate
Expires: Mon, 10 Apr 1972 00:00:00 GMT

Please note that this is not just theoretical issue, since the redirect address is actually used if Che is deployed using chectl with custom plugin registry provided by parameter --plugin-registry-url=.
(see steps to reproduce)

Che version

• latest
• nightly
• other: please specify

Steps to reproduce

1. Start Che with custom plugin registry URL, using command chectl server:start --multiuser --platform=minikube --plugin-registry-url=http://<che-plugin-registry-URL>
2. Login to Che
3. Open Get Started view
4. Choose any stack, perform Create & Proceed editing
5. Error messages pop-up: Failed to load plugins. Failed to load editors.
6. In browser console, error is shown: Access to XMLHttpRequest at 'http://<che-plugin-registry-URL>//plugins/' from origin 'http://<che-che-URL>' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

Expected behavior

Plugin registry should return contents even on provided redirect addresses.

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)
• other: (please specify)

[root@czprapd-chenext ~]# minikube version
minikube version: v1.6.2
commit: 54f28ac5d3a815d1196cd5d57d707439ee4bb392

[root@czprapd-chenext ~]# kubectl version
Client Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.2", GitCommit:"59603c6e503c87169aea6106f57b9f242f64df89", GitTreeState:"clean", BuildDate:"2020-01-18T23:30:10Z", GoVersion:"go1.13.5", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.0", GitCommit:"70132b0f130acc0bed193d9ba59dd186f0e634cf", GitTreeState:"clean", BuildDate:"2019-12-07T21:12:17Z", GoVersion:"go1.13.4", Compiler:"gc", Platform:"linux/amd64"}

Screenshots

Installation method

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

Environment

• my computer
  • Windows
  • Linux
  • macOS
• Cloud
  • Amazon
  • Azure
  • GCE
  • other (please specify)
• other: custom VM, CentOS, minikube on docker

Additional context

Based on this documentation I was able to quick-fix this issue by modifying .htaccess file and providing always condition to Access-Control-Allow-Origin header

Header always set Access-Control-Allow-Origin "*"

This is my suggested fix for this issue

[davidwindell]

I've just come across this after upgrading from 7.15.1 to 7.16.1 (Kubernetes deployment).

This completely breaks the plugin list on Che.

[davidwindell]

I've had to go further to fix this than the "always", for some reason apache was redirecting to non-https, so I changed the redirects in the .htaccess file to:

Redirect temp /plugins https://plugin-registry-che.my.che.domain/v3/plugins
Redirect temp /resources https://plugin-registry-che.my.che.domain/v3/resources

@tolusha I think this is going to cause problems for other users upgrading from 7.15. I feel like #17392 might have broken it.

EDIT: I am using multi-host strategy so /v3 doesn't end up in the config URL

[tolusha]

@davidwindell
Do you use custom plugin registry as well ?

[davidwindell]

@tolusha no I use the default kubernetes deployment

[tolusha]

@davidwindell
7.16.1 isn't released yet
I've checked updating from 7.15.1 to 7.16.0 and didn't face any problem.

@dmytro-ndp
Do we do any tests with custom plugin registry?

[tolusha]

@filipkroupa
Can you confirm that custom plugin registry is run over http and che over https?

[davidwindell]

According to Github it's released :D I don't think HTTP is the issue, it's the fact that in multi-host mode, the new template doesn't apply /v3/ to the URL in the configmap.

[tolusha]

@davidwindell
I got the problem. I will try to provide a fix.

[filipkroupa]

@tolusha No, I'm running both over https. I have some other modifications to plugin registry configuration files when https became mandatory

[filipkroupa]

@tolusha I've updated the changes I currently have in my private build of plugin registry to a branch in my fork, you can check if any of it would help you eclipse-che/che-plugin-registry@master...filipkroupa:custom-registry-cors-https

[tolusha]

@filipkroupa
Could you check pls, if adding /v3 to CHE_PLUGIN_REGISTRY_URL in che configmap can simply fix the problem?

[jamecaes]

For me, adding /v3 to CHE_PLUGIN_REGISTRY_URL on configmap and destroy previous pod, fix my problem!!!!

[che-bot]

Issues go stale after 180 days of inactivity. lifecycle/stale issues rot after an additional 7 days of inactivity and eventually close.

Mark the issue as fresh with /remove-lifecycle stale in a new comment.

If this issue is safe to close now please do so.

Moderators: Add lifecycle/frozen label to avoid stale mode.