Re: [Mod-c-users] Session structure

[Gonzalo A. <gon...@gm...>]

On 8/24/06, Matej Urbas <mat...@gu...> wrote:
> 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

Well, just for the record, I prefer public rather than private flames to me :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.

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

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

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

I believe that a 'good' session id generation algorigthm requires:

1) should be hard to predict (some randomness).
2) should be unique historically & geographycaly (I've stolen these
fancy terms from RADIUS RFCs).
2.a) historically: could include date & time & some other data.
2.b) geographycally: could include a 'hostid', or something unique.

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

Perhaps we could let session id to grow, but not to shrink below a
minimum.  A rough scheme:

Session id could be: date&time (with resolution up to microsecond) + a
sequential value (4bytes) + a random value (4 bytes minimum).

So, if that gives us (say) 32 bytes (in hex), we could let session id
to grow up to 256 bytes (in hex, for instance).  This directive could
mean extra-entropy bytes.
We would need a good random number generator.

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

I agree, this would imply marshalling/serializing support in Session class.
That's something I am definetely in favor of.

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

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

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

no prob.  This is for future development.

Regards,

-- 
Gonzalo A. Arana