I really liked this solution... here is the simple mod_rewrite stuff I've
stuck into my httpd.conf to pull out the session_id:
RewriteEngine On
RewriteCond /your/doc_root/%{REQUEST_FILENAME} !-f
RewriteRule ^/S=([^/]+)/(.*) /$2 [E=SESSION_ID:$1]
When you set your session_id, be sure to prepend the "S=" to it. I
figured that was a much better solution then just looking for 16
characters, although I put the !-f condition in there to test if it was a
file... by the slim chance that the S={session_id} pattern is actually a
real file... it could be done away with.
After this rewrite rule there will be a $ENV{SESSION_ID} variable set for
use in any application (regular cgi included)
This will also set the $r->filename to not include the session_id which
means that mason and the like won't break down looking for the file.
Note: This does NOT change $r->uri which will still contain the session
stuff in it.
Jay Jacobs
LachNet Inc.
On Thu, 11 May 2000, Gunther Birznieks wrote:
> 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/
>
>
