Hi,
You'd maybe like to give a look at #689 [
http://code.djangoproject.com/ticket/689 ] it talks about honouring the
REMOTE_USER ;)
Cheers,
Marc.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" gro
Thanks, Brian and Ivan! The CAS example was helpful in figuring things
out. Turns out the solution was simple, but the Django documentation
was not as much help as I would have liked -- I guess because, again,
the general assumption is that Django is going to handle the
authentication credentials
Ivan Sagalaev wrote:
> Brian Beck wrote:
> > I don't understand how this is related to the admin interface.
>
> Admin interface won't display a login page if you already have
> request.user set to an existing user. (if I'm not mistaken :-) ).
Yep, okay. I was referring to the case where the user
Brian Beck wrote:
> I don't understand how this is related to the admin interface.
Admin interface won't display a login page if you already have
request.user set to an existing user. (if I'm not mistaken :-) ).
> Anyway,
> shouldn't it go after the standard auth middleware, so that
> django.co
Brian Beck wrote:
> I don't understand how this is related to the admin interface. Anyway,
> shouldn't it go after the standard auth middleware, so that
> django.contrib.auth.middleware doesn't clobber the request.user that
> the middleware posted above sets? And you still need to take into
> ac
I don't understand how this is related to the admin interface. Anyway,
shouldn't it go after the standard auth middleware, so that
django.contrib.auth.middleware doesn't clobber the request.user that
the middleware posted above sets? And you still need to take into
account the admin interface's
Brian Beck wrote:
> I just wanted to add that if you want to use this method in combination
> with the bundled admin interface, you're gonna have to intercept any
> admin requests and do the authentication
... which is achieved by placing this middleware before standard auth
middleware.
--~--~-
I just wanted to add that if you want to use this method in combination
with the bundled admin interface, you're gonna have to intercept any
admin requests and do the authentication so that it won't show the
login form. Check the latest post in the CAS authentication thread,
the middleware code t
Ivan Sagalaev wrote:
> request.user = User.objects.get_or_create(
>username=username,
>defaults={...})
This one should be:
request.user, created = User.objects.get_or_create(...)
`get_or_create` returns an object and a flag if it was newly created.
--~--~--
On 12/1/06, dchandek <[EMAIL PROTECTED]> wrote:
>
> I've spent a few hours digging around, but can't seem to find a
> straightforward answer ...
>
> I have an Apache module that does user authentication and sets the
> REMOTE_USER variable with the user name. This is completely independent
> of Dja
dchandek wrote:
> I've looked at authentication backends and middleware, but it looks
> like the default Django installation expects users to login through a
> Django form.
Default system insist on storing logged user credentials in a session
(though they can be of any nature). In your case you
I've spent a few hours digging around, but can't seem to find a
straightforward answer ...
I have an Apache module that does user authentication and sets the
REMOTE_USER variable with the user name. This is completely independent
of Django and Python.
I want Django to "trust" the REMOTE_USER val
12 matches
Mail list logo
