Adrian Holovaty wrote:
> Thanks for bringing this up, Gary. The get_and_delete_messages() thing
> has always bothered me -- if it's activated, we do it for every
> request. I suppose we could make the 'messages' part of the context
> processor lazy, so that it would only call get_and_delete_messag
On Aug 31, 2006, at 1:31 AM, Adrian Holovaty wrote:
> Thanks for bringing this up, Gary. The get_and_delete_messages() thing
> has always bothered me -- if it's activated, we do it for every
> request. I suppose we could make the 'messages' part of the context
> processor lazy, so that it would
On 8/29/06, Gary Wilson <[EMAIL PROTECTED]> wrote:
> So I hit another little snag today related to this. The
> contrib.auth.middleware.LazyUser calls contrib.auth.get_user (knowing
> where to get the user from based on the backend stored in
> session['_auth_user_backend']), which will return an
>
So I hit another little snag today related to this. The
contrib.auth.middleware.LazyUser calls contrib.auth.get_user (knowing
where to get the user from based on the backend stored in
session['_auth_user_backend']), which will return an
authentication-backend-dependent user object. This user obj
On Thu, Aug 03, 2006 at 10:42:39PM -0700, Gary Wilson wrote:
>
> So, the mutli authentication seems to work well for the use case of a
> site accepting more than one authentication source to access some area,
> but not so well for the use case of a site accepting one source of
> authentication in
So, the mutli authentication seems to work well for the use case of a
site accepting more than one authentication source to access some area,
but not so well for the use case of a site accepting one source of
authentication in one area and another source of authentication in a
different area.
The
