Opened 9 years ago

Closed 9 years ago

Last modified 7 years ago

#26623 closed New feature (wontfix)

Customizing environment variable for RemoteUserMiddleware requires subclass

Reported by: Jan Pazdziora Owned by: nobody
Component: contrib.auth Version: 1.9
Severity: Normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

Currently, when deploying Django project and the environment variable for external authentication is different than the default REMOTE_USER like in environment behind HTTP proxy environment where the data comes in HTTP request headers and is seen as HTTP_REMOTE_USER or HTTP_X_REMOTE_USER, the way to "configure" Django is to subclass the RemoteUserMiddleware or PersistentRemoteUserMiddleware.

Coding the configuration with a class and then enabling it in settings.py is a hurdle especially in devops environments.

Since the RemoteUserMiddleware already depends on externally set environment variable for operation, here's a proposal to make the environment variable name externally configurable as well, with DJANGO_REMOTE_USER_VAR. That way the specifics of the external environment can be configured in the configuration of that external environment, like Apache HTTP Server configuration, without the admins having to work with Python code. I propose update of the RemoteUserMiddleware behaviour because that way it can be consumed by subclasses as well.

Change History (5)

comment:1 by Jan Pazdziora, 9 years ago

Has patch: set

comment:2 by Akshesh Doshi, 9 years ago

Summary: Customizing environment variable for for RemoteUserMiddleware requires subclassCustomizing environment variable for RemoteUserMiddleware requires subclass

comment:3 by Aymeric Augustin, 9 years ago

I'm not sure what's wrong with:

class CustomRemoteUserMiddleware(RemoteUserMiddleware):
    header = os.environ['DJANGO_REMOTE_USER_VAR']

Features are usually configured with settings in Django. In "devops environments" these settings are initialized from environment variables.

I'm -0 on adding a setting to tackle this specific use case and -1 on using a environment variable that won't be visible e.g. in diffsettings.

comment:4 by Carl Meyer, 9 years ago

Resolution: wontfix
Status: newclosed

I fully agree with Aymeric, but I'll go one step further and close the ticket: I just don't think this use case is common enough to deserve its own built-in setting. If you need it, it's easy enough to add the class to your project once, and then never have to think about it again.

comment:5 by Jan Pazdziora, 7 years ago

For the record, django-identity-external in https://github.com/adelton/django-identity-external / https://pypi.python.org/pypi/django-identity-external implements this functionality in external middleware.

Note: See TracTickets for help on using tickets.
Back to Top