Hi @AmbroiseRabier , this is a somewhat complicated problem in that it generally only occurs when people are using tutor local for development. We can and should add more documentation around it, but the OAUTHLIB_INSECURE_TRANSPORT is a security problem in tutor local setups that are being used for production so we don’t want to recommend it as a general purpose fix.
If you’re running into this with a setup that has tutor local with a custom hostname and functioning SSL certificate that would be great to know as it would indicate some other kind of configuration issue that the fix might mask and introduce a potential security vulnerability.
Well, I have to use this in prod as well. Where HTTPS is enabled. I am not aware of any certificate issues.
If I remove os.environ["OAUTHLIB_INSECURE_TRANSPORT"] = "1" from the plugin I get the following error:
utils.py:173 - Error trying to fetch Superset guest token, mostly likely due to invalid
lms-1 | settings.SUPERSET_CONFIG or because one of the dashboard UUIDs requested does not
lms-1 | exist in Superset. data
lms-1 | exception: (insecure_transport) OAuth 2 MUST utilize https.
I also this warning in superset at initialization:
superset-1 | 2026-03-05 14:48:34,195:WARNING:superset.initialization:We haven't found any Content Security Policy (CSP) defined in the configurations. Please make sure to configure CSP using the TALISMAN_ENABLED and TALISMAN_CONFIG keys or any other external software. Failing to configure CSP have serious security implications. Check https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP for more information. You can disable this warning using the CONTENT_SECURITY_POLICY_WARNING key.
Caddy is in front (no nginx reverse proxy in front of Caddy).
Tell me if I can provide any more information.
Update: Well, removing both:
os.environ["OAUTHLIB_INSECURE_TRANSPORT"] = "1"
SUPERSET_CONFIG["internal_service_url"] = "http://superset:8088"
and… it works. It is bizarre, but I think I get what has happened:
When moving from my PC to prod, I removed insecure transport but left internal service url since it seemed to make sense. Also in prod we had an extra issue with just authenticating on superset itself, since it was calling a public URL instead of a docker URL. A Virtual IP / hairpin NAT on fortigate fixed it.
And since the error in logs was exactly the same as my local PC…
That one is on me. I hope I didn’t waste your time.
One thing that could make it slightly more explicit could be to add to superset config an explicit internal_service_url, equivalent to:
SUPERSET_CONFIG["internal_service_url"] = "https://superset.openedx.int.ecole2600.com"
→ Assumed not “internal looking” URL.
That aside, the Github issue is still valid, and you recognized it, for local PC (no https) environment it would be nice if it was documented in the official documentation of Open edX.