session id changes in Textpattern based on URL

[whitefael]

This was driving me crazy, but I've finally figured out what is
happening, but I'm not sure why. I had to implement some extra
security for a web site that has added a blog (Textpattern). Sorry I
can't give the address out because the site is a prototype and I've
signed a non-disclosure agreement. I would type in the URL
example.com, I would enter my user name and password, and browse the
site. When I clicked on the blog link it took me to the main blog
page, but clicking any of the other links to blog articles wouldn't
work. After using the LiveHTTPHeaders plugin for Firefox, I saw that
the PHPSESSID was changing every time I accessed the blog. However it
worked on other computers no problem. Come to find out if I entered
the URL with www.example.com (notice the www) everything worked
perfectly and the sessions never reset. I think Textpattern is calling
a page called css.php using the entire URL www.example.com which is
causing the session reset if I started browsing the site using the URL
example.com.

Is this typical for sessions? To check the session, I'm doing the
following:

session_start();

if (!isset($_SESSION['valid_user'])) {
die('Restricted access');
}

The books say this is the way to do it, but is it the best/right way
to do it?

Thanks!

[Jerry Stuckle]

wh*******@gmail.com wrote:

This was driving me crazy, but I've finally figured out what is
happening, but I'm not sure why. I had to implement some extra
security for a web site that has added a blog (Textpattern). Sorry I
can't give the address out because the site is a prototype and I've
signed a non-disclosure agreement. I would type in the URL
example.com, I would enter my user name and password, and browse the
site. When I clicked on the blog link it took me to the main blog
page, but clicking any of the other links to blog articles wouldn't
work. After using the LiveHTTPHeaders plugin for Firefox, I saw that
the PHPSESSID was changing every time I accessed the blog. However it
worked on other computers no problem. Come to find out if I entered
the URL with www.example.com (notice the www) everything worked
perfectly and the sessions never reset. I think Textpattern is calling
a page called css.php using the entire URL www.example.com which is
causing the session reset if I started browsing the site using the URL
example.com.

Is this typical for sessions? To check the session, I'm doing the
following:

session_start();

if (!isset($_SESSION['valid_user'])) {
die('Restricted access');
}

The books say this is the way to do it, but is it the best/right way
to do it?

Thanks!

I don't know about Textpattern - you should ask their support people.
But www.example.com is different than example.com, and the browser won't
send a cookie from one to the other.

But when you say "calls a pages called css.php" - what do you mean? Is
this a redirect? An include? A link?

As for testing - yes, this is one way. I don't use die(), but the
concept is the same.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[harvey]

In article <3f******************************@comcast.com>,
js*******@attglobal.net says...

wh*******@gmail.com wrote:

This was driving me crazy, but I've finally figured out what is
happening, but I'm not sure why. I had to implement some extra
security for a web site that has added a blog (Textpattern). Sorry I
can't give the address out because the site is a prototype and I've
signed a non-disclosure agreement. I would type in the URL
example.com, I would enter my user name and password, and browse the
site. When I clicked on the blog link it took me to the main blog
page, but clicking any of the other links to blog articles wouldn't
work. After using the LiveHTTPHeaders plugin for Firefox, I saw that
the PHPSESSID was changing every time I accessed the blog. However it
worked on other computers no problem. Come to find out if I entered
the URL with www.example.com (notice the www) everything worked
perfectly and the sessions never reset. I think Textpattern is calling
a page called css.php using the entire URL www.example.com which is
causing the session reset if I started browsing the site using the URL
example.com.

Is

This is somewhat disturbing.

Given that this happens - how do you prevent it causing a problem - IE
how can you force this discrepancy to correct itself so the user session
always remains safe?

[Jerry Stuckle]

harvey wrote:

In article <3f******************************@comcast.com>,
js*******@attglobal.net says...

>wh*******@gmail.com wrote:

>>This was driving me crazy, but I've finally figured out what is
happening, but I'm not sure why. I had to implement some extra
security for a web site that has added a blog (Textpattern). Sorry I
can't give the address out because the site is a prototype and I've
signed a non-disclosure agreement. I would type in the URL
example.com, I would enter my user name and password, and browse the
site. When I clicked on the blog link it took me to the main blog
page, but clicking any of the other links to blog articles wouldn't
work. After using the LiveHTTPHeaders plugin for Firefox, I saw that
the PHPSESSID was changing every time I accessed the blog. However it
worked on other computers no problem. Come to find out if I entered
the URL with www.example.com (notice the www) everything worked
perfectly and the sessions never reset. I think Textpattern is calling
a page called css.php using the entire URL www.example.com which is
causing the session reset if I started browsing the site using the URL
example.com.

