#36300: request.META["HTTP_" + self.header] in RemoteUserMiddleware __acall__ 
does
not sound correct
-------------------------------------+-------------------------------------
     Reporter:  Jan Pazdziora        |                    Owner:  Jacob
                                     |  Walls
         Type:  Bug                  |                   Status:  closed
    Component:  contrib.auth         |                  Version:  5.2
     Severity:  Normal               |               Resolution:  fixed
     Keywords:                       |             Triage Stage:  Ready for
                                     |  checkin
    Has patch:  1                    |      Needs documentation:  0
  Needs tests:  0                    |  Patch needs improvement:  0
Easy pickings:  0                    |                    UI/UX:  0
-------------------------------------+-------------------------------------
Changes (by Jacob Walls <jacobtylerwalls@…>):

 * resolution:   => fixed
 * status:  assigned => closed

Comment:

 In [changeset:"1085e5e17b7403b15c4eff397f3c98c15660f46d" 1085e5e]:
 {{{#!CommitTicketReference repository=""
 revision="1085e5e17b7403b15c4eff397f3c98c15660f46d"
 Fixed #36300 -- Restored the semantic where RemoteUserMiddleware.header
 corresponds to request.META under ASGI.

 Because these tests always passed both WSGI environ values and HTTP
 headers via `**extra`, this masked a behavior difference between WSGI
 and ASGI.

 What should happen: everything should be passed via `headers` but for
 the default REMOTE_USER case on WSGI, which should be passed via
 `**extra`.

 Since that was not done, a regression made it into Django 5.2
 (50f89ae850f6b4e35819fe725a08c7e579bfd099) where `.header` no longer
 corresponded to the request.META key under ASGI. To cope, an ASGI user
 would have started(*) sending HTTP headers that match the `.header`
 attribute, which may or may not have been edited to remove the HTTP_
 prefix. (Note: the default `REMOTE_USER` case did not work under ASGI,
 so the change in Django 5.2 had the effect of fixing the default case
 but changing the semantic of the custom case.)

 (*): Unless they were getting the sync execution path, which didn't have
 this bug. See the fix in 0f4fff79d33b7cc84822e66bd1fc16caf8222e3a.

 Thanks Mykhailo Havelia and Sarah Boyce for reviews.
 }}}
-- 
Ticket URL: <https://code.djangoproject.com/ticket/36300#comment:6>
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/0107019dfdbd637a-191b1244-e78c-4c4a-956d-3c6fab892015-000000%40eu-central-1.amazonses.com.

Reply via email to