At 01:21 PM 5/10/00 -0500, Jay Jacobs wrote:
>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.
I was under the impression that this thread is about general session
architectures... and someone appeared to be arguing that there are no
situations where cookies alone would not cut it. The reality is that there
are quite a few developers who develop using cookies alone and accept it as
their user constraint. In an intranet with controlled users where the
business wants an app out quickly, they don't care about the flexibility
for the future especially if the apps are re-engineered to new business
requirements every 6 months anyway.
> > >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.
Of course, if you put the session id at the front of the URL, then the
relative links will all work (unless they are absolute with regards to the
host).
However, it should be relatively easy to make this a lot cleaner in
conjunction with mod_rewrite... You have the URL (seen below) as
/abcdef123456abcdef/index.html
But there is no primer... If we change the URL to
/sessionid/abcdef123456abcdef/index.html
Then you can create a mod_rewrite rule that checks for /sessionid/(.*)endid/.*
And then takes the equivalent of $1 and pushes it into an environment
variable (lets call it $ENV{SESSIONID}).
Then have mod_rewrite strip the sessionid crap out of the URL and pass the
rest to the server as the TRUE url.
Then even CGI scripts (not just mod_perl ones) can take advantage of using
the $ENV{SESSIONID} to see if a sessionid was stripped out.
I'll talk about another advantage down below:
>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.
OK. But if you use mod_rewrite to catch the URL before it has been
processed by the content-handler, then the URLs will all appear without the
session id to mason or something else that is caching the static pages.
Therefore the static pages will all still appear the same to the web server
and the programs except that programs will now have the benefit of an
environment varialbe to pick the URL mangled stuff from. Plus the URL does
not have to be unmangled as long as all links are relative on the web site.
In addition, I am not SURE but this method may even unmangle the URL with
mod_rewrite BEFORE it logs to the access_log. Which is an advantage to make
your logs consistent and easy to parse by analog and other parsers.
Anyway, the capability of providing this hybrid mod_rewrite + CGI or
mod_perl solution is based on other work I did with mod_rewrite, but I
would have to test it to make sure it can be done. (as we know, mod_rewrite
is a subtle language itself).
Later,
Gunther
__________________________________________________
Gunther Birznieks ([EMAIL PROTECTED])
Extropia - The Web Technology Company
http://www.extropia.com/
