No "Access-Control-Allow-Origin" in response despite all being set properly about django-cors-headers HOT 19 OPEN

Any update on this? i have a similar issue

from django-cors-headers.

My issue somehow ended up being related to me changing my authentication session engine to redis, spent 60+ hours debugging other stuff vs checking that 💀

from django-cors-headers.

The response has a 403 status code. Where is that coming from? Is it from a middleware above the OCRS middleware?

Also, you have a CORS-ish cookie:

< set-cookie: AWSALBCORS=xxxxxxx; Expires=Tue, 23 May 2023 13:12:04 GMT; Path=/; SameSite=None; Secure

Is your AWS ALB (application load balancer) controlling CORS for you? Perhaps it is stripping request CORS headers.

from django-cors-headers.

Encountering the same issue, I have everything set up in my settings.py and it works fine on a single EC2 but when put behind an ALB the headers just seem to vaporize.

Currently just trying to replicate the headers that this library would send in my top level Nginx config. Painful but I think I'm making progress.

from django-cors-headers.

Thank you for the quick response @adamchainz!

The response has a 403 status code. Where is that coming from? Is it from a middleware above the OCRS middleware?

Haha, yes, I figured this would be confusing, but my example just happened to be on a confidential route where I was unauthenticated. It should still return the proper cors headers though, right? Anyway, here are similar outputs from a route that returns 200:

< HTTP/2 200 
< content-type: application/json
< content-length: 1745
< vary: Accept-Encoding
< date: Sat, 20 May 2023 14:18:04 GMT
< set-cookie: AWSALB=xxxx; Expires=Sat, 27 May 2023 14:18:04 GMT; Path=/
< set-cookie: AWSALBCORS=xxxx; Expires=Sat, 27 May 2023 14:18:04 GMT; Path=/; SameSite=None; Secure
< server: nginx/1.21.0
< vary: Accept, Cookie, Origin
< allow: GET, HEAD, OPTIONS
< x-frame-options: DENY
< x-content-type-options: nosniff
< referrer-policy: same-origin
< x-cache: Miss from cloudfront
< via: 1.1 xxxx.cloudfront.net (CloudFront)
< x-amz-cf-pop: xxxx
< x-amz-cf-id: xxxx

Also, you have a CORS-ish cookie:

< set-cookie: AWSALBCORS=xxxxxxx; Expires=Tue, 23 May 2023 13:12:04 GMT; Path=/; SameSite=None; Secure

Is your AWS ALB (application load balancer) controlling CORS for you? Perhaps it is stripping request CORS headers.

As I mentionned at the end of my issue, I have no issues receiving the proper headers when I set them manually using finalize_response:

def finalize_response(self, request, *args, **kwargs):
    response = super(PublicObjectDetail, self).finalize_response(
        request, *args, **kwargs
    )
    response["Access-Control-Allow-Origin"] = "*"
    response[
        "Access-Control-Allow-Headers"
    ] = "Origin, X-Requested-With, Content-Type, Accept"
    return response

Result from curl:

< HTTP/2 200 
< content-type: application/json
< content-length: 1745
< vary: Accept-Encoding
< date: Sat, 20 May 2023 14:05:12 GMT
< set-cookie: AWSALB=xxxx; Expires=Sat, 27 May 2023 14:05:12 GMT; Path=/
< set-cookie: AWSALBCORS=xxxx; Expires=Sat, 27 May 2023 14:05:12 GMT; Path=/; SameSite=None; Secure
< server: nginx/1.21.0
< vary: Accept, Cookie
< allow: GET, HEAD, OPTIONS
< access-control-allow-origin: *
< access-control-allow-headers: Origin, X-Requested-With, Content-Type, Accept
< x-frame-options: DENY
< x-content-type-options: nosniff
< referrer-policy: same-origin
< x-cache: Miss from cloudfront
< via: 1.1 xxxxx.cloudfront.net (CloudFront)
< x-amz-cf-pop: xxxx
< x-amz-cf-id: xxxx

As you can see, I receive the headers in the response. (by the way @neverabsolute , you should try this workaround to check if your issue is indeed due to outside factors such as the load balancer, in which case yours is probably not the same issue as mine)

from django-cors-headers.

