[drupal-devel] [bug] Some URLs get ?PHPSESSID added to them
Geary
drupal-devel at drupal.org
Tue Sep 13 04:28:37 UTC 2005
Issue status update for
http://drupal.org/node/4109
Post a follow up:
http://drupal.org/project/comments/add/4109
Project: Drupal
Version: cvs
Component: base system
Category: bug reports
Priority: normal
Assigned to: Eric Scouten
Reported by: Eric Scouten
Updated by: Geary
Status: patch (code needs review)
+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!)
Geary
Previous comments:
------------------------------------------------------------------------
Thu, 13 Nov 2003 00:22:39 +0000 : Eric Scouten
Some URLs get ?PHPSESSID=(whatever) added to them. I find this
distracting and unnecessary for anonymous users. Submitting patch #147
for consideration to remove this issue.
------------------------------------------------------------------------
Fri, 05 Dec 2003 14:39:25 +0000 : Kjartan
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.
------------------------------------------------------------------------
Fri, 05 Dec 2003 15:11:33 +0000 : killes at www.drop.org
Could you elaborate which config setting one has to tweak?
------------------------------------------------------------------------
Fri, 05 Dec 2003 15:18:11 +0000 : Anonymous
php_flag session.use_trans_sid off
php_flag session.use_only_cookies on
The first will disable the automatic addition of the session ID to
internal URLs, the second will remove support for passing session IDs
in URLs. See http://php.net/session [1] for more info. BTW the above
settings are for Apache, in PHP.ini you should not add the php_flag
part, and you should use = inbetween the name and value...
[1] http://php.net/session
------------------------------------------------------------------------
Mon, 07 Jun 2004 22:42:06 +0000 : shane
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.
------------------------------------------------------------------------
Tue, 08 Jun 2004 02:56:00 +0000 : marky
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 [2]:
"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.
[2] http://httpd.apache.org/docs-2.0/howto/htaccess.html#when
------------------------------------------------------------------------
Tue, 08 Jun 2004 04:38:32 +0000 : cel4145
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.
------------------------------------------------------------------------
Tue, 08 Jun 2004 10:39:27 +0000 : killes at www.drop.org
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.
------------------------------------------------------------------------
Tue, 08 Jun 2004 12:17:06 +0000 : robertDouglass
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.
------------------------------------------------------------------------
Tue, 27 Jul 2004 13:25:46 +0000 : JonBob
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.
------------------------------------------------------------------------
Thu, 19 Aug 2004 18:04:13 +0000 : gtoddv
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.
------------------------------------------------------------------------
Sat, 06 Nov 2004 07:17:21 +0000 : wazdog
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.
------------------------------------------------------------------------
Thu, 30 Dec 2004 20:32:35 +0000 : m_freeman2004
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
------------------------------------------------------------------------
Wed, 01 Jun 2005 19:07:53 +0000 : dr05
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!"
------------------------------------------------------------------------
Thu, 14 Jul 2005 15:25:22 +0000 : jasonwhat
Anyone else looking into this? Can one get rid of the id added onto the
url but still keep the sessions going?
------------------------------------------------------------------------
Mon, 25 Jul 2005 06:16:22 +0000 : Eric Scouten
dr05, what version of Apache and what OS are you using? I've been using
this same patch with no problems on Mac OS X, Linux, and FreeBSD-based
servers using both Apache 1.3.x and 2.0.x.
Attached patch will apply these changes to .htaccess. (IMHO, this is
useful for the majority of users; those who are smart enough to
understand the performance issues can comment out these lines.)
------------------------------------------------------------------------
Mon, 25 Jul 2005 06:57:18 +0000 : clydefrog
You forgot the patch, Eric.
------------------------------------------------------------------------
Mon, 25 Jul 2005 08:02:26 +0000 : Eric Scouten
Attachment: http://drupal.org/files/issues/htaccess-no-session-ids.patch (383 bytes)
D'oh!
------------------------------------------------------------------------
Mon, 25 Jul 2005 08:45:48 +0000 : kbahey
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) [3]. This can have disadvantages too,
such some performance impact, as well as excessive CPU utilization
(hosting company may not like it).
[3]
http://baheyeldin.com/drupal/how-to-get-rid-of-phpsessid-in-drupal-and-other-php-applications.html
------------------------------------------------------------------------
Mon, 25 Jul 2005 08:49:31 +0000 : kbahey
Here is some references: issue 21170 [4], and a forum discussion [5].
[4] http://drupal.org/node/21170
[5] http://drupal.org/node/17947
------------------------------------------------------------------------
Sat, 30 Jul 2005 16:24:47 +0000 : ufku
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
------------------------------------------------------------------------
Sun, 07 Aug 2005 12:18:31 +0000 : djnz
Attachment: http://drupal.org/files/issues/rewrite_tags.patch (468 bytes)
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 [6],
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 [7], but as it is
done deliberately (why?) I have left it alone.
[6] http://drupal.org/node/17947#comment-36339
[7] http://drupal.org/node/25852#comment-45111
------------------------------------------------------------------------
Sun, 07 Aug 2005 13:26:17 +0000 : kbahey
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?
------------------------------------------------------------------------
Sun, 07 Aug 2005 22:02:19 +0000 : djnz
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.
------------------------------------------------------------------------
Sun, 07 Aug 2005 22:23:59 +0000 : djnz
Attachment: http://drupal.org/files/issues/trans_sid.patch (1.4 KB)
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. ;)
------------------------------------------------------------------------
Mon, 08 Aug 2005 03:14:41 +0000 : kbahey
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.
------------------------------------------------------------------------
Mon, 08 Aug 2005 20:09:40 +0000 : moshe weitzman
yeah, i think that is cruft.
------------------------------------------------------------------------
Mon, 08 Aug 2005 21:15:29 +0000 : kbahey
Attachment: http://drupal.org/files/issues/common.inc-trans_sid.patch (759 bytes)
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.
------------------------------------------------------------------------
Tue, 09 Aug 2005 16:40:56 +0000 : djnz
Attachment: http://drupal.org/files/issues/both_sid_patches.patch (1.39 KB)
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.
More information about the drupal-devel
mailing list