sessions and redirecting in opera

"Rik" <luiheidsgoeroe@hotmail.com> schreef in bericht
news:op.twuritleqnv3q9@metallium...
> On Fri, 10 Aug 2007 18:10:24 +0200, Scott Bryce <sbryce@scottbryce.com>
> wrote:
>>> My application examins $_SERVER[ 'REQUEST_URI' ] to determine which
>>> page to serve.
>>
>> Why?
>
> Standard practice: single 'point-of-entry' website, serving up pages as
> requested in the url. Saves a whole lot of code duplication, allthough it
> might decrease performance. Look at it like an index file in the root
> examing GET variables and serving up different pages according to the
> given values. Only, for more easily remembered urls for humans, and the
> kind of urls search-engines like, the url contains a pseudo-path: the
> actual path does not exists, but is handled by a script which might be
> anywhere.
>
>> If you have stored the URL of the page you want to go to in a cookie,
>> you should be looking for which page to serve in that cookie.
>
> Never store that kind of a thing in a cookie. Use a session and just a
> session cookie, store data in the server-side session.
>
>> Or are you examining $_SERVER[ 'REQUEST_URI' ] to determine what URL to
>> store in the cookie? Again, why? If I have a PHP script at
>> example.com/user/login, why doesn't that script know its own URL?
>
> Because the script might not be there? It's just a script, where the
> request finally ends up being processed can have very little to do with
> the requested URL.
>
>> I may be way off base here, but your approach seems odd to me.
>
> More a difference in approach, but a very normal one.
> --
> Rik Wasmus

Thanks for answering that one Rik, I couldn't have said it better. :-)

"www.gerardvignes.com" <gerardvignes@gmail.com> schreef in bericht
news:1186764444.819081.108150@i13g2000prf.googlegr oups.com...
>I ran into a login-related problem with NN4 about 6 years ago. This
> was with an ASP site. The problem might be similar enough to suggest
> somethig helpful:
>
> I used a frameset that consisted of two frames. Everything was from
> the same domain. On frame offered help links (that didn't require a
> login). The other frame offered a login screen. Upon a successful
> login, the login page was replaced by the applicaiton home page (in
> the same frame). We were using the standard ASP Session to keep track
> of the login.
>
> This worked very well in IE and NN *** until *** we added SSL to
> protect the login page. To do this, the login page url changed from
> http://www.whatever.com/login.asp to
> https://www.whatever.com:443/login.asp.
> The rest of the site url's remained the same. That broke the login
> with NN4. It still worked fine with IE.
>
> In NN4, the browser cookie was apparantly not getting set to record
> the session id and thus the login state was lost. I experimented, but
> was not able to come up with a simple solution. We ended up replacing
> the frameset with a simple login page (no frameset). This allowed the
> login to work in NN4 (cookie saved, even with SSL). Once logged in,
> the user was redirected to the actual application, which then loaded
> the frameset and two frames (help and application).
>
> It looked like the problem was caused by bad vibes between NN4,
> frames, SSL and cookies. I never found a smoking gun. I just changed
> the design, which was not great to begin with.
>
> BTW, I stopped using framesets almost 5 years ago. I stopped
> supporting NN4 about 4 years ago. Haleluja!
>
> I hope this helps.
>
> Gerard Vignes
>

"www.gerardvignes.com" <gerardvignes@gmail.com> schreef in bericht
news:1186764444.819081.108150@i13g2000prf.googlegr oups.com...
>I ran into a login-related problem with NN4 about 6 years ago. This
> was with an ASP site. The problem might be similar enough to suggest
> somethig helpful:
>
> I used a frameset that consisted of two frames. Everything was from
> the same domain. On frame offered help links (that didn't require a
> login). The other frame offered a login screen. Upon a successful
> login, the login page was replaced by the applicaiton home page (in
> the same frame). We were using the standard ASP Session to keep track
> of the login.

I don't use frames. Like you point out later on: haleluja!! ;-)

> This worked very well in IE and NN *** until *** we added SSL to
> protect the login page. To do this, the login page url changed from
> http://www.whatever.com/login.asp to
> https://www.whatever.com:443/login.asp.
> The rest of the site url's remained the same. That broke the login
> with NN4. It still worked fine with IE.

I don't use SSL either. But thanks for your input anyway.

"Rik" <luiheidsgoeroe@hotmail.com> schreef in bericht
news:op.twup20qfqnv3q9@metallium...
On Fri, 10 Aug 2007 17:39:55 +0200, amygdala <noreply@noreply.com> wrote:

> Hello all,
>
> I have posted a similar question in comp.lang.php in the past, but
> haven't
> had any response to it then. I kinda swept the problem under the rug
> since
> then. But I would really like to resolve this issue once and for all now.
>
> The problem might be PHP related but since I only develop applications
> using
> PHP, I'm not a hundred percent sure. Therefor I've taken the liberty to
> crosspost to comp.lang.php and alt.www.webmaster. I assume the majority
> of
> frequent contributors of these groups have dealt with developing session
> management also, so I'm kind of hoping your experience in this field
> might
> resolve this issue.
>
> The problem is the following:
>
> User profiles on the site I'm developing will be publically available
> through:
>
> http://www.example.com/profile/view/<username>
>
> A users own profile (when logged in) will be available through:
>
> http://www.example.com/profile/view/ or
> http://www.example.com/profile/ (which will redirect to last url)
>
> So when an anonymous user visits one of these last two pages, the
> requested
> page is stored as a referer in a session and the user is redirected to
>
> http://www.example.com/user/login/
>
> where the user is prompted to login.
>
> On succes it gets redirected to the stored referer url again. A pretty
> common procedure I would assume.
>
> This works fine on either IE or Firefox (windows). But in Opera I get
> multiple sessions created in the database of which one *does* contains a
> userId but Opera redirects back to the login page again.
>
> Only when I manually enter the target url I do get to see the logged in
> users profile page.
>
> My application examins $_SERVER[ 'REQUEST_URI' ] to determine which page
> to
> serve. So, after much testing, I thought it might have something to do
> with
> Opera's favicon requests.

Hmm, FF & MSIE equally request that damn thing, shouldn't matter I think...

> I understand that this might be difficult to interpret without seeing any
> code. But since the code is pretty extensive, and I haven't really
> narrowed
> it down to a particular few lines, I thought I describe the problem
> without
> code first. Maybe somebody has had similar experiences and knows what the
> problem could be.

It's very hard to say. Are you sure you're not actually using the HTTP
REFERER header instead of the one stored in a session? It's pretty
unreliable, and very easy to disabled in Opera, i.e. the server never gets
this header. (Don't know wether it's a standard settings, it's a setting I
use nonetheless, and stored under'quick preferences', so easily accessable
for normal users). Another easily accessed Opera feature is to disable
redirecting. If you're relying on it to transfer the user to another page,
but don't exit your script after the redirect, chances are that in Opera
it might come across as 'the same page again'. So on a redirect, always do
something like:

$target = 'http://www.example.com';
header("Location: $target");
echo 'You're be redirected to '.$target.'. Click <a
href="'.$target.'">here</a> if it doesn't work';
exit; //<-----IMPORTANT!

A very easy mistake to make is also differnce in domain (for instance with
or without 'www.' in front of it, cookies that are sent vie https aren't
set by http and vice versa).

If that doesn't work, I'd set up a testpage instead of the normal redirect
to /user/login/, and instead of redirecting, dump the session-id & the
$_SESSION array, and exit. That might give you some insight in what
happens.

It could be a path issue for the cookie also though (as /profile &
/user/login are different, maybe the cookie is set carelessly, and there
are 2 different cookies for the differents paths)... If you use
LiveHTTPHeaders in FF or Fiddler in MSIE, what do you see as Set-Cookie
statements?

If all fails, I'd appreciate a live example, as I'm quite an Opera-fan,
and I can't let this slide :P

f'upped to comp.lang.php BTW.
--
Rik Wasmus

On Fri, 10 Aug 2007 19:14:44 +0200, amygdala <noreply@noreply.com> wrote:
> <snip identical text>

Yes, that's what I said.... Or am I missing something?
--
Rik Wasmus

First off: sorry about the empty posts people. I pushed accidentally pushed
the send button (twice :-S ).

"amygdala" <noreply@noreply.com> schreef in bericht
news:46bc9d79$0$25487$9a622dc7@news.kpnplanet.nl.. .
>

<snip (very useful info nonetheless :-) >

> $target = 'http://www.example.com';
> header("Location: $target");
> echo 'You're be redirected to '.$target.'. Click <a
> href="'.$target.'">here</a> if it doesn't work';
> exit; //<-----IMPORTANT!
>

Well whatta you know!! As soon as I put this suggestion of yours after the
header("Location: $target"); it works! And mind you, not necessarily the
exit() part, but the echo part!! How strange is that? I'm loosing all sense
of logic on this one.

