I embedded notes into this with a short book at the end...
On Wed, 10 May 2000, Gunther Birznieks wrote:
> There is a strong reason for cookies only. Intranets and other controlled
> environments.
<snip>
I'm trying to satisfy as many clents as possible in the chaos of the
uncontrolled world of a public site.
> >User makes request:
> > if a cookie exists with session_id
> > then verify it is a valid session_id
> > if a session-url exists remove it and rely on cookies
>
> Why would both exist?
Becuase they're both set on an initial request, that way if the cookie
fails, the session is still in the url... again, uncontrolled, sloppy
world.
> > if session is expired # timed expirations as a security measure
> > auth them again if needed and/else redirect to requested page.
> >
> > else if a session_url exists with no cookie
> > verify validity and exipiration as above
> >
> > else if no cookie and no url session
> > new session, set cookie and set session-url
> >
> > timestamp the session for expiration.
> >
> >
> >Other notes:
> > Having to re-write site-wide urls seems like a bad idea. It negates any
> >caching (on both server and client sides), and forces all the pages to be
> >dynamic. Relative links (although not the ../../prettiest thing) seems
> >like the best route.
>
> I don't get this. It's still a different URL whether the id is at the end
> of the URL or the beginning. Also, the pages are not dynamic with
> mod_rewrite... mod_rewrite (in this case) is just acting upon a data
> structure on the server. The HTML files are still served as HTML files
> whether the root dir is shown as a session id
>
> The caching that you are ruining is the proxy caching. But the browsers
> will still cache the HTML and images (one would presume that multimedia
> content -- which benefits the most from a proxy cache would not go through
> the URL mangling if possible).
The thing about putting the session_id in the front is that the whole site
can then just do *static* relative linking. The problem isn't using
mod_rewrite to get to the page, the problem is linking from that page to
another while maintaining the session_id in the url. If I'm understanding
you wrong let me know, I'd be quite interested in a solution just using
mod_rewrite.
And with caching... Let's say the site rewrites the url dynamically, so
that the links are something like:
<A Href="/abcdef123456abcdef/index.html">Home page</a>
Now, for whatever unforseen reason the session_id changes (they close
their account and reopen). They hit a page that is cached on their side
with these in there, all of sudden they're back on their old session which
is invalid now. That doesn't exist if the link is "../index.html" or some
other relative link that is cached.
In addition I was also talking about server-side caching, with something
like mason where it's possible to cache a static document on the server
side to speed up the process. Think of an "about" page talking about the
company history... the session will have to be active there, they may want
to look at their account info after that, but the about page is static and
should be cached if possible.
Again, I'm just trying to get a feel for the best way to deal with the
chaos of the browsers and their users. I don't see any way to gaurantee
that 100% of the people will be able to use a session-based site while
also allowing 0 session-jumping with high-security and privacy. And if I
can increase 91% serviced to 92% serviced while assuming the end-user just
figured out what "click here" means, I'll do it.
Jay Jacobs
LachNet Inc.
