demexp-dev
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]