singingwolfboy / flask-dance

Doing the OAuth dance with style using Flask, requests, and oauthlib.
https://pypi.python.org/pypi/Flask-Dance/
MIT License
997 stars 156 forks source link

export OAUTHLIB_INSECURE_TRANSPORT=1 is not working in Debian 11 Linux? #419

Open coateds opened 1 year ago

coateds commented 1 year ago

I have recently added Flask Dance to a web site I have been building. Until now I have been developing on Windows and deploying to Not-Yet-Production Azure App Service that runs Debian 11 under the hood. This has worked well so far.

The trouble I am having is with the OAUTHLIB_INSECURE_TRANSPORT=1 environment variable. I just can't get Flask Dance on Debian 11 to change its behavior as expected. It works in my Windows dev environment. I have gone so far as to create a test VM with Debian 11 to eliminate Azure as a source of the problem. I get exactly the same behavior.

There is another part of the application that utilizes values stored in environment variables. For this test I am placing the export commands in the .bashrc file for the user running the flask app. so I know the app is reading and storing the values.

I have Flask Dance working the way I want it in my dev environment. I am not ready to set up an https environment yet, I still have some comcepts to prove out on top of Flask Dance before I spend the time and money.

What am I missing here to keep developing my web site on top of the Flask Dance functionality that is working so well?

daenney commented 1 year ago

I suspect the environment variable isn't set in the processes' environment. Reading the .bashrc will only happen for processes interactively launched through the shell, not for every process run by the same user (so for example having systemd start the process with User= set won't cause .bashrc to be read and have those values in the process environment).

The quickest thing you can do to verify if the environment variables are set is add the following somewhere in your code, ideally at startup, so it gets printed to the console. That should tell you which environment variables are available:

import os

# printing environment variables, somewhere early in your startup code
print(os.environ)
coateds commented 1 year ago

I understand what you are suggesting. For the purposes of my current test, I am launching my process interactively in the shell and I know what the limitations of that are. I tried your verification test, and the output included all 5 environment variables that I set in the .bashrc. Four are values that I use to access Azure Key Vault for database connection settings and the other value is the one we are discussing. Your test shows that all the values are being read and the fact that I can connect to the database from the dev website proves the process is able to read and use the values.

I am better at Windows than at Linux, and I can get all of this to work, including the OAUTHLIB_INSECURE_TRANSPORT=1 setting on Windows. The Azure app service for Python that I deploy to defaults to Linux (Debian 11) and I am learning the wisdom of having a "staging" environment that lets me identify and troubleshoot issues when I "port" my code Python code from Windows to Linux. My best guess is that there is some software package or module that is missing from my Debian box that is required for this setting to take effect, however there are no error messages to that effect.

BTW, the end of my .bashrc file looks like this:

export AZURE_[setting]="xxxxxxxx-xxxx..." export OAUTHLIB_INSECURE_TRANSPORT="1"

I have tried this with and without quotes and substituting "true" in place of "1"

coateds commented 1 year ago

New Information:

I just got this to work as expected in Ubuntu 18.04. That is, I ...

  1. Configured a very similar environment on an existing Ubuntu 18.04 installation.
  2. Used the same git repo as I did on the Debian 11 installation
  3. Confirmed a similar error telling me the site must be https:
  4. Set export OAUTHLIB_INSECURE_TRANSPORT="1" in the .bashrc and reloaded the environment.
  5. The https requirement (error) disappeared. The site works as expected.

Unfortunately, I am stuck with Debian 11 as the default for an Azure App Service unless I want to figure out how build and utilize my own custom container.

So why would this work in Ubuntu 18.04 and not Debian 11?