roadrunner icon indicating copy to clipboard operation
roadrunner copied to clipboard

[💡FEATURE REQUEST]: Enhance CORS support

Open tntrex opened this issue 3 years ago • 2 comments

Current CORS headers settings doesn't covers my use cases.

First of all I want a support of multiple allowed origins (or even any origin) with credentials enabled. Currently http.headers.cors.allowed_origin = * and http.headers.cors.allow_credentials = true is not working together.

Would be nice if allowed_origin can be configured as single origin or array of origins, and option to reflect Origin from request header (maybe combination of allowed_origin = * and allow_credentials = true or some reserved allowed_origin value). CORS middleware example in Go, that can acts like described: https://github.com/rs/cors

Second little problem is deprecation message from browser like that, when allowed_headers = *:

"Authorization" will not be covered by the wildcard symbol (*)in CORS "Access-Control-Allow-Headers" handling.

I found out that it can be reflected from Access-Control-Request-Headers request header if it specified by client.

tntrex avatar Nov 03 '21 09:11 tntrex

Hey @hustlahusky , thanks for the FR. I need more details about the described problems:

Currently http.headers.cors.allowed_origin = * and http.headers.cors.allow_credentials = true is not working together.

What do you mean by not working here? It should not work according to the standard. https://fetch.spec.whatwg.org/#cors-protocol-and-credentials

Would be nice if allowed_origin can be configured as single origin or array of origins

Access-Control-Allow-Origin header can contain only 1 origin. Here is the trick to have an array with the origins and check every incoming origin with the origins in the array and then reject the request or set the origin from the request if it's in the original allowed origins array. So yes, I guess we can use the sliced version of the allowed_origin here, that won't break the existing config.

and option to reflect Origin from request header

It should be reflected automatically if the Origin is in the allowed origins list.

"Authorization" will not be covered by the wildcard symbol (*)in CORS "Access-Control-Allow-Headers" handling.

Could you please share the http.headers configuration, so, I'd be able to reproduce that?

rustatian avatar Nov 24 '21 20:11 rustatian

What do you mean by not working here? It should not work according to the standard. https://fetch.spec.whatwg.org/#cors-protocol-and-credentials

I mean that allowed_origin = * and allow_credentials = true generates next Access-Control-Allow-Origin: * and Access-Control-Allow-Credentials: true headers, that will never allow browsers to use credentials. I expect that RoadRunner can handle this situation for me and allow any specified in request header origin to use credentials.

It should be reflected automatically if the Origin is in the allowed origins list.

I mean RoadRunner can allow any origin reflected from request header when using asterisk in config.

Could you please share the http.headers configuration, so, I'd be able to reproduce that?

http:
  headers:
    cors:
      allowed_origin: '*'
      allowed_headers: '*'
      allowed_methods: '*'
      allow_credentials: true

tntrex avatar Nov 25 '21 08:11 tntrex

Multiply allowed_origins now supported. Fixed by the: https://github.com/roadrunner-server/headers/pull/48

RoadRunner can allow any origin reflected from request header

This is not an expected behavior (and non-standard), origins should be set explicitly. Not planned to implement.

rustatian avatar Jun 19 '23 10:06 rustatian