[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Demexp-dev] Re: cookies and sessions
From: |
David MENTRE |
Subject: |
[Demexp-dev] Re: cookies and sessions |
Date: |
Sat, 16 Sep 2006 12:08:02 +0200 |
User-agent: |
Gnus/5.1006 (Gnus v5.10.6) Emacs/21.4 (gnu/linux) |
Hello Augustin,
Augustin <address@hidden> writes:
> session:
> 1) In the Drupal sense, the time period a user is logged in the site. The
> user
> is 'recognized' thanks to a cookie(2) sent by the Drupal web site. Depending
> of the Drupal settings, the cookie is valid for a few days, but it could be a
> few weeks, moths, years, too. The user is therefore recognized for that
> length of time, and the Drupal session continues.
> 2) In the Apache sense (earlier, I spoke about HTTP session - I'm not sure
> which term is correct), a session lasts until the user closes their browser
> window or until they turn off their computer. Some data may be kept for the
> duration of the session: http://php.net/session. When I mention $_SESSION[],
> I am specifically referring to a super global created by php itself which
> contains all kinds of user-related and session-related data.
> 3) in demexp, the time between login() and goodbye().
>
> We don't care about (1): I'm not messing with Drupal's sessions, and
> login/logout features.
I'm not sure that the demexp session (3) should not be integrated in
some way with the Drupal session (1).
>> But your not forced to do a login()/goodbye() for each RPC call. In
>> fact, for calls not related to an individual, e.g. question_info() or
>> max_question_id(), you can use zero as cookie without any
>> login()/goodbye().
>
> yes, that's what I am doing by default, unless required otherwise.
> So far, I make sure we have a valid login() only when I need to do get_vote().
Very nice.
>> Well, right now it pollutes the server. I have to setup a cleanup
>> process for such remaining cookies on the server.
>
> a cleanup procedure would be needed anyhow. I can do one on my side, but one
> would be needed on the server side anyhow.
Yep.
> This is less urgent. I'll mark
> this email and we can discuss further this topic once we have dealt with more
> pressing matters.
I agree.
>> > Hmmm... This forces me to store the cookie in two places. One, in the
>> > $_SESSION['demexp_cookie'] variable: this value is definitively lost at
>> > the end of the user's http session. Since I don't know how long the user
>> > is going to browse the site, I don't get a chance to call goodbye.
>> > So, I need to store the cookie in a second more permanent place (in the
>> > DB), and check it against the $_SESSION cookie. If it matches, we are in
>> > the same session. If not, I call goodbye() using the stored cookie, and
>> > ask the user to login again onto the demexp server for the duration of
>> > the new http session.
>>
>> This second approach seems also nice to me, even if it might complicates
>> your code.
>
> I just finished implementing this.
Great.
> The code is somewhat complex, so it's possible a bug has crept in, but I did
> my best to call goodbye() whenever appropriate, before calling login() again.
> We will need to test this together, when we have a test server set up.
Ok. The demo server could be used for that.
Best wishes,
d.
--
GPG/PGP key: A3AD7A2A David MENTRE <address@hidden>
5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A