Some URLs get ?PHPSESSID added to them - Help

This is a local PHP configuration issue. Don't see it as something Drupal should mess with, the less PHP settings Drupal messes with the better.

Could you elaborate which config setting one has to tweak?

It seems that Drupal (via the .htaccess file) already "messes with" a bunch of PHP settings. For example, my Drupal install "came with" these messed with settings:

   php_value register_globals        0
   php_value track_vars              1
   php_value short_open_tag          1
   php_value magic_quotes_gpc        0
   php_value magic_quotes_runtime    0
   php_value magic_quotes_sybase     0
   php_value arg_separator.output    "&"
   php_value session.cache_expire    200000
   php_value session.gc_maxlifetime  200000
   php_value session.cookie_lifetime 2000000
   php_value session.auto_start      0
   php_value session.save_handler    user
   php_value session.cache_limiter   none
   php_value allow_call_time_pass_reference  On

I'm not sure that adding two more "php_value" flags to the stock .htaccess file is going to arguably mess with more than already is.

Personally I find it extremely un-professional and very un-clean to have funky PHPSESSID url strings tacked onto a majority of my URLs. I've worked extremely hard to implement clean URLs (above and beyond the already great "clean url" feature of Drupal - I don't like them being turned into muck.

I'd vote that these two flags be added to the .htaccess file that is distributed with Drupal. However, I'm uncertain of the overall true impact of making these changes, so barring an technical reason - I would absolutely request this as a feature. I've implemented these in many of my production sites already (just today) - we'll see what impact they have.

It's a performance thing. You need to remember that while not everyone has edit access to php.ini, those of us that do control our own servers see no need for .htaccess directives that set php options.

From the Apache docs:

"Apache will look in every directory for .htaccess files. Thus, permitting .htaccess files causes a performance hit, whether or not you actually even use them! Also, the .htaccess file is loaded every time a document is requested."

Ok, I'm lucky in that I control my own server, so I can effectively remove the .htaccess file and move its config options to php.ini and the vhost section of httpd.conf, thus speeding up the responsiveness of my server.

But if you don't have that option there's nothing wrong with adding those directives to your directory .htaccess file. That's what it's for - it allows directory specific config options for those that don't have access to their server config.

As Kjartan said, "the less PHP settings Drupal messes with the better". I've got to agree - as far as I'm concerned it's already big enough. The "php_value short_open_tag 1", "php_value session.auto_start 0" and "php_value session.cache_limiter none" for example serve little purpose, as they mirror the installation default settings (apart from the last, where the available options are: nocache, private or public).

If you don't have the choice, use .htaccess, and add whatever directives you see fit. But please remember that not everyone uses it.

Anyway, just my 2 beads.

Why not add them, but commented out with an explanation? When I encountered this problem, I had to spend a little time on drupal.org finding the solution. However, I am familiar with the .htaccess file from doing installs. If it had been included there commented out, I would have probably remembered it. After all, this is much the same way that httpd.conf functions with it's many, optional, commented out configuration options. Just makes it easier when a non-standard configuration option has to be used.

Besides, I've also seen many Drupal sites with this problem. I suspect that some of those sites would have implemented these flags if they had been an option in the .htaccess file. And it looks bad. People that visit the sites that don't know any better will assume it's Drupal, not the lack of proper PHP settings.

It wouldn't hurt if Drupal had a better documented and possibly extended .htaccess file.
Those who whish not to use it should really not care...

session.save_handler = user should probably included as well.

If you use these settings:
php_flag session.use_trans_sid off
php_flag session.use_only_cookies on

won't it make it so that people with cookies disabled cannot have session state? And if the PHPSESSID is in the URL, isn't that an indication that the browser being used refused to take a cookie? I'd really like clarification on this, if anyone knows the answers.

The original issue is definitely by design, as these URLs need the session ID to preserve the session when running under the given PHP settings. A better-documented .htaccess is a different issue entirely.

It hasn't been mentioned in this thread or anywhere else that I can find, but this session ID issue breaks validation. I don't know is this will cause accessibility issues too. I have tried the .htaccess fix and that doesn't change anything.

The non-validating problem is another problem with your server setup. PHP can be setup to used encoded &'s or not. Your server isn't if the url isn't validating. You'd have to talk to your server admin to fix that.

This is what you have to include in the .htaccess file:

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

The code in .htaccess file:
# Fix for ?PHPSESSID in clean URLs
php_value session.use_trans_sid 0
php_value session.use_only_cookies 1
# End of fix

don't work!
Error: "Internal Server Error!"

Anyone else looking into this? Can one get rid of the id added onto the url but still keep the sessions going?

You forgot the patch, Eric.

There are cases where no parameter will fix this issue. On shared hosting systems where you do not have access to php.ini, and the hosting company has setup things in a way that they cannot be overriden.

I found this out the hard way, after lobbying for the settings to be included in the init_set() statements in the settings.php prior to 4.6 being released. They are simply ignored on some hosts. On other hosts, you need to have a php.ini of your own, if suphp or SuExec is being used.

In some cases, the only way to make things work is to compile your own PHP as a CGI (detailed writeup). This can have disadvantages too, such some performance impact, as well as excessive CPU utilization (hosting company may not like it).

Here is some references: issue 21170, and a forum discussion.

in my case (shared hosting, ini_set() disabled) a php.ini file with only this line in it solved the problem.
url_rewriter.tags = ''
you should place the php.ini in your site's base directory

Drupal already attempts to change a number of values using ini_set() in settings.php, including session.use_trans_sid which should cure this problem. Unfortunately as already noted elsewhere, session.use_trans_sid only worked in ini_set() up to PHP 4.2.3.

