Puncte:1

Solicitarea CloudFront CORS folosind cookie-uri semnate și cuCredentials, fără a trimite înapoi Access-Control-Allow-Credentials decât dacă includ un antet suplimentar

drapel cn

Am o problemă foarte ciudată pe care nu o pot rezolva. Am configurat o distribuție CloudFront privată pentru a servi conținut dintr-o găleată S3 privată. Folosesc cookie-uri semnate pentru a acorda acces la fișiere. De asemenea, fac solicitări încrucișate de la un browser pentru fișiere, așa că trebuie să permit acreditărilor pentru a trimite cookie-ul. Am configurat o politică personalizată pentru anteturile de răspuns pentru a face acest lucru (am setat-o ​​să seteze Access-Control-Allow-Credentials la adevărat, setat în mod explicit Access-Control-Allow-Origin la domeniul dorit și setat Access-Control-Allow-Methods / Access-Control-Max-Age în mod corespunzător și este setat la suprascrierea originii), și am configurat, de asemenea, o politică de cache personalizată pentru a stoca în cache pe baza antetelor de origine și de control al accesului.

această comandă cURL nu oferă răspunsul corect:

curl -v -H "origine: https://my-subdomain.my-domain.com" -H "cookie: CloudFront-Key-Pair-Id=MyKeyPairID; CloudFront-Policy=Base64EncodedPolicy; CloudFront-Signature=SignedPolicy" https ://my-other-subdomain.my-domain.com/key/to/my/private/file.txt

produce următoarele:

< HTTP/1.1 200 OK
< Content-Type: application/octet-stream
< Lungimea conținutului: 576
< Conexiune: păstrați-vă în viață
< Data: vineri, 18 februarie 2022 18:34:09 GMT
< Ultima modificare: joi, 16 decembrie 2021 14:45:12 GMT
< ETTag: „a50884915242f9876bea4bb633963191”
< Accept-Range: octeți
< Server: AmazonS3
< Variază: origine, antete-cerere-control-acces, metodă-cerere-control-acces
< Access-Control-Allow-Origin: https://my-subdomain.my-domain.com
< Variază: Origine
< X-Cache: Lovitură din cloudfront
< Prin: 1.1 redacted.cloudfront.net (CloudFront)
< X-Amz-Cf-Pop: EWR50-C1
< X-Amz-Cf-Id: JxMbPWHeQr0a9AAlf9PI5ksF6xGKVWL1LvpEC9XEoR_PVuVgiJ5zGA==
< Vârsta: 626

Observați cei dispăruți Acces-Control-Permite-Acreditări antet.

Cu toate acestea, această comandă dă răspunsul corect:

curl -v -H "X-some-header: nonsens" -H "origine: https://my-subdomain.my-domain.com" -H "cookie: CloudFront-Key-Pair-Id=MyKeyPairID; CloudFront- Policy=Base64EncodedPolicy; CloudFront-Signature=SignedPolicy" https://my-other-subdomain.my-domain.com/key/to/my/private/file.txt

se intoarce:

< HTTP/1.1 200 OK
< Content-Type: application/octet-stream
< Lungimea conținutului: 576
< Conexiune: păstrați-vă în viață
< Data: vineri, 18 februarie 2022 18:34:09 GMT
< Ultima modificare: joi, 16 decembrie 2021 14:45:12 GMT
< ETTag: „a50884915242f9876bea4bb633963191”
< Accept-Range: octeți
< Server: AmazonS3
< Variază: origine, antete-cerere-control-acces, metodă-cerere-control-acces
< Access-Control-Allow-Credentials: true
< Access-Control-Allow-Origin: https://my-subdomain.my-domain.com
< Variază: Origine
< X-Cache: Lovitură din cloudfront
< Prin: 1.1 redacted.cloudfront.net (CloudFront)
< X-Amz-Cf-Pop: EWR50-C1
< X-Amz-Cf-Id: pUSouCDwLH5Zu6-NBUZqKrb5kY407GLqXXtH4EK2-Th0Z9zZNb54ag==
< Vârsta: 693

de data aceasta, cu corecta Acces-Control-Permite-Acreditări antet. Nu am idee ce am configurat greșit pentru a provoca acest lucru sau de ce s-ar putea întâmpla asta. Orice perspectivă ar fi foarte apreciată, orice configurație sau rezultat de testare este necesară, doar anunțați-mă.

Mulțumesc

EDITAȚI | ×:

După câteva încercări și erori, am stabilit că setarea de înlocuire a originii din Politica antetului de răspuns cauzează problema. Când este setat la adevărat, nu va trimite antetul Access-Control-Allow-Credentials decât dacă trimiteți un antet străin împreună cu solicitarea dvs. Aceasta este o problemă, deoarece provoacă și solicitări nedorite de preflight în browser.

Dezactivarea acestei setări și apoi configurarea CORS-ului meu S3 Bucket pentru a arăta ca cel de mai jos am remediat:

[
    {
        „AllowedHeaders”: [
            "*"
        ],
        „AllowedMethods”: [
            "OBȚINE",
            "CAP"
        ],
        „AllowedOrigins”: [
            „https://*”,
            „http://*”
        ],
        „ExposeHeaders”: [
            „ETag”
        ]
    }
]

Cu toate acestea, sunt încă curios dacă am înțeles greșit setarea de anulare a originii și există o modalitate de a face asta corect sau dacă acesta este o eroare de vreun fel în CloudFront

EDITARE 2:

Politica de solicitare a originii: AWS Managed CORS-S3Oriign (am încercat cu aceasta și fără nicio politică, același rezultat)

Politica de cache: Politica personalizată pentru a stoca în cache pe baza antetelor Origine și de control al accesului, încercată și cu politica CacheOptimized gestionată standard și politica NoCache pentru a mă asigura că nu aveam nicio problemă cu cererile fără acreditări care rămân blocate în cache. De asemenea, am încercat să invalidez cache-ul manual și să văd dacă loviturile sau greșelile au făcut o diferență, nu o fac.

Politica CF Cache

Politica antetelor de răspuns: Personalizat pentru a permite acreditările, aceasta este configurația originală. În cele din urmă, am setat înlocuirea originii la false și lucrurile au început să funcționeze dacă mi-am reconfigurat politica S3 CORS pentru a seta anteturile. Am o valoare aleatoare sub Acces-Control-Permite-anteturi pentru că nu aveam voie să las acel câmp necompletat din orice motiv. Antetul trimis aleatoriu nu trebuie să se potrivească cu antetul setat aici pentru ca antetul de acreditări să fie returnat, dar trebuie să se potrivească pentru ca verificarea preflight a browserului să treacă. M-am jucat și cu setarea de expunere antete, nimic nu a ajutat.

Mai mult, rețineți că, odată ce S3 am stabilit corect anteturile CORS, am reușit să elimin în întregime politica antetelor de răspuns, dar a trebuit să păstrez politica de cache personalizată, altfel origini diferite ar putea obține antetele greșite. Acest lucru este, de asemenea, mai puțin decât ideal, deoarece voi avea utilizatori să acceseze aceste fișiere din origini diferite și cred că, dacă politica antetelor de răspuns ar funcționa corect, ar fi setarea antetelor după ce sunt scoase din cache, mai degrabă decât stocarea antetelor în cache (dar eu poate fi greșit în privința asta). Se pare că singura mea opțiune este o funcție CF care rulează pe răspunsuri, dar aceasta implică costuri suplimentare și cheltuieli generale, în timp ce o politică funcțională a anteturilor de răspuns ar fi gratuită și mai eficientă.

Dar ceea ce este foarte ciudat este că, chiar dacă S3 setează corect anteturile CORS, dacă folosesc Politica antetelor de răspuns cu înlocuirea originii true, tot întrerupe răspunsul fără antetul aleator atașat.

Politica antetelor de răspuns

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.