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
> 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
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
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
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
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
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
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
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 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
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
"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
- 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
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
Stas, this thread is very interesting. Guide material?
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
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
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.
>
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
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, 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
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
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
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
24 matches
Mail list logo
