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: Augustin
Subject: [Demexp-dev] Re: cookies and sessions
Date: Wed, 13 Sep 2006 21:21:42 +0800
User-agent: KMail/1.8.2

Hi David,

This is just to keep you informed and for reference.

The discussion about cookies and sessions is confusing because we are dealing 
with 3 different cookies, and 3 different sessions.
So, some definitions are called for.

cookie:
1) food.
2) traditionally,  a little piece of information send by web sites and locally 
stored by the browser, to "remember" visitors.
3) a large integer sent back by the demexp server to the demexp client upon 
login().


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. 


> 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().

> I'm new to Drupal, to which extent lives $_SESSION[]? Any documentation
> pointer on it?

it's a php thing.
http://php.net/manual/en/reserved.variables.php#reserved.variables.session


> 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. This is less urgent. I'll mark 
this email and we can discuss further this topic once we have dealt with more 
pressing matters.


> > 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.
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.




> The user would have two cookies, one for the hard client and one for the
> web client.
>
> > Would that be a problem for you? I cannot prevent that.
>
> Yes and right now there is no way for the web client to know the exact
> state of the hard client. For example, the hard client stores number of
> seen and voted questions in a local file. To make the web client really
> usable, I need to provide API for you to synchronize with hard client
> state, but I haven't done that work yet.
>
> Let's start slowly, release early and often and add new features in an
> incremental way.


yes. 
I'm already polishing a few things, and hope to release something useable in 
the next few days, next week at the latest.

Did you find the bug with the xml implementation of vote()?




Augustin.



-- 
http://www.wechange.org/
Because we and the world need to change.
 
http://www.reuniting.info/
Intimate Relationships, peace and harmony in the couple.

http://www.gnosis-usa.com/
Revolutionary Psychology, White Tantrism, Dream Yoga...

http://www.masquilier.org/
Condorcet, Approval alternative, better voting methods.




reply via email to

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