STRIPE_LIVE_MODE only works as a string, not as a proper boolean setting... maybe

Describe the bug Re-reporting a previous bug, #578. Feel like this is worth documenting perhaps?

I’ve run across this in multiple Django-isms in the deployment I’m currently working on, and there’s little rhyme or reason to it. Quoting env variables causes mod_wsgi to fail because it respects the quotes. Not quoting env variables causes dj_stripe to fail, because it does expect the quotes. For example, if you load STRIPE_LIVE_MODE from an os environment variable without quotes, you cannot conditionally check it in a view with truthiness assumptions, like…

if settings.STRIPE_LIVE_MODE:
    key = settings.DJSTRIPE_LIVE_SECRET_KEY
else:
    key = settings.DJSTRIPE_TEST_SECRET_KEY

… you have to explicitly call the expected value…

if settings.STRIPE_LIVE_MODE == 'True':
    key = settings.DJSTRIPE_LIVE_SECRET_KEY
else:
    key = settings.DJSTRIPE_TEST_SECRET_KEY

… and then use the workaround in #578 to explicitly cause a truthiness conditional check. It doesn’t help that bash in the base OS handles quotes in env variables differently from bash in a container using an image from the same base OS (CentOS8 in my case, bash in the base OS strips quotes if you specify them in env files that are loaded via source, whereas podman container bash from the official CentOS8 image leaves the quotes in place).

I know that none of this is your fault, it’s a failure within shells and/or python itself, but a blurb about it in the docs might save someone else some trouble.

To Reproduce export DJ_MODE=False export DJ_TESTPUB=pk_test_asdf… export DJ_TESTKEY=sk_test_asdf… export DJ_LIVEPUB=pk_live_asdf… export DJ_LIVEKEY=sk_live_asdf… export DJ_WHKEY=whsec_asdf…

STRIPE_TEST_PUBLIC_KEY = os.environ.get(‘DJ_TESTPUB’) STRIPE_TEST_SECRET_KEY = os.environ.get(‘DJ_TESTKEY’) STRIPE_LIVE_PUBLIC_KEY = os.environ.get(‘DJ_LIVEPUB’) STRIPE_LIVE_SECRET_KEY = os.environ.get(‘DJ_LIVEKEY’) STRIPE_LIVE_MODE = os.environ.get(‘DJ_MODE’) DJSTRIPE_WEBHOOK_SECRET = os.environ.get(‘DJ_WHKEY’) DJSTRIPE_USE_NATIVE_JSONFIELD = True DJSTRIPE_FOREIGN_KEY_TO_FIELD = ‘id’

python manage.py sync models, will get live data or invalid live key message. python manage.py shell, import djstripe and django settings…

import djstripe
from django.conf import settings

if settings.STRIPE_LIVE_MODE:
    key = settings.DJSTRIPE_LIVE_SECRET_KEY
else:
    key = settings.DJSTRIPE_TEST_SECRET_KEY

print(key)

sk_live_asdf....

Software versions

• Dj-Stripe version: dj-stripe==2.5.1
• Python version: Python 3.6.8
• Django version: 3.2
• Stripe API version: stripe==2.60.0
• Database type and version: Postgres v13

[awhileback]

@awhileback I can understand your frustration and this does seem like an annoying quirk of all these systems. I’m curious to know why are you exporting STRIPE_LIVE_MODE as an env key? If your settings.py is different for different deployment environments with perhaps a common ancestor, wouldn’t it be just easier to hardcode this variable depending on which environment that settings.py file is for? And STRIPE_LIVE_MODE is also not a setting that you’d ever want to change dynamically either in my opinion.

Also, one workaround would be to wrap your stringified Boolean values like so:

bool(disutils.util.strtobool(settings.STRIPE_LIVE_MODE)) 

bool is unnecessary if all you want is truthiness and falsiness checks.

The reason for storing the key as an env variable is deployment via containers. There are no hard-coded settings in my django settings files for that reason.

Thanks for the recommendations!

@jleclanche I have seen lots of people praise that environ lib and will take a look. It always seemed superfluous to me to depend on an external lib to hold variables, when a shell can (presumably) do that very thing. But then again… here we are in this issue post (and in the other mentioned issue post), talking about a shell’s inability to consistently handle quote delimiters. There are other reasons for having those env variables in the shell for containerization too, of course, and not in a separate memory space. For instance, when spinning up postgres containers, you presumably have the data folders outside of the container volume on dedicated storage, so after the container image is pulled you need variables set to init the defaults if it’s a master, and/or supply credentials for the webapp db and replication if it’s not. If I put env variables in two different places I’m doubling my margin for error.

Thanks for the replies, and thanks for djstripe as well. Handling payment processing would not be feasible for a one-man show without things like djstripe and djpaypal to help with the integration.

[jleclanche]

@awhileback for clarity, django-environ is a tool to pull values out of os.environ in a more standard way rather than doing eg. boolean conversion yourself. It doesn’t “hold” anything.