mirror of
https://github.com/alexta69/metube.git
synced 2026-09-21 13:35:01 +00:00
Alex Shnitman
c393e0195b
A bookmarklet could never reach an instance behind reverse-proxy auth. on_prepare echoed Access-Control-Allow-Origin but never sent Access-Control-Allow-Credentials, and hardcoded Allow-Headers to Content-Type, so both approaches the reporter suggested in 2022 still failed in a browser today: credentials:'include' was rejected for the missing Allow-Credentials, and an explicit Authorization header was rejected as not allowed by the preflight. Naming an origin in CORS_ALLOWED_ORIGINS is a deliberate trust grant, so a named origin may now send credentials and an Authorization header. The '*' wildcard is not such a grant: it matches origins the operator never enumerated, and since credentials require echoing the origin back rather than sending '*', pairing the two would let any site the user visits drive their instance with their own session. The wildcard therefore keeps byte-for-byte the uncredentialed behaviour it has always had, and a '*' anywhere in the list disables credentials for every origin in it, with a startup warning so that combination is not silently confusing. This matches the boundary socket.io already enforces: engineio defaults cors_credentials to True, and its wildcard test is against the string '*' while we pass a list, so it too grants credentials only to explicitly listed origins. Also sets Vary: Origin, appending rather than clobbering, so a shared cache cannot hand one origin's Allow-Origin to another. Verified in a real browser across the matrix: with the caller's origin named, plain/credentialed/Authorization requests all succeed; under '*' the credentialed and Authorization requests stay blocked; from an unlisted origin everything stays blocked. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>