[Web-SIG] How to make REMOTE_USER variable private across WSGI middlewares?

[Randy Syring]

I think this is not the best mailing list to ask a question like this.  
You are probably better served to ask on Stack Overflow or some other 
place with more activity.

For what it's worth, I also think you might misunderstand how WSGI 
works.  I believe the environment object is supposed to exist in a 
request context.  I'm assuming you only need one user per request, so 
simply filling in the value of REMOTE_USER seems to me like it should 
work.  However, I haven't looked at your code or thought long about the 
problem, it's just an off-handed observation based on your description 
below.

*Randy Syring*
Husband | Father | Redeemed Sinner

/"For what does it profit a man to gain the whole world
and forfeit his soul?" (Mark 8:36 ESV)/

On 10/11/2016 06:47 PM, Etienne Robillard wrote:
> Here's the source code: 
> https://bitbucket.org/tkadm30/django-hotsauce/src/6a862e22e045cb10a84f3b08e4c237ed592ecec7/lib/notmm/controllers/wsgi.pyx
>
> A live demo is here: http://www.isotopesoftware.ca/
>
> The problem is in the init_request method.
>
> The current implementation uses threading.local.
>
> I have no idea how to make the WSGI environ object a thread-local in 
> case the remote user has been logged in.
>
>
> Any input would be greatly appreciated.
>
> Regards,
>
> Etienne
>
>
> Le 2016-10-10 à 10:30, Etienne Robillard a écrit :
>> Hi,
>>
>> I'm attempting to develop a OAuth 2.0 authentication middleware which 
>> sets REMOTE_USER variable into the WSGI environ object, however I'm 
>> unable to make this variable unique for the logged user.
>>
>> Is it recommended to use threading.local or gevent to make the WSGI 
>> environment persisting on a per-request basis ?
>>
>> What others options can you advise to make private request data not 
>> accessible in WSGI ?
>>
>> Thanks in advance,
>>
>> Etienne
>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/web-sig/attachments/20161011/62fe8c91/attachment.html>