Skip to content
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

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

Open
coateds opened this issue Jun 28, 2023 · 3 comments
Open

Comments

@coateds
Copy link

coateds commented Jun 28, 2023

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
Copy link
Collaborator

daenney commented Jun 28, 2023

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
Copy link
Author

coateds commented Jun 28, 2023

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
Copy link
Author

coateds commented Jun 29, 2023

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants