sessions and redirecting in opera

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.

But after defining an extra RewriteRule

RewriteRule ^(.*)favicon.ico /images/favicon.gif [NC,L]

in my .htaccess file, the problem still persisted.

Are any of you formiliar with this issue?

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.

But if you desire to examine some code, I'ld be happy to put some up on a
filesharing server for you to view. (e.g. the session wrapper class and
other relevant code).

Thank you for your time and input.

Cheers.

"amygdala" <noreply@noreply.com> schreef in bericht
news:46bc8754$0$25476$9a622dc7@news.kpnplanet.nl.. .
> Hello all,

<snip>

PS.: I forgot to mention that, before redirecting, I *do* let PHP perform a
session_write_close().

amygdala wrote:

> 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.

I don't code in PHP. I have written my own session management procedures
in Perl. I will answer based on the assumption that PHP uses cookies to
manage sessions.

> 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.

(I realize I haven't snipped very well, but I don't know what to remove
and still keep my comments in context.)

Again, I don't know how PHP manages sessions, but what you are saying
here about Opera seems strange to me. If PHP is using a cookie to store
session information in the browser, then there should only be one
session. One cookie can't have multiple values.

BTW, the browser doesn't create sessions in the database. PHP is doing
that. The browser stores session information in a cookie, which can only
contain one value.

> My application examins $_SERVER[ 'REQUEST_URI' ] to determine which page to
> serve.

Why? 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.

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? Why
can't the script at example.com/user/login simply store its own URL in
the cookie?

I may be way off base here, but your approach seems odd to me.

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* containsa
> 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 settingI
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

In article <46bc8925$0$25485$9a622dc7@news.kpnplanet.nl>,
amygdala <noreply@noreply.com> wrote:
>
>"amygdala" <noreply@noreply.com> schreef in bericht
>news:46bc8754$0$25476$9a622dc7@news.kpnplanet.nl. ..
>> Hello all,
>
><snip>
>
>PS.: I forgot to mention that, before redirecting, I *do* let PHP perform a
>session_write_close().

Why? Are you using framesets? If so, why?

I do something similar on my site, and I use Opera to test. A
user gets a session cookie when first accessing any page on my
site. As long as the $_SESSION array contains no login information,
some content is restricted; any attempts to access that restricted
content go to a login page. As soon as the user logs in, $_SESSION
contains data proving that the user is logged in. $_SESSION also
contains the last page visited and next page requested, at all
times, so it's trivial to direct the user to the proper page after
logging in, using header("Location: http://example.com/xyz.php?a=b");

This works for me in Opera. At *no* time do I attempt to close the
session. That happens only when the user logs off, in which case I
delete the session.

-A

On Fri, 10 Aug 2007 18:31:55 +0200, axlq <axlq@spamcop.net> wrote:

> In article <46bc8925$0$25485$9a622dc7@news.kpnplanet.nl>,
> amygdala <noreply@noreply.com> wrote:
>>
>> "amygdala" <noreply@noreply.com> schreef in bericht
>> news:46bc8754$0$25476$9a622dc7@news.kpnplanet.nl.. .
>>> Hello all,
>>
>> <snip>
>>
>> PS.: I forgot to mention that, before redirecting, I *do* let PHP
>> perform a
>> session_write_close().
>
> Why?

A good reason would be several concurrent requests (which also might be
stylesheets, javascript, images, the lot), a website in which there are
'heavy' pages (take a long time to load), and users are likely to have
several windows open.

It is not strictly necessary to use session_write_close(), but a lot of
loading problems in a PHP-heavy site can be avoided with it. And if you're
done with a session, why not? session-closing/database-closing/unsetting
variables are just the kind of thing that might improve performance when
the server is stretched.

F'upped to c.l.php
--
Rik Wasmus

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

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

On Fri, 10 Aug 2007 18:47:24 +0200, www.gerardvignes.com
<gerardvignes@gmail.com> wrote:

> 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.

The domain http://example.com is not necessarily https://example.com. A
cookie might be set for both or just one.

For PHP -> check wether session.cookie_secure is set (will only be sent
over https) or off (will be sent to both). See also
<http://nl3.php.net/manual/en/function.setcookie.php>, for more detailed
explanation about cookies & their parameters.

--
Rik Wasmus

"Rik" <luiheidsgoeroe@hotmail.com> schreef in bericht
news:op.twuq52o5qnv3q9@metallium...
> On Fri, 10 Aug 2007 18:31:55 +0200, axlq <axlq@spamcop.net> wrote:
>
>> In article <46bc8925$0$25485$9a622dc7@news.kpnplanet.nl>,
>> amygdala <noreply@noreply.com> wrote:
>>>
>>> "amygdala" <noreply@noreply.com> schreef in bericht
>>> news:46bc8754$0$25476$9a622dc7@news.kpnplanet.nl.. .
>>>> Hello all,
>>>
>>> <snip>
>>>
>>> PS.: I forgot to mention that, before redirecting, I *do* let PHP
>>> perform a
>>> session_write_close().
>>
>> Why?
>
> A good reason would be several concurrent requests (which also might be
> stylesheets, javascript, images, the lot), a website in which there are
> 'heavy' pages (take a long time to load), and users are likely to have
> several windows open.
>
> It is not strictly necessary to use session_write_close(), but a lot of
> loading problems in a PHP-heavy site can be avoided with it. And if you're
> done with a session, why not? session-closing/database-closing/unsetting
> variables are just the kind of thing that might improve performance when
> the server is stretched.
>
> F'upped to c.l.php
> --
> Rik Wasmus

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.