8000 Allow some customizations on CORS configuration · Issue #2418 · shlinkio/shlink · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Allow some customizations on CORS configuration #2418

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
acelaya opened this issue Apr 17, 2025 · 4 comments
Open

Allow some customizations on CORS configuration #2418

acelaya opened this issue Apr 17, 2025 · 4 comments
Labels
Milestone

Comments

@acelaya
Copy link
Member
acelaya commented Apr 17, 2025

Summary

Allow customizing allowed origins, allow credentials, and max age:

  • CORS_ALLOW_ORIGIN: * (allow any origin), <origin> (which will make it resolve the value from the request's Origin header) or a comma-sepparated list of origins, which will make Shlink return the header only when those origins are the ones making the request. Defaults to *.
  • CORS_ALLOW_CREDENTIALS: true or false. Defaults to false.
  • CORS_MAX_AGE: Any number representing a value in seconds. Defaults to 3600.

More details:

Use case

This will allow to better support cases like the one described in shlinkio/shlink-web-client#1510

@stouset
Copy link
stouset commented Apr 21, 2025

Please note that you will also need to allow the Access-Control-Allow-Headers header to be configured.

Per MDN:

The value * only counts as a special wildcard value for requests without credentials (requests without HTTP cookies or HTTP authentication information). In requests with credentials, it is treated as the literal header name * without special semantics.

@acelaya
Copy link
Member Author
acelaya commented Apr 21, 2025

Please note that you will also need to allow the Access-Control-Allow-Headers header to be configured.

I will verify it, but I would expect this to cover for anything https://github.com/shlinkio/shlink/blob/develop/module/Rest/src/Middleware/CrossDomainMiddleware.php#L42

That basically means Shlink will set the value of Access-Control-Allow-Headers based on what the browser set in Access-Control-Request-Headers.

It's always better if it can be made so that there's less room for human error.

@stouset
Copy link
stouset commented Apr 21, 2025

Unfortunately I think that's not enough. The problem is that the preflight request happens before those headers are sent, because the client doesn't know that it's okay to send them yet. So they're not included in the preflight request, the preflight response doesn't know to say "yes, those headers are okay", and then the browser fails to send the actual request because the headers it was asked to provide weren't whitelisted by the preflight.

I think in your mental model, the browser sends all the headers it hopes to send as part of the initial CORS preflight, the preflight response says "yes, those are okay", and then the browser makes the actual request with those headers. But instead, the client makes a request without any of those headers, the server explicitly tells the client which ones are okay to send, and then the client decides whether or not it can make the request based on the headers it needs to include.

One sec, I think something else is going on for us. You're right that the browser should include all of the headers in the original request, in the Access-Control-Request-Headers header. Sorry, CORS is quite complex in practice.

@acelaya
Copy link
Member Author
acelaya commented Apr 21, 2025
< 6A0F p dir="auto">Sorry, CORS is quite complex in practice.

It's a pain in the ass 😅

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: No status
Development

Successfully merging a pull request may close this issue.

2 participants
0