Re: [Myghty-users] session problem

[mike b. <mi...@my...>]

> (As an aside, the code for this app is extremely cool - really well done
> (even if but a toy).)

thanks !  its meant to illustrate the "ideal" as far as I can conceive.

> 2. The shopping cart makes its calls to m.get_session() without args. It
> might be useful to see use with args (or, at least, include an example
> with args, as I didn't think it was that clear how the args work) Also,
> if you use args, and it is important to keep the args identical
> whenvever m.get_session() is called (which, I assumed it is), maybe that
> should be explicitly stated.

m.get_session() stores a per-request instance to the session object it
creates, and returns the same object over and over again within the scope
of that request.  this means the session object is only created, with the
parameters, once per request.  so the very first time it is called, the
parameters are significant.  any subsequent calls, the existing session
object is just returned.  this counts for subrequests of that request as
well...its all the same object.

less commonly, it occurs to me that if you first declare the session
inside the subrequest, then call the session in the parent request, the
parent is not going to get the same instance, and would probably break for
an is_new session too since the cookie is not present yet. (hmmm.)  that
might be worth a tweak.

>
> a. Is it possible to set the args in one place, so that one can
> subsequently call m.get_session() with no args, and be assured that
> everything is consistent?

yup, just put them in the configuration parameters for your interpreter,
i.e. apache.conf or the params you send to your standalone server, with
the prefix "session_".  then you only call m.get_session() with no
parameters.  this was the intended usage, really, since it is easier.  i
should stick some in the sample shopping cart conf file to illustrate.


> b. Also, I assume that timeount=None => forever. Maybe it should say that.

sure thing.

> c. I looked at the session code and really don't understand certain
> aspects - e.g., the hierarcy of directories, and the multiplicty of dbm
> files. Is there one dbm for each session?

there is one file per session, which is a similar scheme to
Apache::Session::File.   Although some dbm implementations create more
than one file.  The location of the files are generated subdirectories in
pretty much the same manner as Cache::FileCache.  The thing that is making
it all more complicated to track down is that the filesystem code is
turning the given ID into an MD5-hashed key before creating a file, since
its a generic file-storing method that doesnt assume its getting a
file-friendly name.  so with the session id, its already an MD5-hashed
random ID, that is then MD5-hashed again to get the filename.  if we
really want a direct session id->filename mapping, id have to change this,
which I have considered.   though if you are using the 'secret' parameter,
 the cookie sent to the browser is again an hmac hex digest of the session
ID, so from the cookie value to the filesystem, its two separate layers of
encoding.


> d. for session, it would be nice to have a get() method (as for
> dictionaries). Also, __repr__ to format as a dictionary so can easily
> print out the contents for debugging...

...sureeee thing.

> 3. Without the "secret" param, my test seems to work! So, it would seem,
> there is something wrong here...

what happens if you add the "secret" parameter to the shopping cart demo ?
 just a static string.  maybe the secret parameter has broken itself since
the last few revisions...ill take a look.  also might be good to play with
the HTTP headers firefox plugin to see if multiple values are coming out
or something.  as long as the value of the parameter stays the same for a
particular client, it should work, its just applying a translation to the
session ID before sending it out, and untranslating it upon re-entry.

- mike