Re: [Summation] 100% sessions?
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.
> >
> >
> >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 s
Re: [Summation] 100% sessions?
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.
>
>
>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:
>Home page
>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
Re: [Summation] 100% sessions?
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. 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: Home page 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.
Re: [Summation] 100% sessions?
There is a strong reason for cookies only. Intranets and other controlled environments. You generally do not have to worry about the lack of cookies, and if a user does have them turned off in the organization, then you can mandate them to turn them on as corporate policy if they want to use the app. I've seen many large organizations do this without nary a cry from the users. And it speeds up development tremendously if you don't have to think about URL mangling stuff. I have to say that I do like the mod_rewrite with session id stripped from the front of the URLs a lot. Later, Gunther PS Minor comments within the message... At 11:36 AM 5/10/00 -0500, Jay Jacobs wrote: >On Wed, 10 May 2000, Roger Espel Llima wrote: > > > Jay Jacobs <[EMAIL PROTECTED]> wrote: > > > So as I see it there are essentially 2 *mostly* reliable ways, cookies > > > and url-rewriting. Both have drawbacks and neither are 100%. There > > > really isn't a way to cross-reference anything else (IP or login) becuase > > > there are valid reasons for a user to come from multiple ip addresses > > > during a session (albeit rare), and sessions may be needed without > > > requiring a user to login. > > > > > It also doesn't make sense to try to rely on both cookies and > > > url-rewriting, that would just get sloppy and waste time. The only thing > > > to do is to pick one or the other and deal with the drawbacks associated > > > with that... > > > > Why wouldn't it make sense? Some users have cookies turned off, then > > you just send them a rewritten URL. That's what I do now: send a > > session cookie with every request. If I got a session cookie from the > > client, then that's it; if not, I also add the session data at the end > > of the internal links. > >After sleeping on it I agree to a point. I think the url-session should >be first thing in the url and the site should be fully relatively linked. >Cookies are a lot "cleaner" for the user and transparent. So I've written >up pseudo-code (I learned something in college!) on the logic: > >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? > 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). >This way of doing sessions doesn't sit right with me, but I suppose when >your only tool is a hammer... > >Jay Jacobs >LachNet Inc.
Re: [Summation] 100% sessions?
On Wed, 10 May 2000, Roger Espel Llima wrote: > Jay Jacobs <[EMAIL PROTECTED]> wrote: > > So as I see it there are essentially 2 *mostly* reliable ways, cookies > > and url-rewriting. Both have drawbacks and neither are 100%. There > > really isn't a way to cross-reference anything else (IP or login) becuase > > there are valid reasons for a user to come from multiple ip addresses > > during a session (albeit rare), and sessions may be needed without > > requiring a user to login. > > > It also doesn't make sense to try to rely on both cookies and > > url-rewriting, that would just get sloppy and waste time. The only thing > > to do is to pick one or the other and deal with the drawbacks associated > > with that... > > Why wouldn't it make sense? Some users have cookies turned off, then > you just send them a rewritten URL. That's what I do now: send a > session cookie with every request. If I got a session cookie from the > client, then that's it; if not, I also add the session data at the end > of the internal links. After sleeping on it I agree to a point. I think the url-session should be first thing in the url and the site should be fully relatively linked. Cookies are a lot "cleaner" for the user and transparent. So I've written up pseudo-code (I learned something in college!) on the logic: 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 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. This way of doing sessions doesn't sit right with me, but I suppose when your only tool is a hammer... Jay Jacobs LachNet Inc.
Re: [Summation] 100% sessions?
Jay Jacobs <[EMAIL PROTECTED]> wrote: > So as I see it there are essentially 2 *mostly* reliable ways, cookies > and url-rewriting. Both have drawbacks and neither are 100%. There > really isn't a way to cross-reference anything else (IP or login) becuase > there are valid reasons for a user to come from multiple ip addresses > during a session (albeit rare), and sessions may be needed without > requiring a user to login. > It also doesn't make sense to try to rely on both cookies and > url-rewriting, that would just get sloppy and waste time. The only thing > to do is to pick one or the other and deal with the drawbacks associated > with that... Why wouldn't it make sense? Some users have cookies turned off, then you just send them a rewritten URL. That's what I do now: send a session cookie with every request. If I got a session cookie from the client, then that's it; if not, I also add the session data at the end of the internal links. -- Roger Espel Llima, [EMAIL PROTECTED] http://www.iagora.com/~espel/index.html
Re: [Summation] 100% sessions?
On Wed, 10 May 2000, Jay Jacobs wrote: > So as I see it there are essentially 2 *mostly* reliable ways, cookies > and url-rewriting. Both have drawbacks and neither are 100%. There > really isn't a way to cross-reference anything else (IP or login) becuase > there are valid reasons for a user to come from multiple ip addresses > during a session (albeit rare), and sessions may be needed without > requiring a user to login. > It also doesn't make sense to try to rely on both cookies and > url-rewriting, that would just get sloppy and waste time. The only thing > to do is to pick one or the other and deal with the drawbacks associated > with that... > > URLS: > - redirecting to a different site sends the session_id in the > HTTP_REFERER in some browsers, which ruins it for the rest of the world ;) > - requires site-wide url-rewriting or site-wide relative links (including > things like "../../index.html" which seems ugly IMO) If you're doing site-wide URL re-writing, you might as well re-write outside URL's to a redirect CGI, so that the session doesn't go in the referer. -- Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org http://xml.sergeant.org
Re: [Summation] 100% sessions?
At 02:24 10/05/2000 -0500, Jay Jacobs wrote: > So as I see it there are essentially 2 *mostly* reliable ways, cookies >and url-rewriting. Both have drawbacks and neither are 100%. Well if it's *reliability* that you are looking for, url rewriting seems to come-accross as better. None of the following points really keeps you from implementing a quite reliable scheme, depending of course on the level of security that you want. >URLS: >- redirecting to a different site sends the session_id in the >HTTP_REFERER in some browsers, which ruins it for the rest of the world ;) Writing a handler that sends a proper redirect to browsers known to handle it correctly and a redirect to the rest takes only a few lines of code. I know the latter isn't the most beautiful solution but hey, dirty browser, dirty solution :) >- requires site-wide url-rewriting or site-wide relative links (including >things like "../../index.html" which seems ugly IMO) url-rewriting can be costly, but it isn't really hard to do. And there are advantages to relative linking. >- users bookmarking with the session_id which may be expired on the server >side thus negating the bookmarked session. Well, either the session is still valid (as it would be for instance with a long-lasting cookie) and there isn't a problem, or it isn't and the user should log in again, or be redirected to another url with a proper session. >- messes up logging unless a custom logging handler, or url-rewriting >before logging is implemented Again that isn't hard or long to do. I'm not trying to say that your points are wrong and that having to implement all this is not troublesome, but url rewriting seems to me to be pretty reliable, at least compared to cookies. The user can still try to delete the session from the url, but that's the same problem with cookies. Suffice it to say cookies are *much* more likely to be off than urls :) It's more a question of doing it cleanly and efficiently than reliably imho. There are also things that can be done with domain levels under the second (eg: ses465738.domain.com) that take care of points 2 and 4 (but it's ugly). .Robin Forty two.
Re: [Summation] 100% sessions?
So as I see it there are essentially 2 *mostly* reliable ways, cookies and url-rewriting. Both have drawbacks and neither are 100%. There really isn't a way to cross-reference anything else (IP or login) becuase there are valid reasons for a user to come from multiple ip addresses during a session (albeit rare), and sessions may be needed without requiring a user to login. It also doesn't make sense to try to rely on both cookies and url-rewriting, that would just get sloppy and waste time. The only thing to do is to pick one or the other and deal with the drawbacks associated with that... URLS: - redirecting to a different site sends the session_id in the HTTP_REFERER in some browsers, which ruins it for the rest of the world ;) - requires site-wide url-rewriting or site-wide relative links (including things like "../../index.html" which seems ugly IMO) - users bookmarking with the session_id which may be expired on the server side thus negating the bookmarked session. - messes up logging unless a custom logging handler, or url-rewriting before logging is implemented Cookies: - Turned off by user - May be blocked all together by some proxies. I'm sure I missed some points, but it's all I can think of at this time. Jay Jacobs LachNet Inc.
