Получение ошибок CORS даже при заданных заголовках - только для некоторых вызовов - PullRequest
0 голосов
/ 06 мая 2020

У меня возникают странные проблемы с CORS, с которыми я никогда раньше не сталкивался. Я делаю запрос GET к конечной точке, у которой установлено access-control-allow-origin: *. Это результат с curl -v:

[me:~]$ curl -v https://example.org/wp-json/jwr/v1/instagram
*   Trying 123.123.123.123...
* TCP_NODELAY set
* Connected to example.org (123.123.123.123) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* 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, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-ECDSA-CHACHA20-POLY1305
* ALPN, server accepted to use h2
* Server certificate:
*  subject: C=US; ST=CA; L=San Francisco; O=Cloudflare, Inc.; CN=sni.cloudflaressl.com
*  start date: Nov 21 00:00:00 2019 GMT
*  expire date: Oct  9 12:00:00 2020 GMT
*  subjectAltName: host "example.org" matched cert's "example.org"
*  issuer: C=US; ST=CA; L=San Francisco; O=CloudFlare, Inc.; CN=CloudFlare Inc ECC CA-2
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x7f9cf5808200)
> GET /wp-json/jwr/v1/instagram HTTP/2
> Host: example.org
> User-Agent: curl/7.64.1
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS == 256)!
< HTTP/2 200
< date: Tue, 05 May 2020 21:41:48 GMT
< content-type: application/json; charset=UTF-8
< content-length: 10378
< set-cookie: __cfduid=d6e8c142300b62cb6b4fd207fe1912a7a1588714908; expires=Thu, 04-Jun-20 21:41:48 GMT; path=/; domain=.example.org; HttpOnly; SameSite=Lax; Secure
< x-powered-by: PHP/7.3.17
< x-robots-tag: noindex
< link: <https://example.org/wp-json/>; rel="https://api.w.org/"
< x-content-type-options: nosniff
< access-control-expose-headers: X-WP-Total, X-WP-TotalPages
< access-control-allow-headers: Authorization, Content-Type
< allow: GET
< access-control-allow-origin: *
< access-control-allow-methods: POST, GET, OPTIONS, DELETE
< access-control-allow-credentials: true
< access-control-expose-headers: Link
< etag: "129925-1588714700;;;"
< x-litespeed-cache: hit
< vary: User-Agent
< alt-svc: h3-27=":443"; ma=86400, h3-25=":443"; ma=86400, h3-24=":443"; ma=86400, h3-23=":443"; ma=86400
< cf-cache-status: DYNAMIC
< expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
< server: cloudflare
< cf-ray: 58eda0b43d6fd881-CPH
< cf-request-id: 028862c4a60000d88135a8f200000001

Однако в Chrome я получаю сообщение об ошибке:

Access to XMLHttpRequest at 'https://example.org/wp-json/jwr/v1/instagram' from origin 'http://localhost:3000' 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.

Я попытался отключить CORS в Google Chrome (с веб-безопасность отключена), и тогда он работает. Я проверил заголовки ответа, и в них также присутствовали заголовки allow-origin.

Я также пытался скопировать Chrome сетевой запрос как команду CURL, и он выполняется нормально, без каких-либо ошибок в php и с установленными заголовками CORS.

Одна странная проблема, которую я обнаружил, заключается в том, что это происходит только тогда, когда я вхожу в систему, несмотря на то, что два запроса выглядят очень похожими. Я использую Nuxt и https://github.com/nuxt-community/auth-module - однако проблема не возникает для ВСЕХ вызовов, несмотря на то, что вызовы очень похожи (та же конечная точка отдыха API)

1 Ответ

1 голос
/ 06 мая 2020

Проблема заключалась в том, что у меня было "allow-origin: *", а это недопустимо, когда вы используете withCredentials:true. Так что мне пришлось определить происхождение, и тогда это, похоже, сработало.

...