#35971: RemoteUserMiddleware needs a get_username method
-------------------------------+--------------------------------------
     Reporter:  Adrien Kunysz  |                    Owner:  (none)
         Type:  New feature    |                   Status:  new
    Component:  contrib.auth   |                  Version:  5.0
     Severity:  Normal         |               Resolution:
     Keywords:                 |             Triage Stage:  Unreviewed
    Has patch:  0              |      Needs documentation:  0
  Needs tests:  0              |  Patch needs improvement:  0
Easy pickings:  0              |                    UI/UX:  0
-------------------------------+--------------------------------------
Description changed by Adrien Kunysz:

Old description:

> As currently implemented, the only way to customise how
> RemoteUserMiddleware gets the username is through the "header" variable.
> This is then used in __call__ and __acall__ methods like this:
>
> {{{
>             username = request.META[self.header]
> }}}
>
> It would be convenient to move that logic into a separate method that
> could be overridden. For example:
> {{{
> get_username(self):
>     return request.META[self.header]
> }}}
>
> Specific use case: the proxy I have in front of Django always sets two
> specific headers (say "X-Username" and "X-Authenticated"). The value of
> "X-Username" is only valid if "X-Authenticated" is "true", otherwise it
> should be ignored (typically it ends up being a single space character).
> I use PersistentRemoteMiddleware to use X-Username but the only way I
> found to ignore it when X-Authenticated is not true is to override
> __call__ / __acall__ or clean_username. Both seem rather fragile while a
> small change to RemoteUserMiddleware would make for a much more robust,
> flexible and maintainable solution.
>
> With the proposed change, in my child class I could just say
> {{{
> def get_username(self):
>     if request.META["X-Authenticated"].lower() != "true":
>         raise KeyError
>     else:
>         return request.META[self.header]
> }}}
>
> I am happy to propose a patch if we can agree this change is desirable.

New description:

 As currently implemented, the only way to customise how
 RemoteUserMiddleware gets the username is through the "header" variable.
 This is then used in __call__ and __acall__ methods like this:

 {{{
             username = request.META[self.header]
 }}}

 It would be convenient to move that logic into a separate method that
 could be overridden. For example:
 {{{
 get_username(self, header_name):
     return request.META[header_name]
 }}}

 Specific use case: the proxy I have in front of Django always sets two
 specific headers (say "X-Username" and "X-Authenticated"). The value of
 "X-Username" is only valid if "X-Authenticated" is "true", otherwise it
 should be ignored (typically it ends up being a single space character). I
 use PersistentRemoteMiddleware to use X-Username but the only way I found
 to ignore it when X-Authenticated is not true is to override __call__ /
 __acall__ , which seems rather fragile while a small change to
 RemoteUserMiddleware would make for a much more robust, flexible and
 maintainable solution.

 With the proposed change, in my child class I could just say
 {{{
 def get_username(self, header_name):
     if request.META["X-Authenticated"].lower() != "true":
         raise KeyError
     return request.META[header_name]
 }}}

 I am happy to propose a patch if we can agree this change is desirable.

 The analysis above is for the latest version on github. I have marked this
 feature request as 5.0 because that's the version I currently use and
 backporting the proposed change seems easy enough.

--
-- 
Ticket URL: <https://code.djangoproject.com/ticket/35971#comment:3>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion visit 
https://groups.google.com/d/msgid/django-updates/01070193922c5818-e0d944f2-b104-4538-a188-4ed90b0e88d6-000000%40eu-central-1.amazonses.com.

Reply via email to