Mark Ramm wrote:
>> @gustavo thank you very much, it was exactly that problem.
>>
>> @Alberto, yes I though about that but as Gustavo pointed out in the
>> changelog, the error middleware should be the last one to show up and
>> it was catching the 401 before repoze.who did.
>>     
>
> I actually think this solution isn't quite right.   We can do as
> alberto suggests and stop trapping 401's in the error handler, and
> things should go back to working, unless there's another problem I'm
> not seeing.
>   
Quick FYI: I've disabled trapping of 401's if auth middleware is on in 
http://trac.turbogears.org/changeset/6137 since it also affected the new 
flash since cookies were swallowed when internal-redirecting to the 
error page. Should be no problem since we don't need to render a nice 
error page when it's never going to reach the user.
> And we're dropping the sqlalchemy session with the session removal
> middleare, and now repoze.what is outside of that so if it tries to do
> anything on the way out, it won't have an active DBSession.   So, the
> current solution is broken.
>   

db_session_remover should be the last middleware executed on egress that 
needs access to SA's scoped session. If it isn't then further accesses 
to it will automatically create a new one which will contaminate the 
next request that the thread that opened it handles. Sure recipe for 
hard to track and reproduce bugs.

Alberto

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to