?PHPSESSID= is a pain

By rjspence on 5 Aug 2004 at 17:29 UTC

Hello,

I've searched for an answer and found a couple reports from 2003 on this issue. I am however having a difficult time solving it. With the site design as it is, I have a few custom blocks showing up on the home page node, and when the url is correct without the session hash, it works fine. However, clicking home link a couple times throws the session into the url and the blocks that are supposed to be just for index.php dissapear. This is clearly a corrupted url session issue and as mentioned has been reported quite some time ago. The browsers affected are firefox, mozilla, and netscrape. IE works just fine of course. Would anyone have a php.ini fix or something that can be done to clean up the session hash out the the url string?

PS, I have added this suggestion:
php_flag session.use_trans_sid off
php_flag session.use_only_cookies on

It didn't work.
Thank you.
rjspence

Comments

4.4.2

rjspence commented 5 August 2004 at 17:33

I guess I should have mentioned that this is 4.4.2 drupal version.
I also found a report from 2004 on the issue. I'm wondering if this is fixable?

Thank you.
rjspence

did you put "php_flag sessio

kjl commented 5 August 2004 at 18:26

did you put "php_flag session.use_trans_sid off" in an .htaccess file?

Maybe your host doesn't allow php flags in .htaccess?

OR try putting it in .htaccess if you didn't.

some hosts you can put a php.ini in your web root too.

To rafferty

rjspence commented 5 August 2004 at 19:47

Hi rafferty. Thanks for responding.

Yes. I initially put the flag in the .htaccess but ended up trying it in the php.ini as well.

My server sits right here next to me. No host.

Thank you,
rjspence

That shouldn't matter

TDobes commented 5 August 2004 at 19:03

I understand the desire to not use the ?PHPSESSID nonsense because it makes URL's ugly. However, it should not affect blocks, AFAIK. Make sure that, when the blocks do disappear, you're not viewing the home page in a different manner. There are several URL's which end up at the home page:
http://yoursite/drupal/index.php
http://yoursite/drupal/
http://yoursite/drupal/node

You should really match all of those in your path for the blocks. If it is indeed the PHPSESSID which is messing things up, I would consider this a bug. Please give us an example of (a.) a URL on which the blocks appear and (b.) a URL on which the blocks don't appear, but should.

Hi Tdobes

rjspence commented 5 August 2004 at 19:58

Hi Tdobes,

Thank you for responding as well. It's not that the URL is ugly. That is just one issue. It's more that I'm missing blocks.

I have a few blocks for just home or

^(|index\.php)$ in brackets.

and I have a block or so that I need on everything but home or

(^/$|[^(drupal/index\.php)(drupal/index\.html)/]+) in brackets.

This works. However when refrshing the browser by clicking the home link, the only blocks that remain are the ones with no path settings.
Anything with a path setting vanishes when the URL includes the session hash. It is indeed viewing the home page in a different manner due to the session hash being part of the URL. However, it is still just your node home.

Here are the requested URLs:
http://www.example.com/ = works fine.

Then hit the home....
http://www.example.com/?PHPSESSID=37598069acbd6c51022ee987776e63de
loses blocks. that are set for ^(|index\.php)$. In brackets.

I hope I read your instructions correctly. I do have clean uls set and it seems to be working via the confs or the .htaccess. So the clean url filter seems to be working. At least in part.

This has to do with cookies as well. When clearing the browsers cache and clicking home link you get this more often. If you don't it may or may not based on the cookie. Most of the time the link ends up with a sesshion hash after clicking home a time or two and after clearing browser cache.

I'm probably noticing this more than some who use IE as their primary browser. IE seems to do better with this and has less problems. But I don't design based around IE for obvious reasons. So I might be seeing this more so than others who use IE more.

Thank you,
Rjspence

A quick edit to block.module

TDobes commented 6 August 2004 at 08:06