I was asking if the ALB is stripping CORS request headers. Your workaround sets respnse CORS headers unconditionally, but that’s not a generally secure way to do CORS, hence this package only sets them on CORS requests. You could test by debugging the headers received by Django, or read up the AWS docs - I’ve found them mostly complete, if verbose.

from django-cors-headers.

I was asking if the ALB is stripping CORS request headers. Your workaround sets respnse CORS headers unconditionally, but that’s not a generally secure way to do CORS, hence this package only sets them on CORS requests. You could test by debugging the headers received by Django, or read up the AWS docs - I’ve found them mostly complete, if verbose.

Ah, my bad, I wrongly assumed you meant response headers instead, sorry!

I did read up a good sum of the AWS docs on this issue, and all they seem to talk about as far as I can see are the Origin, Access-Control-Request-Method, Access-Control-Request-Headers headers. As mentioned in the first post, I already checked that Origin was properly forwarded, but here is the same debugging including the other two:

from corsheaders.signals import check_request_enabled
from django.conf import settings

def cors_allow_api_to_everyone(sender, request, **kwargs):
    print("CHECKING REQUEST ORIGIN")
    print(request.headers['Origin'])
    print(request.headers['Access-Control-Request-Method'])
    print(request.headers['Access-Control-Request-Headers'])
    return False

check_request_enabled.connect(cors_allow_api_to_everyone)

When requesting a url using curl this way:

curl -H "Origin: example.com" -H "Access-Control-Request-Method: GET" -H "Access-Control-Request-Headers: X-Requested-With" -v "https://myapp.com/api/myprivateroute/" -X OPTIONS

Here is the output in the server logs:

CHECKING REQUEST ORIGIN
example.com
GET
X-Requested-With

So I am thinking this proves that the headers are being forwarded correctly?

from django-cors-headers.

🤷‍♂️ I'm sorry, I'm not really sure then.

from django-cors-headers.

Check for a missing CSRF token!

from django-cors-headers.

@SylvainBigonneau Did you find the solution to this problem? I have got the same issue

Django==4.2.5
django-cors-headers==4.3.0
djangorestframework==3.14.0

All setting done as per the docs:

INSTALLED_APPS = [.., 'corsheaders', ..]
MIDDLEWARE = [..., 'corsheaders.middleware.CorsMiddleware',...]
CORS_ALLOW_ALL_ORIGINS = True 
CORS_ALLOW_HEADERS = default_headers

no sign of 'Access-Control-Allow-Origin' header when I do a curl:

P.S: The Django application is behind an nginx server with proxy pass set:

location /api{ proxy_pass http://backend:8000; }

from django-cors-headers.

@SylvainBigonneau Did you find the solution to this problem? I have got the same issue

Django==4.2.5 django-cors-headers==4.3.0 djangorestframework==3.14.0

All setting done as per the docs:

INSTALLED_APPS = [.., 'corsheaders', ..]
MIDDLEWARE = [..., 'corsheaders.middleware.CorsMiddleware',...]
CORS_ALLOW_ALL_ORIGINS = True 
CORS_ALLOW_HEADERS = default_headers

no sign of 'Access-Control-Allow-Origin' header when I do a curl:

P.S: The Django application is behind an nginx server with proxy pass set:

location /api{ proxy_pass http://backend:8000; }
Facing same problem. Please let us know if you find a solution for this.

from django-cors-headers.

For anyone who finds this, the screenshot below shows that the Origin header is missing from the request. As specified in the issue 901, you need to add that header to get the access-control-allow-origin header back,

@SylvainBigonneau Did you find the solution to this problem? I have got the same issue

Django==4.2.5 django-cors-headers==4.3.0 djangorestframework==3.14.0

All setting done as per the docs:

INSTALLED_APPS = [.., 'corsheaders', ..]
MIDDLEWARE = [..., 'corsheaders.middleware.CorsMiddleware',...]
CORS_ALLOW_ALL_ORIGINS = True 
CORS_ALLOW_HEADERS = default_headers

no sign of 'Access-Control-Allow-Origin' header when I do a curl:

P.S: The Django application is behind an nginx server with proxy pass set:

location /api{ proxy_pass http://backend:8000; }

from django-cors-headers.