Re: Introducing a Session header...

On Fri, Jul 20, 2012 at 8:51 AM, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
> In message <500952FE.1020402@jrn.me.uk>, Ross Nicoll writes:
>>On 20/07/2012 13:35, Poul-Henning Kamp wrote:
>
>>> Ohh, that's the disconnect:  It should _never_ share the session-id
>>> with any other site, that's sort of the entire point.
>
>>We rather do want sites to share session IDs, actually, so we can do
>>easy single-sign-on.
>
> I'm all for single-sign-on, but they need to use a different nonce
> than the session-id I'm talking about.
>
> The session-id I'm talking about, are mainly for letting HTTP routers
> chose the same server for the entire sessions, without having to
> dig through cookies.


I think it would be good to have just one of these and it could cut
down on the number of cookies a browser needs to store/track.

The REST argument seems to be a red herring to me. If people want to
write stateless servers then fine, they can use a different technique.
There have been statefull servers on the Web since 1993. That is why
the POST method is written the way it is. The design goal was to
separate out the idempotent methods from the rest.

You can't do an application like Web Mail without loca state because a
mailspool IS state.


But it is quite easy for the session-ID to be used for routing without
state at either end:

Session-ID: Base64 ( HMAC-SHA2-256 ( host-domain, client-secret ))

Client only needs to store the variable 'client secret' which is the
same for all domains. The specification does not need to be tied to
any crypto algorithm as it is just an opaque blob with at least 256
bits of randomness (the birthday attack is an issue here for a
change).


A router can then take as many bits as it needs to identify the
'bucket' to direct the response to and then map 'buckets' to back-end
servers as required to meet need.

An application can use the session-id as an index into whatever table
it has to maintain per-connection state - which is why you would need
a router in the first place.


Having said that, this is not a total slam dunk for doing client side
state as you might also want to achieve the same thing with a server
pushed token being used in an authentication scheme.


-- 
Website: http://hallambaker.com/

Received on Friday, 20 July 2012 14:33:16 UTC