Is

This is somewhat disturbing.

Given that this happens - how do you prevent it causing a problem - IE
how can you force this discrepancy to correct itself so the user session
always remains safe?

Harvey,

I've never had to do it myself, but I understand you can change the
domain name for session cookies in your php.ini file, i.e.

session.cookie_domain = .example.com

To have the cookie available for all domains you must have the leading
period.

As I said - I haven't tried it, because I haven't had the problem. But
it might be your fix.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[whitefael]

I don't know about Textpattern - you should ask their support people.

Butwww.example.comis different than example.com, and the browser won't
send a cookie from one to the other.

But when you say "calls a pages called css.php" - what do you mean? Is
this a redirect? An include? A link?

As for testing - yes, this is one way. I don't use die(), but the
concept is the same.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
[e-mail]
==================

I asked the same question in the Textpattern forum, but the response
was basically RTFM with a link to the PHP sessions section on php.net.
I read the session section, but I still don't see what I did wrong in
terms of using session_start().

The css.php is an include. From what I understand it creates the link
to the CSS file based on the Textpattern configuration file.

Thanks for the response!

[Whitefael]

On May 15, 10:14 am, harvey <[e-mail]:

In article <[e-mail]>,
[e-mail] says...
This is somewhat disturbing.

Given that this happens - how do you prevent it causing a problem - IE
how can you force this discrepancy to correct itself so the user session
always remains safe?

On May 15, 10:14 am, harvey <[e-mail]:

In article <[e-mail]>,
[e-mail] says...

This is somewhat disturbing.

Given that this happens - how do you prevent it causing a problem - IE
how can you force this discrepancy to correct itself so the user session
always remains safe?

One person on the Textpattern forum did recommend doing this (I'm
assuming this goes in the .htaccess file or httpd.conf file):

<IfModule mod_rewrite.c>
RewriteEngine on

# no www ------------------
RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC]
RewriteRule ^(.*)$ http://example.com/$1 [R=301,L]
</IfModule mod_rewrite.c>
The above automatically redirects people to the non-www version of any
given url.

I'd also like to see if Jerry's suggestion works.

Thanks again for the help.

[harvey]

Does this problem affect everyone using Paypal & other services ?

I've now managed to replicate this on my test site and believe it may
well affect me but I have yet to find a solution. Nothing suggested so
far can solve this.

I use an ISP and have user access and execution rights but can't modify
either PHP.INI or apache startup files. (shared access means I'm not
allowed to re-start - obviously)

I have a site that communicates with paypal that sells data files
but I can't guarantee people will type in the WWW when they enter the
site (at whatever page) so they could start their session either with or
without it.

So I have a dilema - the required return address from paypal can either
include or exclude the WWW portion. It can't do both.

This means if there is a missmatch the sales transaction will fail.
Even worse - there is no way to identify that this was the cause
creating random transaction failures potentially (statistically over
time) of 50%

This is going to cost me money and I suspect everyone else using
any service such as this will suffer too.

This obviously isn't a minor problem.

If anyone can help - an idiots guide would be welcome ;-)

[Jerry Stuckle]

harvey wrote:

Does this problem affect everyone using Paypal & other services ?

I've now managed to replicate this on my test site and believe it may
well affect me but I have yet to find a solution. Nothing suggested so
far can solve this.

I use an ISP and have user access and execution rights but can't modify
either PHP.INI or apache startup files. (shared access means I'm not
allowed to re-start - obviously)

I have a site that communicates with paypal that sells data files
but I can't guarantee people will type in the WWW when they enter the
site (at whatever page) so they could start their session either with or
without it.

So I have a dilema - the required return address from paypal can either
include or exclude the WWW portion. It can't do both.

This means if there is a missmatch the sales transaction will fail.
Even worse - there is no way to identify that this was the cause
creating random transaction failures potentially (statistically over
time) of 50%

This is going to cost me money and I suspect everyone else using
any service such as this will suffer too.

This obviously isn't a minor problem.

If anyone can help - an idiots guide would be welcome ;-)

This isn't a problem just with Paypal - it's how cookies work in all
browsers.

You don't necessarily need to set it in your php.ini file. You should
also be able to do it in your .htaccess file (if your hosting company
allows it), i.e.

php_value session.cookie_domain .example.com

Or, you can set up your .htaccess file to automatically reroute request
from example.com to www.example.com.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================