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.
