I've been perusing the archives on the topic of cookie vs. url vs. user
session tracking, and I can't find a solution that is 100% effective.
Here's the scenario... using Apache::Session::DBI on a public site, where
registered users can log in to get detailed information and "place orders"
online
On Tue, 9 May 2000, Jay Jacobs wrote:
> I'm thinking of just relying on cookies, while not 100%, it's gotta be
> close to 80 or 90% which may be good for this project. But I figured
> others had faced this same issue and had an ample solution...
We use in-URL session IDs for everyone, and give
Tom Mornini wrote:
>
> On Tue, 9 May 2000, Jay Jacobs wrote:
>
> > I'm thinking of just relying on cookies, while not 100%, it's gotta be
> > close to 80 or 90% which may be good for this project. But I figured
> > others had faced this same issue and had an ample solution...
>
> We use in-URL
A mod_rewrite recipe wouldn't help you a lot, because you actually need to
parse the HTML, find all HREFs (and FORM actions) which point to your local
site and add the session information to these.
If you have a module which does process all the output from your handlers
then this would be a good
On Tue, 9 May 2000, Drew Taylor wrote:
> > > I'm thinking of just relying on cookies, while not 100%, it's gotta be
> > > close to 80 or 90% which may be good for this project. But I figured
> > > others had faced this same issue and had an ample solution...
> >
> > We use in-URL session IDs fo
Tom,
At 02:02 PM 5/9/00 -0700, Tom Mornini wrote:
>That is the tricky part. :-)
>
>Here's the sneaky way to handle it: Put the Session ID at the beginning of
>the URI. If a request comes in with a Session ID, then strip it out of
>$r->urii. If a request comes in without one, redirect them to the
On Tue, 9 May 2000, Tobias Hoellrich wrote:
> Tom,
>
> At 02:02 PM 5/9/00 -0700, Tom Mornini wrote:
> >That is the tricky part. :-)
> >
> >Here's the sneaky way to handle it: Put the Session ID at the beginning of
> >the URI. If a request comes in with a Session ID, then strip it out of
> >$r->u
On Tue, 9 May 2000, Jeffrey W. Baker wrote:
> Why is the session ID invalid just because they left for a week? Ask them
> to authenticate again and take them right back to whatever they were
> doing.
>
> On some sites bookmarking the URL with the session ID embedded is the
> optimal behavior.
>
Jeffrey,
At 02:32 PM 5/9/00 -0700, Jeffrey W. Baker wrote:
>Why is the session ID invalid just because they left for a week? Ask them
>to authenticate again and take them right back to whatever they were
>doing.
>
>On some sites bookmarking the URL with the session ID embedded is the
>optimal be
Yes,
we use our own url-rewriting implementation of Apache::Session::DBI -
we just use method calls instead of hrefs
($ui->a_href('page.html','querystring','other stuff') ) which whop a
key= into the query string.
In addition, to time out sessions we added a timestamp field to the
sessions data
On Tue, 9 May 2000, Tom Mornini wrote:
> That is the tricky part. :-)
>
> Here's the sneaky way to handle it: Put the Session ID at the beginning of
> the URI. If a request comes in with a Session ID, then strip it out of
> $r->urii. If a request comes in without one, redirect them to the same U
- Original Message -
From: "Jay Jacobs" <[EMAIL PROTECTED]>
> I've been perusing the archives on the topic of cookie vs. url vs. user
> session tracking, and I can't find a solution that is 100% effective.
I've been thinking for a while now on a "complete" state maintainance
system. Altho
"Jeffrey W. Baker" wrote:
>
> On Tue, 9 May 2000, Tom Mornini wrote:
>
> > The cool thing about this is that relative links need not be rewritten at
> > all, the browser handles it!
>
> This last part is a great point, and one that people would do well to
> heed. I hadn't considered the implic
On Tue, May 09, 2000 at 03:36:38PM -0700, Jeffrey W. Baker wrote:
> >
> > The cool thing about this is that relative links need not be rewritten at
> > all, the browser handles it!
>
> I like to use session ids at the beginning of the URL for another
> reason: the users understand it. For e
On Wed, 10 May 2000, harm wrote:
> On Tue, May 09, 2000 at 03:36:38PM -0700, Jeffrey W. Baker wrote:
> > >
> > > The cool thing about this is that relative links need not be rewritten at
> > > all, the browser handles it!
>
>
>
> >
> > I like to use session ids at the beginning of the URL f
Rule #1: Never ever link directly to a remote site, but do it through a
redirector which makes sure that nothing that doesn't have to be sent to
the remote site gets sent to it. We use a handler that "listens" on
/redirect turns urls like:
/redirect/http://www.disney.com
to the obvious
On Tue, May 09, 2000 at 04:15:29PM -0700, Tobias Hoellrich wrote:
> Rule #1: Never ever link directly to a remote site, but do it through a
> redirector which makes sure that nothing that doesn't have to be sent to
> the remote site gets sent to it. We use a handler that "listens" on
> /redirect t
At 01:40 AM 5/10/00 +0200, harm wrote:
> ...
>It doesn`t clear the referer header!
>Any suggestions for better redirection strategies? Generate a html file
>whith qualifies as ugly ;-)
>
>
Then I guess our solution qualifies as ugly - you can spit out as many
302's as you want, it won't increase
You should be able to wrap the session creation inside an eval so that if
the session has expired, your code doesn't break, it silently creates a new
session behind the scenes.
That's if you have this requirement.
Later,
Gunther
At 04:50 PM 5/9/00 -0500, Jay Jacobs wrote:
>On Tue, 9 May
On Tue, 9 May 2000, Tobias Hoellrich wrote:
> and what happens when somebody bookmarks a URL with the session-id
> prepended and comes back a week later with an invalid session-id in the URL?
They get a screen that asks them to fix their bookmark, and shows them
how. This is the only disadvantag
On Tue, 9 May 2000, Drew Taylor wrote:
> > This works on my site, because the urlspace is completely
> > ficticious. There is no disk path /home/abcdef0987654321, in fact there
> > is no /home, nor even a document root at all. I just threw in the /home
> > to make the URL look a little more fri
At 19:26 09/05/00 -0700, Tom Mornini wrote:
>On Tue, 9 May 2000, Tobias Hoellrich wrote:
>
>> and what happens when somebody bookmarks a URL with the session-id
>> prepended and comes back a week later with an invalid session-id in the
URL?
>
>They get a screen that asks them to fix their bookmark
Rodney Broom:
> I've been thinking for a while now on a "complete" state maintainance
> system. Although it would be allot of writing, I think that a
> system could be build that magically incorporates one or more of:
> - magic numbers (or session IDs)
> - cookies
> - IP tracking
> - special for
Stas, this thread is very interesting. Guide material?
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 ses
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 t
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 o
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 pub
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 p
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 prepen
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
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 fol
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 t
> Stas, this thread is very interesting. Guide material?
Yeah, sure. Someone would like to summarize things in a verbose form?
Thanks a lot!
__
Stas Bekman | JAm_pH--Just Another mod_perl Hacker
http://stas
34 matches
Mail list logo
