error: CORS request did not succeed #306

daiyam · 2021-07-11T00:32:33Z

Hi,

VSCodium-1.58.0 is getting an error message when loading the list of extensions from open-vsx.org.
After debugging, I've reduced the code used to its minimal form so we can test it in the browser(Firefox is consistent unlike Chrome):

(function() {
const xhr = new XMLHttpRequest();

xhr.open('POST', 'https://open-vsx.org/vscode/gallery/extensionquery', true);

xhr.setRequestHeader('X-Market-Client-Id', 'VSCode 1.58.0');
xhr.setRequestHeader('X-Market-User-Id', '27ea627c-eac1-4ae6-92fd-d093b80d1ba5');
xhr.setRequestHeader('Content-Type', 'application/json');
xhr.setRequestHeader('Accept', 'application/json;api-version=3.0-preview.1');

xhr.onload = (e) => {
	console.log(xhr.response);
};

xhr.send('{"filters":[{"criteria":[{"filterType":8,"value":"Microsoft.VisualStudio.Code"},{"filterType":12,"value":"4096"}],"pageNumber":1,"pageSize":50,"sortBy":4,"sortOrder":0}],"assetTypes":[],"flags":950}');
})();

I'm getting:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://open-vsx.org/vscode/gallery/extensionquery. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing).

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://open-vsx.org/vscode/gallery/extensionquery. (Reason: CORS request did not succeed).

If you change the url to https://marketplace.visualstudio.com/_apis/public/gallery/extensionquery, there is no more errors.

The text was updated successfully, but these errors were encountered:

SpacingBat3 · 2021-07-11T21:50:56Z

Seems #284 pull request is being relevant to this issue.

