Django-Twilio package giving me a 403 forbidden when using “twilio_view” decorator
Closed this issue · 12 comments
I'm experiencing an issue with @twilio_view I've posted the details on stackoverflow: my question on stackoverflow
When I use http://123abc.ngrok.io/newsms/ instead of https://123abc.ngrok.io/newsms/ it works. Why is that? I thought https should work with django-twilio?
Curious, for the https address, are you sure that your server is processing the request? django's runserver is not capable of https, so I want to check on that, first.
Yes, I think server is processing it, because it works when I have @csrf_exempt and use https://123abc.ngrok.io/newsms/ as webhook. I did upload an example of issue which can be duplicated to my github repository: testing-django-twilio.
Still researching this.
It's interesting that if you switch to @csrf_exempt that the request goes through, because @twilio_view itself is wrapped under @csrf_exempt.
I realize this next question probably isn't a good one, but in the interest of removing the simple problems first, can you put the normal decorator back in and try the https-based request again?
When you do, can you open the ngrok localhost console/panel, and check what headers were sent in on that request? I want to make sure that twilio's header actually makes it that far (that is: to your local ngrok).
I then did a little bit of research (again, this may not be our issue, and the issue linked below may not be valid any longer, or a different issue):
inconshreveable/ngrok#92
I don't recall any real changes to the library recently. We went explicit support for py3.5-3.8, and django 2.2-3.0 but otherwise there shouldn't be any other changes yet.
Would you mind trying your test project against that older django twilio version?
So I can now confirm issue with twilio_view decorator is specific to using https as webhook with ngrok, if you use http as webhook it works fine. I have tested with earlier versions of Django and Django-Twilio, and same problem of https as webhook with ngrok not working but http working occurs.
https on my prod environment i.e not using ngrok works fine.
"can you open the ngrok localhost console/panel, and check what headers were sent in on that request"
I don't know how to check the headers, I can try to do it, if you can give me further instructions on how to. Thanks
Note my ngrok is converting http://localhost:8000 to https://123abc.ngrok.com , not sure if that is related to issue.
Thank you for checking on this and verifying that it's essentially an ngrok/tunneling/header issue.
When you start your ngrok server it should have a link in the terminal for you to go to localhost or 127.0.0.1 on a given port (maybe 4040? I haven't tried in awhile). If there are request history shown you can click on a request and I think on the bottom it shows the headers. If the twilio headers aren't there, then [something] clipped them off. Based on the symptoms you verified (production works, no tunneling, and earlier versions have the same issue non-production), without further evidence, I'm asserting my hypothesis to be true.
That said, there's no reason we can't update the docs to warn about https ngrok not working with the twilio security verification feature.
Based on the above, I'm closing the issue. Should someone run the test (check headers) and post their results, that would be beneficial. We can also reopen, but I expect we won't find any bug in this project.
Would you mind opening an issue asking for the docs change?
I ran into this issue in Google App Engine, which turns https requests into http requests at the load balancer. You can fix this issue for both ngrok and App Engine by setting the SECURE_PROXY_SSL_HEADER setting in Django settings, because they both set an X-Forwarded-Proto header indicating the protocol of the upstream request: https://docs.djangoproject.com/en/3.2/ref/settings/#secure-proxy-ssl-header
@incidentist can you open an issue for a doc change and possibly a PR with the change? It would be okay to paste the django docs link as part of the change (given django likely includes more info etc and may update their docs faster than we may).