Right, but remember the adage "when you're a hammer, everything looks
like a nail". Certainly many applications could be enabled by a
session-ID that the server could control and manipulate reliably - but
that doesn't mean that it's the right way to do it.
> We've used the embed-an-id-in-the-url hack on several sites before. We did
> it on http://www.firstnight.org/firstnight/ so that we could keep track of
> a user intinerary and let people come back to the site later on with all of
> their preferences still set. That's roughtly akin to the shopping basket
> model. On the other hand, we're doing it on http://www.wcrb.com/wcrb/ and
> http://www.mighty.com/mighty/ so that we can provide a user-registration
> mechanism that doesn't require remembering a user-name/password
> combination.
I've spent many hours look at this from all angles and all possible
protocol abuses, and can't find a system that satisfies the requirement
of unique, cross-session identification with any modicum of security that
doesn't require one to remember a name and password. Putting the name
and password in the URL or having people save to their hotlist a URL with
a session-ID are still hacks.
> It's a hack and I don't like it,
Okay you recover yourself here :)
> and I play a number of games
> to try and make sure that the same ID isn't getting used from multiple
> users (it's not a big concern from a security standpoint - if it was we'd
> require passwords, but it's a concern nonetheless). I also have to handle
> lost IDs of course - it makes life interesting.
>
> I do believe the session-id needs to be server generated - that way we can
> use an ID that makes sense to our user-tracking system.
Hmm - this thesis needs to be explored more deeply. You suggest a
user-tracking system that is external to the actual web traffic - could
you provide some examples?
> The Netscape
> proposal for an optional expiration date is also very nice, since it allows
> trial periods and the like, something that is very common on the Web.
A server that wanted to have a "trial test period" could also implement a
fast lookup on hostname+client-generated-session-ID, and see if the time
stamp associated with that lookup exists and if it is still within the
time frame allowed. This goes against the argument against maintaining
large server-side state as I'll note below, but it means the server
doesn't have to generate expire times on session ID's (besides, this is a
lot more secure - someone could very easily write a web browser which
ignored the "expire" argument and then have indefinite access to a
section with restricted access)
> Path
> specific ids are also a requirement, many providers host multiple web sites
> that will have different id name spaces.
True that machines may host multiple sites, but why (if the server isn't
generating session ID's) would those sites not want the same session-ID?
au contrare, they might like to compare session ID's to see how much they
help each other's traffic :)
> It also needs to be possible to
> defeat cacheing - and in that respect I see the cookie proposal as very
> much akin to the standard name/password mechanism.
Er, I hope that's a typo. Any proposal made from here on out needs to be
able to support caching to some extent - publishing on the web is going
to become very difficult for anyone but large providers without it.
In fact, I'd support language in the spec that said "it is strongly
recommended that servers not generate content that depends on a
particular session-ID value" - what would be ideal is if proxy caches
did forward GET If-modified-since requests, *with* the session-ID's, so
servers who want it can still get good data without having to dish out
the whole file for every request. HTTP-NG sounds like it'll have a way
to forward on Session-ID's, too, even if the proxy never talked to the
original server when the request was made for a cached object.
> What I really want to avoid is the HotWired/NewsPage problem of "what was
> my username and password on *this* site". That's just not acceptable,
> particularly for sites which you may not use regularly.
As the person who *built* that for hotwired, I couldn't agree more! What
I really wanted was a mechaism by which browsers told me what they've
already seen, and I could generate a page based on comparing that info
with a list of "whats-new objects" I had, short blurbs of info with
timestamps and URL's attached. In fact I posted a proposal a few months
ago for a State: header which accomplished pretty much what people now
want to use Session-ID for (although State is a much better term for
it when used by applications like what's new and shopping carts).
However, after talking with a few people and watching the conversation
about shopping carts, I realized what I really wanted was a general way
to distribute those "what's-new objects" in a way that the client could
assemble them locally. The result was the realization that the what's
new" functionality was something highly generalizable for all URL's out
there, so an extension of the browser hotlist function to every now and
then (as set by the user) check up on the last-modified times of various
URL's and present the list of changed objects as a mail-reader-like
application would be the most scalable way to go. It meant HotWired
would lose the control over formatting they had, admittedly; but once
Java's around HW could distribute its own version of that "What's New"
application with their logo in the background of the main window or
something :)
The point is - there is a much better solution to "what's new" than what
HotWired is doing coming down the pipe, and instead of incremental
solutions like basing it on a second-class data object like "Session-ID",
a bigger leap would really provide bigger results.
> You could partially
> solve this by having the browser cache name/password pairs over multiple
> runs,
Ugh - *so* many problems there. Security (other people using your
browser), logistics (what happens if you use someone else's browser?) and
it does nothing to elimanate the account creation and server-side-state
problem. I think when my bosses talked about wanting to make the process
"invisible" they didn't quite realize this....
> Shopping carts embedded in ids is a cute hack, but it's a red herring. The
> real goal in my mind is to find a way to identify a user without requiring
> them to carry a separate ID for every store they walk into.
Agreed... which is why I don't think they should carry a session-ID for
every store they visit either. :)
Brian
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/