#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 , 9 years ago
Has patch: | set |
---|
comment:2 by , 9 years ago
Summary: | Customizing environment variable for for RemoteUserMiddleware requires subclass → Customizing environment variable for RemoteUserMiddleware requires subclass |
---|
comment:3 by , 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 , 9 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
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 , 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.
Proposed patch at https://github.com/django/django/pull/6616.