mod-c-users

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

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

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

Re: [Mod-c-users] Session structure

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

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

nice, perhaps we could add process id and a sequential uint32_t.  This
way we are even closer to be 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 :)

I agree.  Although I would like to make each ethml instance to
generate its own unique session id, perhaps the best approach would be
to have a server for this matter.

Perhaps we can include a disk-based session store (ala php).  This
would make things easier (avoid writing a daemon).

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

yes, I was thinking in redesign it.  Later I'll send a document
explaining a possible approach.

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

I agree.

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

That is all of what I was thinking of.

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

I keep agreeing.

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

Amen.

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

Yes, but I would like to split session handling in:
1) session storage,
2) session id generation
3) session data serializing/marshalling.

I guess 1 & 2 need plug-in structure, while 3 does not.

So the responsability of session store is *only* to store keyed data,
not 2) nor 3).

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

Same to me.

Later on I'll submit a document summarizing all of this.

Regards,

-- 
Gonzalo A. Arana