Re: [Mod-c-users] Session structure

[Matej U. <mat...@gm...>]

On Fri, 2006-08-25 at 10:07 -0300, Gonzalo Arana wrote:
> > Well, I've seen ASP.NET having a directive that lets the user decide
> > what size of Id one can use.
> 
> I find quite difficult to imagine a good session ID generation
> algorithm for abritrary session length.  I would rather loose this
> feature but require to have a good sessionID generation. (what I
> demand for a 'good' algorigthm: below).

Ok, so here is what we can do:

Id structure (taken from your mail):
|<-- timestamp -->|<-- geostamp -->|<-- variable sized random bytes -->|
      4 bytes          4 bytes                   8 >= bytes

(I like 8 more :-P)

 - timestamp and geostamp will not make the Id unique

I have devised a random byte sequence generator in mod_c_dss. I guess it
is secure enough.

And I guess we'll have to create an Id generation daemon for (guess
what) Id generation :)

> 
> > > 2) Session id generation is in session backend, so if we want to use a
> > > different store (say, *sql, dbm, etc) we have to write a session id
> > > generation algorithm for each one of them.
> >
> > Aye. Would be stupid do reimplement the wheel over and over again.
> 
> Indeed :(

So the plan is to redesign the session API?

We'll have to retain the plug-in system - to be able to load and select
session types dynamically for each directory.

The API must be well defined (I know mine was pretty ad-hoc) and should
support:

 - persistent connections
 - starting a session
 - recalling an active session
 - ending a session
 - storing/retrieving binary data only (takes a load off of driver
developers - a wrapper should be responsible for more user-friendly
storage strategies)
 - it should provide some standard info about the current session: when
it was created, how many bytes are stored etc...
 - perhaps data caching (BeginTransaction - FlushTransaction) to send
data in one go.

You name it...

Well, my idea is to keep the session API as simple as possible, but it
should provide enough to create a wrapper on top of it. We will provide
a wrapper for session storage in EHTML and everyone will be happy :-)

Well, you should tell me :P


> > Well, yeah. They would use the session API to achieve this, no? Wrap
> > around it... EHTML could provide such key-value session storage. To make
> > it easier to use. Let say EHTMLApplication will have a
> > Session.SetValue(key, value) and Session.GetValue(key). I think I have
> > done something in this way already - but I forgot.
> 
> I agree, this would imply marshalling/serializing support in Session class.
> That's something I am definetely in favor of.

Yep, it is a must in EHTML at least. Of course one is not obliged to use
EHTML and could use the session API directly or with other wrappers -
not bound to EHTML.

But since EHTML is a convenience library, it should also integrate
session storage...

> 
> That's a good idea, but by 'keyed data' I was meaning 'keyed by session id'.

Isn't this actually what's being done right now? Storing keyed data?

> 
> > > 3) Shifting your current UNIX-socket-based default session handler to
> > > TCP should be quite trivial.  I would do that as well.  This way, we
> > > can have a single session server among a cluster of apaches.
> >
> > Yes it is trivial, I planned to do it at some later stage, but I never
> > got to it :P
> 
> :D I'll do it, relax.

Nice :-) There is a comment in the default server's source file - it
says:

    // TODO: Add the remote part of the server...

You should mainly copy everything that is just above this comment and
use normal sockets instead.


Things look promising to me ;-)


Enjoy,
---
Matej