Also, using this extension on Firefox I was able to bypass CORS limitations and successfully get correct answer from the server using the function typed above. Without the extension, CORS configuration fails at the same error as well. So the current workaround (client-side) would be to bypass the CORS configuration the same way the extension does. As VSCode and VSCodium are Electron-based, even the same extension could be injected into VSCodium as a proof of concept (or even analyze the extension and develop similar method of bypassing CORS, as following extension has it's code non-minified and well commented published on GitHub).

EDIT: I've read VSCodium issues and actually forgot about Chromium flags, so it is much simplier just to use flag with commandLine.appendSwitch() API to programatically control VSCodium behaviour about CORS server policy.

daiyam · 2021-07-11T22:29:59Z

@SpacingBat3 thanks for the feedback

For the --disable-web-security flag, since to disable the security for the whole IDE (including the extensions) is a little over the top, I'm against to make it the default.

It's a server's configuration issue and from the client standpoint, the main components haven't much changed from 1.57.1 to 1.58.0:

Chromium: same 89.0.4389.128
Electron: 12.0.7 -> 12.0.13
Node: same 14.16.0

daiyam · 2021-07-13T07:22:00Z

Queries on /api/-/query are also failing due to CORS while /api/-/search is fine.
/vscode/gallery/extensionquery and /api/-/query are POST while /api/-/search is a GET.

jotoho · 2021-07-13T15:04:22Z

I'm unable to check for extension upgrades in version 1.58.0-1 of the archlinux code package, which (to the best of my knowledge) uses openvsx.

Here's the error message in the developer tools:

The error message makes me think some important header is missing in the response from open-vsx.org, which is why I came here instead of the archlinux bugtracker.

daiyam · 2021-07-13T16:06:23Z

@jotoho I've checked vscode and the headers haven't changed between 1.57 and 1.58.
My little example has been extracted from my debug with all the headers/body sent.

eclipsewebmaster · 2021-07-13T16:12:57Z

Is it possible to retry this now?

daiyam · 2021-07-13T16:17:18Z

Still the same. With both VSCodium or my example.

jotoho · 2021-07-13T16:17:46Z

Checking for updates still fails for me with the same error message

jotoho · 2021-07-13T16:28:13Z

@daiyam Maybe some change to a dependency of vscode now requires an extra consideration? (Presumably for security reasons)

daiyam · 2021-07-13T17:30:14Z

@jotoho I don't think so since the code/example is working with the url https://marketplace.visualstudio.com/_apis/public/gallery/extensionquery but not with https://open-vsx.org/vscode/gallery/extensionquery. But I can be wrong.

VSCode is using the built-in XMLHttpRequest from Electron/Chromium to make the query. I should have said that...

jotoho · 2021-07-13T18:35:12Z

@daiyam I don't really understand your tests in the opening post, since I am unfamiliar with the technologies but when I was talking about my suspicion regarding headers I meant the headers sent by the server with the http response and not the headers the client sets.

Would it not be possible that vscode or one of it's dependencies expects a certain header to be sent by the server and does not work correctly without it? If the microsoft marketplace correctly sends those headers along but open-vsx.org does not then that would explain why your tests work against microsofts servers but not against openvsx.

Or am I missing something huge? Like I said, I'm no expert on these apis.

eclipsewebmaster · 2021-07-13T18:53:08Z

If I run the code on Firefox, I get: Content Security Policy: The page’s settings blocked the loading of a resource at https://marketplace.visualstudio.com/_apis/public/gallery/extensionquery (“default-src”). debugger eval code:15:4

eclipsewebmaster · 2021-07-13T19:14:35Z

I've tested buth URLs with curl, as I am not a developer.

curl -v --header "Content-Type: application/json" \
  --request POST \
  --header "X-Market-Client-Id: VSCode 1.58.0" \
  --header "X-Market-User-Id: 27ea627c-eac1-4ae6-92fd-d093b80d1ba5" \
  --header "Accept: application/json;api-version=3.0-preview.1" \
  --header "Origin: open-vsx.org" \
  --data '{"filters":[{"criteria":[{"filterType":8,"value":"Microsoft.VisualStudio.Code"},{"filterType":12,"value":"4096"}],"pageNumber":1,"pageSize":50,"sortBy":4,"sortOrder":0}],"assetTypes":[],"flags":950}' \
  https://open-vsx.org/vscode/gallery/extensionquery

If my request does not specify an Origin: header, both sites (https://marketplace.visualstudio.com/_apis/public/gallery/extensionquery and https://open-vsx.org/vscode/gallery/extensionquery) do not return a access-control-allow-origin header.

If my request DOES specify an Origin header, both sites return a access-control-allow-origin header.

From where I sit, I'm not sure what the expected output is.

daiyam · 2021-07-13T19:16:07Z

@eclipsewebmaster I run it in the console Ctrl+Alt+K or Tools/Web Developer/Web Console

eclipsewebmaster · 2021-07-13T19:18:00Z

daiyam · 2021-07-13T19:26:54Z

Even without the Origin header, curl is working for me:

curl -v --header "Content-Type: application/json" \
>   --request POST \
>   --header "X-Market-Client-Id: VSCode 1.58.0" \
>   --header "X-Market-User-Id: 27ea627c-eac1-4ae6-92fd-d093b80d1ba5" \
>   --header "Accept: application/json;api-version=3.0-preview.1" \
>   --data '{"filters":[{"criteria":[{"filterType":8,"value":"Microsoft.VisualStudio.Code"},{"filterType":12,"value":"4096"}],"pageNumber":1,"pageSize":50,"sortBy":4,"sortOrder":0}],"assetTypes":[],"flags":950}' \
>   https://open-vsx.org/vscode/gallery/extensionquery
Note: Unnecessary use of -X or --request, POST is already inferred.
*   Trying 198.41.30.195:443...
* Connected to open-vsx.org (198.41.30.195) port 443 (#0)
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /opt/local/share/curl/curl-ca-bundle.crt
*  CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* NPN, negotiated HTTP1.1
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Next protocol (67):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: C=CA; ST=Ontario; L=Ottawa; O=Eclipse.org Foundation, Inc.; CN=open-vsx.org
*  start date: Dec 10 00:00:00 2020 GMT
*  expire date: Jan 10 23:59:59 2022 GMT
*  subjectAltName: host "open-vsx.org" matched cert's "open-vsx.org"
*  issuer: C=US; O=DigiCert Inc; CN=DigiCert TLS RSA SHA256 2020 CA1
*  SSL certificate verify ok.
> POST /vscode/gallery/extensionquery HTTP/1.1
> Host: open-vsx.org
> User-Agent: curl/7.74.0
> Content-Type: application/json
> X-Market-Client-Id: VSCode 1.58.0
> X-Market-User-Id: 27ea627c-eac1-4ae6-92fd-d093b80d1ba5
> Accept: application/json;api-version=3.0-preview.1
> Content-Length: 198
> 
* upload completely sent off: 198 out of 198 bytes
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 
< Server: nginx
< Date: Tue, 13 Jul 2021 19:20:39 GMT
< Content-Type: application/json; api-version=3.0-preview.1
< Transfer-Encoding: chunked
< Connection: keep-alive
< Vary: Origin
< Vary: Access-Control-Request-Method
< Vary: Access-Control-Request-Headers
< X-Content-Type-Options: nosniff
< X-XSS-Protection: 1; mode=block
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Pragma: no-cache
< Expires: 0
< Strict-Transport-Security: max-age=31536000 ; includeSubDomains
< X-Frame-Options: DENY
< X-access-control-allow-origin: x
{"results":[{"extensions":[....

I will check again if I haven't missed something...

SpacingBat3 · 2021-07-13T19:37:43Z

@eclipsewebmaster, try to open DevTools on blank page instead opening it on the random ones – most sites has CSP header specified and blocks request from sites outside of it. On Firefox, that would be about:blank page.

daiyam · 2021-07-13T19:47:24Z

I know only basics about CORS... but I was able to see (in Firefox) that before the actual POST request, there is an OPTIONS request. A quick google, I got this: https://developer.mozilla.org/en-US/docs/Glossary/Preflight_request
So I recreated the request:

curl -v \
--request OPTIONS \
--header "Access-Control-Request-Headers: content-type,x-market-client-id,x-market-user-id" \
--header "Access-Control-Request-Method: POST" \
--header "Origin: null" \
https://open-vsx.org/vscode/gallery/extensionquery

For https://marketplace.visualstudio.com/_apis/public/gallery/extensionquery, the response is:

< HTTP/1.1 200 OK
< P3P: CP="CAO DSP COR ADMa DEV CONo TELo CUR PSA PSD TAI IVDo OUR SAMi BUS DEM NAV STA UNI COM INT PHY ONL FIN PUR LOC CNT"
< X-TFS-ProcessId: 643dff84-c32c-4595-a9ca-6dc3b8dd819a
< Strict-Transport-Security: max-age=31536000; includeSubDomains
< ActivityId: eb8c0f7c-4a95-42c4-9dfc-0507fa8d9950
< X-TFS-Session: eb8c0f7c-4a95-42c4-9dfc-0507fa8d9950
< X-VSS-E2EID: eb8c0f7c-4a95-42c4-9dfc-0507fa8d9950
< Access-Control-Allow-Origin: *
< Access-Control-Max-Age: 3600
< Access-Control-Allow-Methods: OPTIONS,GET,POST,PATCH,PUT,DELETE
< Access-Control-Expose-Headers: ActivityId,X-TFS-Session,X-MS-ContinuationToken,X-VSS-GlobalMessage,ETag
< Access-Control-Allow-Headers: content-type,x-market-client-id,x-market-user-id, authorization
< Request-Context: appId=cid-v1:84715e31-583a-4723-a46d-946169b2f4a8
< Access-Control-Expose-Headers: Request-Context
< X-Content-Type-Options: nosniff
< X-Cache: CONFIG_NOCACHE
< X-MSEdge-Ref: Ref A: D4CE2E01A41D4DFE9C5F045FC8A2816A Ref B: LON21EDGE1011 Ref C: 2021-07-13T19:38:16Z
< Date: Tue, 13 Jul 2021 19:38:16 GMT
< Content-Length: 0

There is Access-Control-Allow-Origin: * in the response.

For https://open-vsx.org/vscode/gallery/extensionquery :

< HTTP/1.1 204 No Content
< Server: nginx
< Date: Tue, 13 Jul 2021 19:38:38 GMT
< Connection: keep-alive
< Content-Length: 0
< Vary: Origin
< Vary: Access-Control-Request-Method
< Vary: Access-Control-Request-Headers
< Allow: GET,HEAD,POST,OPTIONS
< strict-transport-security: max-age=31536000 ; includeSubDomains
< x-frame-options: DENY

No Access-Control-Allow-Origin.

It's matching the error we are getting.

SpacingBat3 · 2021-07-13T19:49:20Z

I've tested buth URLs with curl, as I am not a developer.
curl -v --header "Content-Type: application/json" \
  --request POST \
  --header "X-Market-Client-Id: VSCode 1.58.0" \
  --header "X-Market-User-Id: 27ea627c-eac1-4ae6-92fd-d093b80d1ba5" \
  --header "Accept: application/json;api-version=3.0-preview.1" \
  --header "Origin: open-vsx.org" \
  --data '{"filters":[{"criteria":[{"filterType":8,"value":"Microsoft.VisualStudio.Code"},{"filterType":12,"value":"4096"}],"pageNumber":1,"pageSize":50,"sortBy":4,"sortOrder":0}],"assetTypes":[],"flags":950}' \
  https://open-vsx.org/vscode/gallery/extensionquery
If my request does not specify an Origin: header, both sites (https://marketplace.visualstudio.com/_apis/public/gallery/extensionquery and https://open-vsx.org/vscode/gallery/extensionquery) do not return a access-control-allow-origin header.

If my request DOES specify an Origin header, both sites return a access-control-allow-origin header.

From where I sit, I'm not sure what the expected output is.

@eclipsewebmaster seems that Origin header is considered as unsafe, Firefox blocks it for security reasons and I would expect Chromium/Electron is doing the same as well.

SpacingBat3 · 2021-07-13T20:00:05Z

I know only basics about CORS... but I was able to see (in Firefox) that before the actual POST request, there is an OPTIONS request. A quick google, I got this: https://developer.mozilla.org/en-US/docs/Glossary/Preflight_request
So I recreated the request:

curl -v \
--request OPTIONS \
--header "Access-Control-Request-Headers: content-type,x-market-client-id,x-market-user-id" \
--header "Access-Control-Request-Method: POST" \
--header "Origin: null" \
https://open-vsx.org/vscode/gallery/extensionquery

For https://marketplace.visualstudio.com/_apis/public/gallery/extensionquery, the response is:

< HTTP/1.1 200 OK
< P3P: CP="CAO DSP COR ADMa DEV CONo TELo CUR PSA PSD TAI IVDo OUR SAMi BUS DEM NAV STA UNI COM INT PHY ONL FIN PUR LOC CNT"
< X-TFS-ProcessId: 643dff84-c32c-4595-a9ca-6dc3b8dd819a
< Strict-Transport-Security: max-age=31536000; includeSubDomains
< ActivityId: eb8c0f7c-4a95-42c4-9dfc-0507fa8d9950
< X-TFS-Session: eb8c0f7c-4a95-42c4-9dfc-0507fa8d9950
< X-VSS-E2EID: eb8c0f7c-4a95-42c4-9dfc-0507fa8d9950
< Access-Control-Allow-Origin: *
< Access-Control-Max-Age: 3600
< Access-Control-Allow-Methods: OPTIONS,GET,POST,PATCH,PUT,DELETE
< Access-Control-Expose-Headers: ActivityId,X-TFS-Session,X-MS-ContinuationToken,X-VSS-GlobalMessage,ETag
< Access-Control-Allow-Headers: content-type,x-market-client-id,x-market-user-id, authorization
< Request-Context: appId=cid-v1:84715e31-583a-4723-a46d-946169b2f4a8
< Access-Control-Expose-Headers: Request-Context
< X-Content-Type-Options: nosniff
< X-Cache: CONFIG_NOCACHE
< X-MSEdge-Ref: Ref A: D4CE2E01A41D4DFE9C5F045FC8A2816A Ref B: LON21EDGE1011 Ref C: 2021-07-13T19:38:16Z
< Date: Tue, 13 Jul 2021 19:38:16 GMT
< Content-Length: 0

There is Access-Control-Allow-Origin: * in the response.

For https://open-vsx.org/vscode/gallery/extensionquery :

< HTTP/1.1 204 No Content
< Server: nginx
< Date: Tue, 13 Jul 2021 19:38:38 GMT
< Connection: keep-alive
< Content-Length: 0
< Vary: Origin
< Vary: Access-Control-Request-Method
< Vary: Access-Control-Request-Headers
< Allow: GET,HEAD,POST,OPTIONS
< strict-transport-security: max-age=31536000 ; includeSubDomains
< x-frame-options: DENY

No Access-Control-Allow-Origin.

It's matching the error we are getting.

@daiyam I just want to say Access-Control-[Allow/Expose]-Headers are missing as well, and as I tested that on Firefox with mentioned extension earlier, it seems to be required by CORS as well.

SpacingBat3 · 2021-07-13T20:19:25Z

Also @daiyam shouldn't this issue be reopened at EclipseFdn/open-vsx.org? I think this is an issue due to server configuration and issues in OpenVSX repository should about the OpenVSX in general, affecting both open-vsx.org and other marketplaces based on OpenVSX (which could have different server configuration that properly sets CORS).

This is what README.md states:

A public instance of Open VSX is running at open-vsx.org. Please report issues related to that instance at EclipseFdn/open-vsx.org.

eclipsewebmaster · 2021-07-13T20:29:13Z

No Access-Control-Allow-Origin.

It's matching the error we are getting.

I've added the header to the OPTIONS response. Try now?

jotoho · 2021-07-13T20:59:57Z

@eclipsewebmaster Checking for updates still fails for me but the error message is different:

eclipsewebmaster · 2021-07-13T21:03:49Z

That could be an issue with the actual server component, as we don't mangle with Access-control-Allow-Headers at the accelerator/cache level.

daiyam · 2021-07-13T21:39:19Z

I'm getting the following error in Firefox:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://open-vsx.org/vscode/gallery/extensionquery. (Reason: header ‘content-type’ is not allowed according to header ‘Access-Control-Allow-Headers’ from CORS preflight response).

As mentioned by @SpacingBat3, Access-Control-Allow-Origin isn't the only required header. More details here.
CORS in Spring: https://spring.io/blog/2015/06/08/cors-support-in-spring-framework

daiyam · 2021-07-13T21:47:47Z

Seems like something have been changed from client side to validate the CORS policy. I will check that.

If I have time, I will check how to configure CORS with Spring. It's been years that I haven't any Java dev and much more with Spring...

daiyam · 2021-07-14T08:14:11Z

LOL. Starting the project on Gitpod, I get the same error...

Access to fetch at 'https://8080-amber-viper-0lssdfbs.ws-eu10.gitpod.io/api/-/search?size=10&sortBy=relevance&sortOrder=desc' from origin 'https://3000-amber-viper-0lssdfbs.ws-eu10.gitpod.io' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

daiyam · 2021-07-14T08:32:04Z

@eclipsewebmaster The server are correctly configured. I've just tested directly the java server with:

curl -v \
--request OPTIONS \
--header "Access-Control-Request-Headers: content-type,x-market-client-id,x-market-user-id" \
--header "Access-Control-Request-Method: POST" \
--header "Origin: null" \
https://8080-amber-viper-0lssdfbs.ws-eu10.gitpod.io/vscode/gallery/extensionquery

When @CrossOrigin is there (which it is), I correctly get:

< HTTP/1.1 200 OK
< Access-Control-Allow-Headers: content-type, x-market-client-id, x-market-user-id
< Access-Control-Allow-Methods: POST
< Access-Control-Allow-Origin: *
< Access-Control-Max-Age: 1800
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Content-Length: 0
< Date: Wed, 14 Jul 2021 08:25:18 GMT
< Expires: 0
< Pragma: no-cache
< Vary: Origin
< Vary: Access-Control-Request-Method
< Vary: Access-Control-Request-Headers
< X-Content-Type-Options: nosniff
< X-Xss-Protection: 1; mode=block

When removed, I get:

< HTTP/1.1 403 Forbidden
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Date: Wed, 14 Jul 2021 08:24:22 GMT
< Expires: 0
< Pragma: no-cache
< Vary: Origin
< Vary: Access-Control-Request-Method
< Vary: Access-Control-Request-Headers
< X-Content-Type-Options: nosniff
< X-Xss-Protection: 1; mode=block
< Content-Type: text/plain; charset=utf-8
< Transfer-Encoding: chunked

So the server component seems fine.

Not sure what's going on...

ocket8888 · 2021-09-01T14:18:56Z

Still an issue

Access to XMLHttpRequest at 'https://open-vsx.org/vscode/gallery/extensionquery' from origin 'vscode-file://vscode-app' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.

daiyam · 2021-09-02T21:31:40Z

Since VSCode v1.60, this issue has become a catastrophic issue.
The path to load the resources with node has been completely removed. So no easy patch.
I've put on hold VSCodium v1.60 until a complete fix of the issue.

coxackie · 2021-09-06T07:58:57Z

Please do something about this issue. It has effectively rendered the marketplace in open-source builds of VSCode unusable. If the whole "open marketplace" experiment does not work out, users will have no choice but to go back to proprietary builds of VSCode.

brianking · 2021-09-06T09:53:08Z

Some unforeseen circumstances have delayed us from fixing this, but please be aware that it is the number 1 priority for us with Open VSX now and will proceed from there.

daiyam · 2021-09-06T09:59:05Z

@brianking Thank you

frank-dspeed · 2021-09-06T11:48:10Z

Proposal (please thumbs up if it looks valid)

We could implement a cors proxy inside the extension and change the url to use that this will bypass cors only for this extension.

daiyam · 2021-09-06T12:01:54Z

@frank-dspeed Today, I was also thinking about a cors proxy until I found out a mistake in my testings. When fixed, my patch was working... So VSCodium v1.60.0 will be out tonight.

frank-dspeed · 2021-09-06T12:21:51Z

@daiyam sure but then still the problem exists inside web theia deployments for example so you also think that cors is a valid solution ?

daiyam · 2021-09-06T12:31:26Z

@frank-dspeed Yes, the CORS requests need to be correctly handled.

eclipsewebmaster · 2021-09-07T15:35:20Z

We've made a temporary change via EclipseFdn/open-vsx.org#633 -- does that help?

vince-fugnitto · 2021-09-07T15:57:43Z

We've made a temporary change via EclipseFdn/open-vsx.org#633 -- does that help?

@eclipsewebmaster are the changes live? I am still getting cors issues:

paul-marechal · 2021-09-07T16:51:20Z

@eclipsewebmaster here's a Bash command that inspects headers for the public instance of Open VSX:

curl \
    --dump-header - \
    --header 'Content-Type: application/json' \
    --header 'Origin: https://some-domain.com' \
    --data '{"extensionId":"patate"}' \
    --request POST 'https://open-vsx.org/api/-/query' \
    --stderr /dev/null | \
    grep -i 'Access-Control-Allow-Origin'

As long as grep doesn't return Access-Control-Allow-Origin: * the problem is not fixed.

edit: Hopefully this helped you enough despite being wrong...
edit: Fixed case sensitivity as the server responds with lowercased access-control-allow-origin:.
edit: Added a placeholder Origin: header.

eclipsewebmaster · 2021-09-07T19:00:03Z

Thank you, that is helpful.

eclipsewebmaster · 2021-09-07T19:08:16Z

@paul-marechal Are you sure?

If I post a valid extension, I (now) get the valid header:

$ curl --dump-header - --header 'Content-Type: application/json' --data '{"extensionId":"redhat.vscode-xml"}' --request POST 'https://open-vsx.org/api/-/query'
HTTP/2 200
server: nginx
date: Tue, 07 Sep 2021 19:06:23 GMT
content-type: application/json
vary: Accept-Encoding
vary: Origin
vary: Access-Control-Request-Method
vary: Access-Control-Request-Headers
cache-control: max-age=600, public
x-content-type-options: nosniff
x-xss-protection: 1; mode=block
strict-transport-security: max-age=31536000 ; includeSubDomains
x-frame-options: DENY
access-control-allow-origin: *
x-access-control-allow-origin: Added_by_nginx

If I search for an invalid extension, I don't get the header(s) added by the proxy:
$ curl --dump-header - --header 'Content-Type: application/json' --data '{"extensionId":"patate"}' --request POST 'https://open-vsx.org/api/-/query'
HTTP/2 400
server: nginx
date: Tue, 07 Sep 2021 19:07:32 GMT
content-type: application/json
vary: Origin
vary: Access-Control-Request-Method
vary: Access-Control-Request-Headers
x-content-type-options: nosniff
x-xss-protection: 1; mode=block
cache-control: no-cache, no-store, max-age=0, must-revalidate
pragma: no-cache
expires: 0
strict-transport-security: max-age=31536000 ; includeSubDomains
x-frame-options: DENY

eclipsewebmaster · 2021-09-07T19:14:24Z

@spoenemann it appears the server itself is not returning the header when no origin is specified. From the nginx reverse-proxy:

curl --insecure --dump-header - --header "Host: open-vsx.org" --header 'Content-Type: application/json' --data '{"extensionId":"redhat.vscode-xml"}' --request POST 'https://okdnode-1/api/-/query'
HTTP/1.1 200
Vary: Origin
Vary: Access-Control-Request-Method
Vary: Access-Control-Request-Headers
Cache-Control: max-age=600, public
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Strict-Transport-Security: max-age=31536000 ; includeSubDomains
X-Frame-Options: DENY
Content-Type: application/json
Transfer-Encoding: chunked
Date: Tue, 07 Sep 2021 19:11:08 GMT

If I specify an Origin, I get the header:
curl --insecure --dump-header - --header "Host: open-vsx.org" --header "Origin: https://x" --header 'Content-Type: application/json' --data '{"extensionId":"redhat.vscode-xml"}' --request POST 'https://okdnode-1/api/-/query'
HTTP/1.1 200
Vary: Origin
Vary: Access-Control-Request-Method
Vary: Access-Control-Request-Headers
Access-Control-Allow-Origin: *
Cache-Control: max-age=600, public
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Strict-Transport-Security: max-age=31536000 ; includeSubDomains
X-Frame-Options: DENY
Content-Type: application/json
Transfer-Encoding: chunked
Date: Tue, 07 Sep 2021 19:13:16 GMT

Those responses are untouched by the proxy, direct from the open-vsx server

eclipsewebmaster · 2021-09-07T19:16:36Z

I've got the header to apear even for 400 responses:

$ curl --dump-header - --header 'Content-Type: application/json' --data '{"extensionId":"patate"}' --request POST 'https://open-vsx.org/api/-/query'
HTTP/2 400
server: nginx
date: Tue, 07 Sep 2021 19:15:51 GMT
content-type: application/json
vary: Origin
vary: Access-Control-Request-Method
vary: Access-Control-Request-Headers
x-content-type-options: nosniff
x-xss-protection: 1; mode=block
cache-control: no-cache, no-store, max-age=0, must-revalidate
pragma: no-cache
expires: 0
strict-transport-security: max-age=31536000 ; includeSubDomains
x-frame-options: DENY
access-control-allow-origin: *
x-access-control-allow-origin: Added_by_nginx

Please confirm if this helps.

dustydecapod · 2021-09-07T19:47:02Z

Everything looks to be working in my vscode install. :)

eclipsewebmaster · 2021-09-07T19:52:09Z

Thanks.

To reiterate, @spoenemann it appears the server itself is not returning the access-control-allow-origin: * header when no Origin is specified (please see earlier comments).

daiyam · 2021-09-07T20:12:37Z

is not returning the access-control-allow-origin: * header when no Origin is specified (please see earlier comments).

@eclipsewebmaster yes, that's normal.

paul-marechal · 2021-09-07T21:43:59Z

@eclipsewebmaster I expected the server to respond with * no matter what so I also missed the Origin header... This is my bad.

Testing now from different origins seems to work fine: the Acces-Control-Allow-Origin: field copies what was passed as Origin: which gets rid of the CORS issues!

According to https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Origin#directives the * directive is useful for requests made without credentials. Depending on how the API is meant to be accessed the current behavior of copying the declared Origin: might be fine? Just not sure what's the best course of action here.

edit: Testing now I see that without an Origin header access-control-allow-origin: * is returned.

Jsmond2016 · 2021-09-08T14:41:11Z

I have met the same question, is there any useful way to resolve it? I can't install any plugins from market now..

marcdumais-work · 2021-09-08T14:48:50Z

@Jsmond2016 It looks like you are accessing the official Visual Studio Marketplace. Which client are you using? VSCodium?

Jsmond2016 · 2021-09-09T01:52:56Z

@Jsmond2016 It looks like you are accessing the official Visual Studio Marketplace. Which client are you using? VSCodium?

spoenemann · 2021-09-09T06:53:33Z

To reiterate, @spoenemann it appears the server itself is not returning the access-control-allow-origin: * header when no Origin is specified (please see earlier comments).

@eclipsewebmaster this is the default behavior implemented by Spring, and in my understanding it's the correct behavior. It's the responsibility of the web browser to include an Origin header and check the response headers when a request is sent to a different domain via JS API.

spoenemann · 2021-09-16T12:04:19Z

Seems to work now, see EclipseFdn/open-vsx.org#633

daiyam mentioned this issue Jul 11, 2021

[1.58] Extension marketplace not working VSCodium/vscodium#746

Closed

2 tasks

Memexurer mentioned this issue Jul 12, 2021

Extensions Marketplace microsoft/vscode#128443

Closed

spoenemann reopened this Aug 23, 2021

gasinvein mentioned this issue Aug 27, 2021

Extensions tab is not working flathub/com.visualstudio.code-oss#52

Closed

daiyam mentioned this issue Sep 5, 2021

v1.60 VSCodium/vscodium#818

Closed

frank-dspeed mentioned this issue Sep 7, 2021

Fix unrelated cors error happening because of unneeded frontend call to vsx-registry-frontend-model.ts refresh() open-pwa/theia#1

Closed

spoenemann closed this as completed Sep 16, 2021

error: CORS request did not succeed #306

error: CORS request did not succeed #306

Comments

daiyam commented Jul 11, 2021

SpacingBat3 commented Jul 11, 2021 • edited Loading

daiyam commented Jul 11, 2021

daiyam commented Jul 13, 2021

jotoho commented Jul 13, 2021

daiyam commented Jul 13, 2021

eclipsewebmaster commented Jul 13, 2021

daiyam commented Jul 13, 2021

jotoho commented Jul 13, 2021

jotoho commented Jul 13, 2021 • edited Loading

daiyam commented Jul 13, 2021 • edited Loading

jotoho commented Jul 13, 2021

eclipsewebmaster commented Jul 13, 2021

eclipsewebmaster commented Jul 13, 2021

daiyam commented Jul 13, 2021

eclipsewebmaster commented Jul 13, 2021

daiyam commented Jul 13, 2021

SpacingBat3 commented Jul 13, 2021

daiyam commented Jul 13, 2021 • edited Loading

SpacingBat3 commented Jul 13, 2021 • edited Loading

SpacingBat3 commented Jul 13, 2021 • edited Loading

SpacingBat3 commented Jul 13, 2021 • edited Loading

eclipsewebmaster commented Jul 13, 2021

jotoho commented Jul 13, 2021

eclipsewebmaster commented Jul 13, 2021

daiyam commented Jul 13, 2021

daiyam commented Jul 13, 2021

daiyam commented Jul 14, 2021

daiyam commented Jul 14, 2021

ocket8888 commented Sep 1, 2021

daiyam commented Sep 2, 2021

coxackie commented Sep 6, 2021

brianking commented Sep 6, 2021

daiyam commented Sep 6, 2021

frank-dspeed commented Sep 6, 2021

Proposal (please thumbs up if it looks valid)

daiyam commented Sep 6, 2021

frank-dspeed commented Sep 6, 2021

daiyam commented Sep 6, 2021

eclipsewebmaster commented Sep 7, 2021

vince-fugnitto commented Sep 7, 2021

paul-marechal commented Sep 7, 2021 • edited Loading

eclipsewebmaster commented Sep 7, 2021

eclipsewebmaster commented Sep 7, 2021

eclipsewebmaster commented Sep 7, 2021

eclipsewebmaster commented Sep 7, 2021

dustydecapod commented Sep 7, 2021

eclipsewebmaster commented Sep 7, 2021

daiyam commented Sep 7, 2021 • edited Loading

paul-marechal commented Sep 7, 2021 • edited Loading

Jsmond2016 commented Sep 8, 2021

marcdumais-work commented Sep 8, 2021

Jsmond2016 commented Sep 9, 2021

spoenemann commented Sep 9, 2021

spoenemann commented Sep 16, 2021

SpacingBat3 commented Jul 11, 2021 •

edited

Loading

jotoho commented Jul 13, 2021 •

edited

Loading

daiyam commented Jul 13, 2021 •

edited

Loading

daiyam commented Jul 13, 2021 •

edited

Loading

SpacingBat3 commented Jul 13, 2021 •

edited

Loading

SpacingBat3 commented Jul 13, 2021 •

edited

Loading

SpacingBat3 commented Jul 13, 2021 •

edited

Loading

paul-marechal commented Sep 7, 2021 •

edited

Loading

daiyam commented Sep 7, 2021 •

edited

Loading

paul-marechal commented Sep 7, 2021 •

edited

Loading