Rather than change the whole philosophy and change this setting in .htaccess or php.ini (neither of which work for many hosted set-ups), surely the answer is to correct settings.php as described

The attached patch does just that - it is only one line.

Note that session ids are still appended to the url when redirecting by Drupal eg after a POST. This is also easily patched, but as it is done deliberately (why?) I have left it alone.

PHPSESSIDs in the URL are a) ugly, b) negatively affects search engine indexing, and most importantly, c) is a security risk that can enable a malicious user to hijack your session.

We should work on a solution to eliminate this once and for all, and for all configurations.

The current approach (putting some PHP parameters in settings.php, or instructing users to change them in .htaccess or php.ini) has severe shorcomings: Whatever we do, there are bound to be some configurations that no amount of PHP parameters will cure.

Some hosts deny their users the ability to change some or all of the above parameters.

I discovered this the painful way with many hosts I have used, and friends and clients I have helped.

I think we need to rethink this whole session thing, in a way that we are not dependant on idiosyncracies of various hosts and PHP configurations.

Perhaps attempt to set a DRUPAL cookie and not maintain a session unless we are able to set it. This way we know that we will not have a PHPSESSID in the URL. If we are not able to set the cookie, then we allow only anonymous access that is sessionless..

I am not sure if that will work or not: what other options do we have here?

I am convinced that ini_set('url_rewriter.tags','') is the answer. I find it hard to believe that any host would go to the trouble to disable this (not just a matter of setting compile time paramaters, you would have to hack the PHP source; and why would they?) - certainly no cPanel host I have used does.

The reason the code currently in settings.php doesn't work is not because hosts disable it, it is because PHP does not support it. RTFM.

After further thought, there really is no point in appending the SID to a redirect url, so the attached patch solves this problem too.

If anyone has a problem with session IDs in URLs after applying this patch, I'll offer them free hosting myself. Maybe. ;)

You are right about the fact that the use of PHPSESSID in the URL on a redirect is totally unnecessary. That line should be removed from the base code altogether, there is no excuse for it.

As for url_rewriter.tags, I am not 100% sure, but I tried it with someone who was facing difficulties, and it did not work as far as I can recall.

In any case, your solution should go in base. It cannot hurt, unless some host has disabled it.

yeah, i think that is cruft.

Actually, since the code in common.inc should not fiddle with PHPSESSID in URL in the first place, why not junk that whole section of the code altogether?

A patch for common.inc is attached that removes this whole section. As Moshe said, this is cruft.

Yes, you are both right - I was being too kind to the code just FALSEing it out, it should just be deleted. I don't want to lose the url_rewriter.tags patch though so the attached patch has both.

+1 on this latest patch. I had a nagging problem on a fresh install of 4.6.3 in a subdirectory on a TextDrive account. If I went into admin/user, then selected 'edit' on the first user, made a change and saved it, I got the PHPSESSID in the URL. This patch fixed it for both PHP4 and PHP5.

Eric's earlier patch fixed it for PHP5 but did not fix it for PHP4. (Sorry Eric!)

Thanks for all the work on the PHPSESSID issue. After removing the code from the common.inc file and applying the trans_sid.patch my site validates xhtml 1.1 using the chameleon theme. After fixing the phpsessid issue you only need to modify the chameleon.theme file to output the xhtml 1.1 doctype info and you are ready to roll.

+1 on this.

It takes out some dead code that causing annoying PHPSESSID.

Adding the url.rewriter_tag does not always work (ISP PHP setup dependant), but does not hurt.

4.6.3 has the same code in these places, so I tried the patch too, manually.

However, it doesn't work on my hosting, where I still get PHPSESSID added on redirects after forms.

There are other factors involved, and not only this piece of code.

Removal of this piece code ensures that PHPSESSID does not appear on a redirect, provided all the other factors have been addressed first.

Search Drupal.org for PHPSESSID for other articles on this.

A summary of the points can be found in this article on my site.

That is the wrong link. The correct one is here.

The patch in #28 applies cleanly, breaks no coding standards, and in my testing just now eliminated all PHPSESSID instances. Looks ready for HEAD to me. Dries, can we get this committed, please? :-)

Committed to HEAD.

The original patch created some large problems in that you now HAVE to use cookies to handle the session id. I know that passing the session id in the URL is not ideal, but it is necessary for those users who don't accept cookies.

The attached patch from grugnog restores the code that allows you to add PHPSESSID to URLs.

This is now a feature request. Please use a new thread for that.

Really, though, it's 2006. People who don't accept session cookies sent from the originating web site are locking themselves out of half the Web out of pure paranoia. We can only baby people so far.

For those of use that are new to path application.
I am using 4.66 and I get the session IDs along with blank pages in the simple2 theme.
Please tell me how I should/apply the patch (The site is in hosted space and I cannot change PHP.ini, just .htaccess).

I have your patch, but it's not clear if I should replace existing code or run it as an application. I tried to modify includes/common.inc and it worked just halfway (blog creation resulted in a 500 error casue I assume that I did not have state between pages - POST info was lost)

I just want to say that I have retroactively applied this to my 4.6.5 site, and it works extremely well.

This is a very good thing to have; Google Analytics does some wierd things with the PHPSESSIONID's - it regards each as a seperate page, making statistics tracking very messy.

To apply this patch manually, open it up, go to the indicated file, remove all the code with a - in front of the line, and add all the code which has a + in front of the line.

There is a patch command to handle this automatically, but I am not quite fmailiar with it's details.