-
-
Notifications
You must be signed in to change notification settings - Fork 536
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
No "Access-Control-Allow-Origin" in response despite all being set properly #862
Comments
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:
Is your AWS ALB (application load balancer) controlling CORS for you? Perhaps it is stripping request CORS headers. |
Encountering the same issue, I have everything set up in my 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. |
Thank you for the quick response @adamchainz!
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:
As I mentionned at the end of my issue, I have no issues receiving the proper headers when I set them manually using 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:
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) |
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. |
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 💀 |
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 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:
Here is the output in the server logs:
So I am thinking this proves that the headers are being forwarded correctly? |
🤷♂️ I'm sorry, I'm not really sure then. |
Check for a missing CSRF token! |
@SylvainBigonneau Did you find the solution to this problem? I have got the same issue Django==4.2.5 All setting done as per the docs:
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:
|
|
Any update on this? i have a similar issue |
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
|
I think this issue has been solved! |
Sorry for the ghosting people, I must admit I had given up hope on this, and left it up to my |
Nope, I can confirm this issue still occurs exactly the same on django-cors-headers v4.4.0:
Yes, I know it's a 403, because I didn't bother authenticating with curl, and I put all my public routes behind a Cloudfront cache because they are bombarded by requests from clients, so requesting those routes won't actually hit my server. But as far as I can tell, no matter the HTTP code, I should get that sweet sweet As usual, here is the debug output from the server logs, showing that the request does hit the server with all the proper request headers:
And if I force the response headers by overriding the def finalize_response(self, request, *args, **kwargs):
response = super(ObjectDetail, self).finalize_response(
request, *args, **kwargs
)
response["Access-Control-Allow-Origin"] = "https://myapp.com,https://localhost:3000"
response["Access-Control-Allow-Headers"] = (
"Origin, X-Requested-With, Content-Type, Accept"
)
return response I get the response header no problem, showing that it is not AWS stripping them off:
So nope, not solved! By the way my app behaves, it really feels like I would love to help debugging this further, but I am not well versed in the intrications of debugging a third-party django middleware... If anyone can guide me a little on how and where I could look in my django app to investigate where the middleware is failing, I'd be happy to try it! Could you clarify what you meant about the "missing CSRF token" @martinskou ? How would I check that from the |
@SylvainBigonneau what happens if you send an OPTIONS http request? Like below:
|
|
I'd like to report that I'm having the same issues as seen here, spent yesterday working on first deploy to production, and ended up forcing the required headers into the response in some middleware. It's like django-cors-headers is just not being included... API server Pipfile (prod on DigitalOcean App Platform)
middleware
I had attempted to move And same response as @SylvainBigonneau (no CORS headers being included). |
Question about enablement of the library for a given response... How this is block used within the CorsMiddleware, it would suggest that CORS is only enabled when the REGEX is set, or if signals are used?
Which goes on to be used within Does this seem right? I'm not using signals nor regex, just basic configuration for setting the CORS_ALLOWED_ORIGINS. |
Understanding CORS
Python Version
3.10
Django Version
3.2.9
Package Version
3.14.0
Description
Sorry for the very typical issue name, but I am in a real pickle here.
Here is my config:
environment variable:
DJANGO_ALLOWED_HOSTS=myapp.com,localhost:3000
settings.py:
For debugging, I also set up some hacky logging at request, using signals.
handlers.py
When requesting a url using curl this way:
Here is the output in the server logs:
Here is the curl output for the response:
As you can see, no trace of any "Access-Control-Allow-Origin" response header there, despite the server receiving "example.com" as an origin, and the
CORS_ALLOWED_ORIGINS
settings being properly set.For further info, I tried forcing returning an "Access-Control-Allow-Origin" using the
finalize_response
override on one of my DRF methods, and it does return the header properly on the previously mentioned curl command. So it is likely not an issue of the header being lost on the way back to the client.The text was updated successfully, but these errors were encountered: