Re: Digest for wub-discussion@googlegroups.com - 1 Message in 1 Topic

10 views
Skip to first unread message

Tom Krehbiel

unread,
Sep 11, 2013, 1:12:30 PM9/11/13
to wub-dis...@googlegroups.com
Hi Colin,
After chatting with you the other night about sessions, I had some
more thoughts on the subject. As I mentioned in our chat, a simple
table with (session key, keyword, value) record should be good enough
for storing values. What I didn't mention was the session table. The
session table contains one entry per session. The records would look
similar to this (ip address, session key, serial number, timeout
value, last transaction). An ip address is associated with the session
key to help prevent someone from taking over a session. The serial
number value is a random number that is set in a client cookie during
each transaction. The server checks and modifies this value during
each transaction. The timeout value is a delta time value that defines
how long a session can be idle. A background process sweeps the
session table periodically and removes sessions that have exceeded
their timeout value. The last transaction value is a timestamp for the
last transaction. Note that the session management stuff should all
happen out side the access scope of the application. Also note that
the session manager is a good place to implement throttling, perhaps
during serial number generation.
Tom K.

On Sun, Sep 8, 2013 at 8:01 PM, <wub-dis...@googlegroups.com> wrote:
> Today's Topic Summary
>
> Group: http://groups.google.com/group/wub-discussion/topics
>
> Significant Changes [1 Update]
>
> Significant Changes
>
> Colin McCormack <co...@chinix.com> Sep 08 04:14PM +1000
>
> Hi All,
>
> I've modified Site and Config to more properly use and handle
> configuration section metadata. I doubt anyone's using this, so doubt
> that it matters.
>
> I'm working on a new Session implementation, this one should work very
> well ... it's a work in progress, so don't expect too much just yet.
>
> This email is intended as a heads-up in case there's any disruption or
> damage pursuant to my mucking about ... if there is, please let me know
> ASAP, and I'll repair it.
>
> Colin
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Wub Discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to wub-discussio...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

mcccol

unread,
Sep 11, 2013, 11:45:01 PM9/11/13
to wub-dis...@googlegroups.com
Hi Tom,

On Thursday, 12 September 2013 03:12:30 UTC+10, tomk wrote:
After chatting with you the other night about sessions, I had some
more thoughts on the subject. As I mentioned in our chat, a simple
table with (session key, keyword, value) record should be good enough
for storing values.

I've added a subclass of Session, called it SimpleSession, which has these properties.  I haven't tested it, but kept it in lock-step with the Session class, and expect it'll work pretty easily.
 
What I didn't mention was the session table. The
session table contains one entry per session. The records would look
similar to this (ip address, session key, serial number, timeout
value, last transaction).

I get that these fields exist to facilitate security and admin of sessions.  I'm going to suggest ways they could be added to Session in user code within the session instance.  To that end, I will add some lambda configuration arguments which could be used to provide such functionality.

An ip address is associated with the session
key to help prevent someone from taking over a session.

I see no reason to suppose that a session can't be continued from multiple IP addresses, over time.  What you suggest might be a particular session policy, and should be implemented as such.  Your point raises the question of whether sessions can be shared between browser instances simultaneously, which is really interesting.  I think I can see uses for that mode too.  What do you think?
 
The serial
number value is a random number that is set in a client cookie during
each transaction. The server checks and modifies this value during
each transaction.

Ok.  The purpose there is to prevent capture/replay of session in the case that a session cookie is intercepted?  What's to stop the hypothetical interceptor catching this cookie, too, as a man in the middle?  I think the way to implement this would be to insist upon SSL connection for secure sessions.
 
The timeout value is a delta time value that defines
how long a session can be idle. A background process sweeps the
session table periodically and removes sessions that have exceeded
their timeout value.

This is currently implemented, slightly differently ... there's a last transaction time array by session, and a couple of methods to collect, and to close, those sessions which have been idle for more than some period (specified as in [clock add].)  I think this achieves the goal of controlling idle sessions without requiring per-session persistent storage.  Is per-session idleness useful?

I have, by design, left as much policy outside Session as I can.  I can provide accessors for all the information Session maintains, and permit a parallel session management policy object to enforce such policies.  I would be loathe to add policy level facilities where it's not clear that such policies are universal.
 
The last transaction value is a timestamp for the
last transaction. Note that the session management stuff should all
happen out side the access scope of the application.

I think it's ok for a session to close itself, as an example of session management within the session, and have made provision for that via a Session method.  TImestamp is implemented as above.

I question the virtue of trying to firewall off session management from session code.  The purpose and function of Session is to permit code to run in a context of its own, which persists over time, and (optionally) between server restarts, and which all pipelines and requests from a given browser instance can share.  Once one permits arbitrary code to run on the server, one has no control over what it can do.  I have no way to prevent any code from digging around in the Session instance and wreaking what havoc it will.

I can certainly see the point of stopping per-session code messing with Session inadvertantly, and have done that, but more than that isn't really feasible in Tcl, unless you can think of something cool to do it.
 
Also note that
the session manager is a good place to implement throttling, perhaps
during serial number generation.

Well that's a good idea.  One simple way to do that would be to cause Session to check throttling, return a Suspend reply, then after some timeout to actually perform the request processing, and Resume with its result.  Let me mull that over a while, but I think it's a clever use of the facility.

Thanks, some interesting insights here,

Colin.
Reply all
Reply to author
Forward
0 new messages