Could it be that Opera needs some kind of body content after a redirection
header? Or could it perhaps be that Opera indeed thinks that it should
redirect back to the login page again, since it is redirected to a page,
that redirected to the login page in the first place. lol

In other words, does Opera cache the redirect? In that it has been there
before and remembers: I need to go to the login page, cause nothing has
seemed to change?

Eerrr, that was kind of what you said already wasn't it?

I'm gonna investigate this a little more, cause this doesn't make enough
sense to me yet.

But low and behold, I got it working. Thanks a bunch so far Rik! That made
my day!

"Rik" <luiheidsgoeroe@hotmail.com> schreef in bericht
news:op.twuuoj2lqnv3q9@metallium...
> On Fri, 10 Aug 2007 19:14:44 +0200, amygdala <noreply@noreply.com> wrote:
>> <snip identical text>
>
> Yes, that's what I said.... Or am I missing something?
> --
> Rik Wasmus

LOL, sorry Rik, I'm a bit tense today, and therefor I accidentily pushed the
send button. No plagiarism intended. :)

On Fri, 10 Aug 2007 20:07:03 +0200, amygdala <noreply@noreply.com> wrote:

> First off: sorry about the empty posts people. I pushed accidentally
> pushed
> the send button (twice :-S ).
>
> "amygdala" <noreply@noreply.com> schreef in bericht
> news:46bc9d79$0$25487$9a622dc7@news.kpnplanet.nl.. .
>>
>
> <snip (very useful info nonetheless :-) >
>
>> $target = 'http://www.example.com';
>> header("Location: $target");
>> echo 'You're be redirected to '.$target.'. Click <a
>> href="'.$target.'">here</a> if it doesn't work';
>> exit; //<-----IMPORTANT!
>>
>
> Well whatta you know!! As soon as I put this suggestion of yours after
> the
> header("Location: $target"); it works! And mind you, not necessarily the
> exit() part, but the echo part!! How strange is that? I'm loosing all
> sense
> of logic on this one.
>
> Could it be that Opera needs some kind of body content after a
> redirection
> header? Or could it perhaps be that Opera indeed thinks that it should
> redirect back to the login page again, since it is redirected to a page,
> that redirected to the login page in the first place. lol

Possiblity 1:
Opera -> Tools -> preferences -> Advanced -> Network -> Enable Automatic
Redirection.

It's enabled by default, but can be disabled for whatever purpose. All the
more reason why a header redirect should be accompanied by some
information one is redirected, and a script should die()/exit() after that.

Possibility 2:
Opera get's the redirect, but still has the page with the same URL in
cache, so decides to use that one. Set some header and/or html information
these pages should not be cached.

Possibility 3:
The script isn't terminated after the first header-redirect, continues to
run, and effectively changes the redirect by a second header() call.
Putting an echo directly after it will force the headers to be sent, so
they cannot be replaced anymore, resulting in the first one being the only
one, and thus the one obeyed by the browser. Another example why one
should die()/exit() after a redirect.

<?php
//this will offcourse end in /second.html
header('Location: /first.html');
header('Location: /second.html');
?>

<?php
//this will end in /first.html
header('Location: /first.html');
flush();
header('Location: /second.html');
?>
--
Rik Wasmus

..oO(amygdala)

>Exactly. To top it off, I implemented this because I assumed that by not
>doing so, Opera's session might not be commited before the redirect.

Are you sure you really understood how sessions work? The browser's
only task is to keep the session ID, that's it. The handling of the
session itself - open, read, write, close - is done on the server.
Sessions are browser-independent, there's nothing to commit.

Micha

"Michael Fesser" <netizen@gmx.de> schreef in bericht
news:albpb3dnnonfa1bv9g0c82b1mn557ml8ab@4ax.com...
> .oO(amygdala)
>
>>Exactly. To top it off, I implemented this because I assumed that by not
>>doing so, Opera's session might not be commited before the redirect.
>
> Are you sure you really understood how sessions work? The browser's
> only task is to keep the session ID, that's it. The handling of the
> session itself - open, read, write, close - is done on the server.
> Sessions are browser-independent, there's nothing to commit.
>
> Micha

Actually I do understand how sessions work, that's why this whole thing
didn't make any sense to me. Why would it work on other browsers, but not on
Opera.

But when all logic fails, I tend to resort to ad-hoc trial and error,
including these kind of things. But Rik's latest post in which he poses some
possibilities, start to make sense. I'm gonna keep the exit() statement
behind the redirects, but I'm still gonna investigate whether my application
indeed is doing something else after the redirect, that it shouldn't.