Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Was the popular but sadly abused issue: http://drupal.org/node/60584
This is against cvs, and moved to session.inc where the new session regeneration code was moved.
Comment | File | Size | Author |
---|---|---|---|
#30 | session_4.patch | 964 bytes | ajwwong |
#29 | user_77.patch | 446 bytes | ajwwong |
#24 | session.inc.diff.txt | 920 bytes | drumm |
#15 | session.inc_9.patch | 995 bytes | chx |
#13 | session.inc.patch_3.txt | 1.04 KB | crunchywelch |
Comments
Comment #1
chx CreditAttribution: chx commentedSure. Simple but necessary fix for any PHP versions before 4.4.0 http://bugs.php.net/bug.php?id=32802
Comment #2
crunchywelch CreditAttribution: crunchywelch commentedLets add that to the patch for curious future code reviewers and for future removal once its not needed
Comment #3
Dries CreditAttribution: Dries commentedCoding style and documentation style need work. Punctuation, spaces, etc, ...
Comment #4
crunchywelch CreditAttribution: crunchywelch commentedCleaned uop, documentation rewritten
Comment #5
chx CreditAttribution: chx commentedI still like it...
Comment #6
drummpatching file ./includes/session.inc
patch: **** malformed patch at line 22:
Comment #7
chx CreditAttribution: chx commentedReally? It needs a bzr patch then :)
Comment #8
chx CreditAttribution: chx commentedproper file.
Comment #9
Dries CreditAttribution: Dries commentedIn the code comments, please clarify 'certain drupal configurations'. Also, we write 'Drupal', not 'drupal'. Maybe add a TODO so we don't forget to remove this cruft once we drop support for PHP 4.4.
Comment #10
chx CreditAttribution: chx commentedDries, detailing "certain Drupal configurations" is WAY beyond the scope of a code comment. Especially because I surely would forget one or two.
Comment #11
chx CreditAttribution: chx commentedGrrr.. wrong file. Have not happend since long. Sorry.
Comment #12
Dries CreditAttribution: Dries commentedYou don't have to be super-specific when you describe the configurations. But surely, there must be something generic that triggers the problem? (Code comments normally wrap at line width 78.)
Comment #13
crunchywelch CreditAttribution: crunchywelch commented'certain Drupal configurations' is misleading. I have reproduced this on normal and multisite installs on both 4.6 and 4.7. The root cause is a php bug. This is evidenced by the similar workarounds being done in other projects like gallery2. I have changed the comments to reflect this, and reformatted the comment line breaks.
Comment #14
Dries CreditAttribution: Dries commentedPatch does not apply, and line breaks are not consistent.
Comment #15
chx CreditAttribution: chx commentedComment #16
Dries CreditAttribution: Dries commentedCommitted to CVS HEAD. Thanks.
Comment #17
webernet CreditAttribution: webernet commentedThis seems to have broken login for PHP 5.1.2 - the session is opened, then the cookie is destroyed resulting in being unable to login.
Comment #18
webernet CreditAttribution: webernet commentedTesting under PHP 4.3.3 reveals the same login problem.
Comment #19
webernet CreditAttribution: webernet commentedUntil a better fix can be found - this patch needs to be rolled back.
Comment #20
Thomas Ilsche CreditAttribution: Thomas Ilsche commentedWhile I cannot confirm that it is due to this patch, I can confirm that login in HEAD is broken. The state of beeing logged in however keeps working if the login happened before update (of course just until logout).
Comment #21
rkerr CreditAttribution: rkerr commentedConfirmed to be broken on PHP 5.2.1 (OpenSUSE 10.1) with a fresh HEAD install and database.
Logging in as uid 1 through the block returns to without being logged in.
Logging in as uid 1 through user/login returns to user/1 with "access denied" message.
Comment #22
chx CreditAttribution: chx commentedCrunchywelch told me that he ran this patch for years on several installs. He is looking into the problem.
Comment #23
hunmonk CreditAttribution: hunmonk commentedi can confirm that this patch is causing the problem. i removed the offending lines and logins now work fine. please roll this back until we find a workable solution for the problem it was trying to solve.
Comment #24
drummI'll explain this when I'm not boardinfg an airplabne
Comment #25
chx CreditAttribution: chx commentedWe understand. The current code invalidates the new session cookie session_regenerate_id sends since 4.3.3 instead of invalidating the old one. Good catch.
Comment #26
Kjartan CreditAttribution: Kjartan commentedCommitted.
Comment #27
moshe weitzman CreditAttribution: moshe weitzman commenteddoes drumm's patch need to be backported?
Comment #28
(not verified) CreditAttribution: commentedComment #29
ajwwong CreditAttribution: ajwwong commentedThis is a backport attempt of drumm's patch for 4.7. I hope I did this right. I just wanted to try to make a small contribution to this dialogue.
So... as far as I can tell, the patch requires a modification to user.module [where the session_regeneration function *used* to live] as well as session.inc, I think....
So here is the patch modification to user.module of 4.7 HEAD.
Comment #30
ajwwong CreditAttribution: ajwwong commentedAnd this is the patch modification for sessions.inc.
Thanks to everyone for your hard work here...
Much love,
Albert
www.ithou.org
Comment #31
ajwwong CreditAttribution: ajwwong commentedComment #32
Caleb G2 CreditAttribution: Caleb G2 commentedNo problems logging in in IE/FF for windows, or Safari/FF for Mac with latest 4.7 head. Seems good. This is good commit, because people have definitely had problems with login. (used to myself until fixed them with patches and such)
Comment #33
killes@www.drop.org CreditAttribution: killes@www.drop.org commentedapplied
Comment #34
Chill35 CreditAttribution: Chill35 commentedProblem persists for me with Drupal 4.7.5.
Comment #35
Chill35 CreditAttribution: Chill35 commentedComment #36
Chill35 CreditAttribution: Chill35 commentedDetails :
1. You log in once, nothing happens, you log in a second time, you're logged in.
2. Sometimes you have to use a different browser than IE because you end up always remaining logged out in it.
There are no bad logs in my Drupal Admin Panel about it.
On my host I checked which version of Apache I am using...
(It happens all the time for me now, on my remote site.)
PHP Version 5.1.2
Apache/2.0.54
I upgraded Drupal to 4.7.5 from 4.7.4 (and ran update.php). Same problem.
The exact same site on my local machine works like a charm.
Here are some more info about my remote server :
Session Support enabled
Registered save handlers files user sqlite
Registered serializer handlers php php_binary
Directive Local Value Versus Master Value
session.auto_start Off Off
session.bug_compat_42 Off Off
session.bug_compat_warn On On
session.cache_expire 180 180
session.cache_limiter nocache nocache
session.cookie_domain no value no value
session.cookie_lifetime 0 0
session.cookie_path / /
session.cookie_secure Off Off
session.entropy_file no value no value
session.entropy_length 0 0
session.gc_divisor 1000 1000
session.gc_maxlifetime 1440 1440
session.gc_probability 1 1
session.hash_bits_per_character 5 5
session.hash_function 0 0
session.name PHPSESSID PHPSESSID
session.referer_check no value no value
session.save_handler files files
session.save_path /tmp /tmp
session.serialize_handler php php
session.use_cookies On On
session.use_only_cookies Off Off
session.use_trans_sid 0 0
Comment #37
Chill35 CreditAttribution: Chill35 commentedMy session.inc files says (the file installed with drupal 4.7.5) :
My question is :
Is this patch causing me a problem ? Should I do what the comment is telling me :
My remote server is runnning PHP 5.
Comment #38
salvisI don't know if I'm seeing the same problem — I'm using 4.7.5 with PHP four.three.ten and none of the patches in this thread applied yet. In the middle of a session I'm suddenly logged out, and any log in attempts just won't catch on. Logging in from another computer works just fine. In the log I see successful log-ins.
However, this is at least in part caused by ZoneAlarm. When it happens, it usually takes a day or so until I can log in again successfully, but I've had immediate success removing and recreating the ZA Privacy record for my site. Another user has reported the same problem, and he's also using ZA.
If I install the httpauth module, I can force a successful login by appending
?authenticate
to the URL, however, with the next click on a link I get an empty page and the address bar shows?PHPSESSID=
sessionid appended to the URL. This happens even though I have session.use_only_cookies On and session.use_trans_sid Off! I verified these settings in phpInfo() inside the devel module — his baffles me completely! If I cut off the session ID and re-get the page, I get the requested page, i.e. I'm still logged in.Is this the effect discussed in this thread, or can anyone point me in the right direction?
Comment #39
ajwwong CreditAttribution: ajwwong commentedRunning php 4.4.2
MySQL 4.1
Apache 2.2
FreeBSD 6.0
Drupal 4.7.5
dedicated server
Just fyi:
running drupal with patch above applied:
nevertheless -- i am still observing duplicate session entries for particular users [approximately 5% of the user base -- all of whom use internet explorer] in spite of clearing cookies:
For the user who cannot login, the sessions table data looks like this: **duplicate session entries** with same timestamp:
They have been asked to clear cookies, sessions table has been truncated, and the .htaccess file now contains the following:
and settings.php contains the following line:
Nevertheless duplicate session id's appear. I will continue to work with the users to try and track this down.
If anyone wants access to the settings of my machine to inspect or try an find a fix, please let me know and I will be happy to send the info to you.
Regards,
Albert
www.ithou.org
Comment #40
webernet CreditAttribution: webernet commented