Re: [Mod-c-users] Session structure

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

On Thu, 2006-08-24 at 15:22 -0300, Gonzalo Arana wrote:
> Hi,
> 
> I am writing this directly to you, just because I considered it to be
> more polite in this way.  I don't want to sound like a flamer :(.

Don't worry, people could spit on me, and I would take it easily ;-) I
don't mind people seeing what I've done wrong - makes me want to better
myself. And, please, do yell at me if I've done anything stupid - I'd
rather twist my ankle than produce stupid code (and leave it in my
projects). :-P

> 
> I have a couple of notes regarding current session id generation/handling:
> 
> 1) SessionID is to be set in apache configuration (via
> EHTMLSessionIdSize).   Is this actually necessary?  As a matter of
> fact, it is not honored (you can set it to '1', but the default sesion
> server will force this to be between MIN_ID_SIZE -16- AND MAX_ID_SIZE
> -256-).  This should be removed, I think.

Well, I've seen ASP.NET having a directive that lets the user decide
what size of Id one can use.

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

> 
> These are not actually errors, I would like to change this as:
> 
> 1) id generation should be handled by different plugins (a default
> plug-in must be provided)  GenerateId should receive: apache request,
> session-server-connection (it is quite easy to provide unique IDs
> based on any unique TCP connection, although we don't want that data
> to be used on all cases).

Phew, IDs must be totally secure - very hard to guess - hence, the
better the random generating algorithm, the more I'd like it. But to
make it unique, we could (of course!) use your suggested method.

Nice idea (though I think we cannot forget about randomizing it as much
as possible too).

> 
> 2) another set of plug-ins could be provided for 'session store', that
> is, session storage; whose only reponsability is to save keyed data
> (sessions).

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.

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

> 
> 4) In the near future, we could have a scheme like the one attached.
> Building replication should be quite straight forward, since the keys
> are known to be unique (some cares still apply anyway).

I haven't had the time to look into this one. Will do it tomorrow.

Bye,
---
Matej