Ahhh! If I had been more explicit in giving you my code, we might have
seen the problem sooner!
The problem is that my login form is on the sidebar of my base.html - it
appears on my homepage. My homepage renders directly to a template.
So, the POST from my homepage goes to the login view from
django.contrib.auth.views
However, django.contrib.auth expects you to have a dedicated page to log
in from.
Here's a condensed version of that view :
def login(request, template_name='registration/login.html'):
"Displays the login form and handles the login action."
manipulator = AuthenticationForm(request)
redirect_to = request.REQUEST.get(REDIRECT_FIELD_NAME, '')
if request.POST:
(does its auth checks and logging in here, then redirects if ok)
else:
errors = {}
request.session.set_test_cookie()
return render_to_response(template_name, {
'form': oldforms.FormWrapper(manipulator, request.POST, errors),
REDIRECT_FIELD_NAME: redirect_to,
'site_name': Site.objects.get_current().name,
}, context_instance=RequestContext(request))
So you can see that you NEED to call the login view with a GET (or
failed attempt with POST) request BEFORE you post your
username/password, or else the test cookie will not be set and you can't
log in.
The reason that I dont have a session cookie or a session in the db
after my first page view is that I make no modifications to the session
during that view, and so the session is not saved or a cookie set.
Looks like i'll need to implement my own view :)
Mike
Malcolm Tredinnick wrote:
> Hey Mike,
>
> On Sat, 2007-06-09 at 16:53 +0100, Mike H wrote:
>
>> Malcolm Tredinnick wrote:
>>
>>> Assuming you have the SessionMiddleware installed, you will have a
>>> session created whenever you access a page that Django is responsible
>>> for.
>>>
>>>
>>>
>> Thanks, exactly what I needed to know :) This is not happening. After
>> the first page view, I have no session.
>>
>
> Hmmm. :-(
>
> Line 28 of django/contrib/auth/views.py (in the login() method) would
> seem pretty convincing as far as trying to set the cookie goes. I wonder
> what's happening.
>
> Is the cookie not being set at the browser or not being sent at all in
> the response (something to establish)? I'm just wondering if it's
> sending a completely bogus path or something there. Checking the
> response on the browser side (e.g. with Firefox's web developer
> extension) might be an idea.
>
> This is where I was hinting that debugging prints might be needed, too.
> Poke around the login() method, the Session middleware, etc. If you
> haven't looked at middleware before, process_request() is called before
> calling any views and process_response() is called just before returning
> to the caller. Middlewares are called in order from top to bottom (or
> first to last, if you prefer to think of it as the Python sequence) for
> process_request() and last to first for process_response().
>
> Anyway, I probably don't need to teach you to suck eggs. There can't be
> too many layers involved here, since calling the login view is pretty
> straightforward (I would have thought).
>
> Good luck. Feel free to ask questions (although I'm going to sleep now,
> so I won't be answering for a few hours; plenty of other people around
> here, though).
>
> Regards,
> Malcolm
>
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" 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/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