I discovered that block.module is indeed bothered by the ?PHPSESSID junk at the end of URL's. Here's a quick edit to the Drupal 4.4.2 file modules/block.module which will fix the problem:
Change the line that reads:
if ((($block['status'] && (!$user->uid || !$block['custom'])) || ($block['custom'] && $user->block[$block['module']][$block['delta']])) && (!$block['path'] || preg_match($block['path'], ereg_replace('^/(\?q=)?', '', request_uri())))) {
to read:
if ((($block['status'] && (!$user->uid || !$block['custom'])) || ($block['custom'] && $user->block[$block['module']][$block['delta']])) && (!$block['path'] || preg_match($block['path'], ereg_replace('^/(\?q=)?', '', str_replace('?'. session_name() .'='. session_id(), '', request_uri()))))) {

That should remove the ?PHPSESSID before Drupal matches the URL with your block paths. I'll propose this as a patch for CVS (soon to be 4.5) as well.

Tom

EDIT: I filed an issue with a patch that fixes this for Drupal CVS.

Super. Sorry I didn't get rig

rjspence commented 8 August 2004 at 02:54

Super. Sorry I didn't get right back to you. I really appreciate the fix. Much appreciated.

This has been applied and I'm working to test a bit more on it. It appears to be functioning as needed here. So a very big thank you for helping with this.

I'll report back any diverse negative function I get with this issue. So far, looks good.

Thank you.
Rjspence

A quick fixfor ?PHPSESSID problem

m_freeman2004 commented 30 December 2004 at 20:43

The following can be added to the .htaccess file:

# Fix for ?PHPSESSID in clean URLs
php_value session.use_trans_sid 0
php_value session.use_only_cookies 1

Notice the use of boolean values instead of on/off.

Not Working

xian commented 23 April 2005 at 07:28

The following can be added to the .htaccess file:
# Fix for ?PHPSESSID in clean URLs
php_value session.use_trans_sid 0
php_value session.use_only_cookies 1

Notice the use of boolean values instead of on/off.

After i put that in my .htaccess file which is located inside the drupal folder I could not access my site. It gave me some internal server error. I had to remove those values to access my site again.

Works only with mod_php

TDobes commented 25 April 2005 at 06:22

Those values can be placed in .htaccess iff you (or your host) is using mod_php. If not, similar entries need to be placed in php.ini. (You might be able to create a php.ini for just your site... or it may be necessary to modify the global php.ini, which you probably cannot do if you're on a shared host.)

Drupal 4.6 has moved these values to settings.php, where they are set at runtime. Unfortunately, this seems to work only occasionally.

cant log in

childhood commented 29 April 2005 at 10:15

if i use that quick fix, i cant log in as admin, the pages for anonimous users work perfectly, it's just the login that doesnt work without sessions

i use drupal 4.5.2

Works!

Jacob commented 21 February 2006 at 17:29

Thanks to m_freeman2004, it worked for me!
By the default, Drupal 4.6 comes with set of php overwrites in setting.php file:

ini_set('arg_separator.output',     '&amp;');
ini_set('magic_quotes_runtime',     0);
ini_set('magic_quotes_sybase',      0);
ini_set('session.cache_expire',     200000);
ini_set('session.cache_limiter',    'none');
ini_set('session.cookie_lifetime',  2000000);
ini_set('session.gc_maxlifetime',   200000);
ini_set('session.save_handler',     'user');
ini_set('session.use_only_cookies', 1);
ini_set('session.use_trans_sid',    0);

If one have access to .htaccess file, then
# Fix for ?PHPSESSID in clean URLs
php_value session.use_trans_sid 0
php_value session.use_only_cookies 1
works fine.

The reason is describes at http://il.php.net/manual/en/ref.session.php :

PHP is capable of transforming links transparently. Unless you are using PHP 4.2 or later, you need to enable it manually when building PHP. Under Unix, pass --enable-trans-sid to configure. If this build option and the run-time option session.use_trans_sid are enabled, relative URIs will be changed to contain the session id automatically.

.htaccess solution best for me

Marc Bijl commented 23 March 2006 at 16:32

Today I've been struggling with phpsessid... Quite a fight (:

The strange thing was: at my site I got only a phpsessid when I started browsing the site by typing the domain name, that is, only when viewing the very first page. After that, browsing the rest of the site, everything was fine and the phpsessid seemed to be gone. Typing the domain name again, yes, the phpsessid returned...

I'm running the newest 4.6 version (4.6.6) and if I'm right, I didn't have the problem with an older version at another site. Anyway, first I thought it had something to do with front page module, but that was not true.

Then I tried other things like editing settings.php (added ini_set('url_rewriter.tags','');, but nothing seemed to help...

Till I just found this post and changed .htaccess. Now phpsessid is gone, so this solution seems to do the trick!

Cool bananas...

___________________
discover new oceans
lose sight of the shore