February 2005 - Development - lists.drupal.org

[drupal-devel] [feature] "remember me" doesn't work
by Goba 12 Feb '05

12 Feb '05

Project: Drupal Version: cvs Component: user.module Category: feature requests Priority: normal Assigned to: kbahey Reported by: marco Updated by: Goba Status: patch kbahey, please, what is the problem with setting the ini setting with ini_set() runtime? It would work without fiddling with the $path and $domain... Also note that your patch contains a lot of unrelated changes... Goba Previous comments: ------------------------------------------------------------------------ September 22, 2003 - 14:37 : marco "remember me" checkbox in the login box doesn't work; even if the checkbox is left unchecked the user is NOT forgotten when he quits the browser. Try logging in w/o "remember me", then quit the browser and open it again: you should be still logged in. What happens: when you login w/o checkbox user.module outputs a cookie with lifetime = 0 ("until session ends"); but user.module calls session_start() at the beginning, which outputs a cookie too, with the lifetime specified in .htaccess; and session_start() outputs this cookie always, so on the next page the cookie from user_login() will be overwritten. I run Mozilla 1.4; I can replicate with Drupal 4.0 and Drupal 4.2 on PHP 4.3.3, and I can replicate this on drupal.org which also runs PHP 4.3.3; OTOH I can't replicate on a site running Drupal 4.2 with PHP 4.2.2, which may mean session_start() changed with PHP 4.3.x; I looked in the changelog of PHP but couldn't find anything. I didn't have any report about this before upgrading to PHP 4.3.3, which also seems to strengthen the hypothesis of a changed behaviour in PHP. Another test I did also showed that with PHP 4.2.2 no cookie is printed by session_start() if a session cookie is found, while it is always printed in PHP 4.3.3; I double checked the configurations and didn't find anything which may cause this. If you want to investigate this, I suggest you to use Mozilla and Live HTTP Headers plugin. ------------------------------------------------------------------------ October 11, 2003 - 01:37 : moshe weitzman Can anyone confirm this? Also, how to fix? ------------------------------------------------------------------------ October 12, 2003 - 18:45 : axel(a)debian.linuxrulez.ru I agree it for Mozilla 1.0. On my site running on FreeBSD 4.7, PHP/4.3.0, Drupal CVS (Oct 3) this function also don't work. Though, with Galeon 1.2.5 cookie works ok. On localhost (Debian GNU/Linux 3.0, PHP 4.1.2, same Drupal cvs version) it works ok with Mozilla & Galeon. ------------------------------------------------------------------------ October 12, 2003 - 19:34 : al The original bug report is surely due to Drupal needing to unset the cookie that it originally stored? To fix this bug, we therefore need a check on the user login/validation stage which forcibly unsets the cookie if you don't do "remember me". I suspect Axel's problems with one of his sites and not the other are due to him blocking a cookie originally and having that site on his Mozilla's list of sites to ban cookies from, or similar. Axel - if you are genuinely having issues with remember me not working at all (and not the fault originally described in this report by Ax) then please open a different bug report. Please make sure it's a genuine problem first - i.e. clear your blocked cookies sites list in Mozilla. ------------------------------------------------------------------------ October 13, 2003 - 00:24 : axel(a)debian.linuxrulez.ru Well. I don't sure what is a bug, therefore first post the question about it to forum [1]. Answer to that question point me to this bug report. Already several users of my site [2] report me about problem with "remember me" (I don't know which browsers they use). And there are not any blocked sites in my Mozilla cookies list - from site I receive only cookie PHPSESSID that expire time shows "at end of session". [1] http://drupal.org/node/view/3601 [2] http://debian.linuxrulez.ru ------------------------------------------------------------------------ October 17, 2003 - 21:36 : dmo Expect "remember me" problems for users of Internet Explorer 6. Depending on the privacy settings, IE6 may automatically expire all cookies at the end of the browser session if your site doesn't have a compact P3P policy. See http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpriv/htm… and http://www.oreillynet.com/pub/a/javascript/2002/10/04/p3p.html for further details. ------------------------------------------------------------------------ October 18, 2003 - 03:53 : moshe weitzman since noone can reproduce this, i am marking as 'by design' ------------------------------------------------------------------------ November 25, 2003 - 08:41 : junyoung This is not a IE6 specific problem. I have seen the same symptom with IE5.5/6.0, Opera 7.0/7.1, and Konqueror 3.1.x so far. FWIW, my blog site is running with Drupal 4.2.0 + PHP 4.3.3. ------------------------------------------------------------------------ November 25, 2003 - 15:06 : remco(a)rc6.org Same problem on http://rc6.org, though the other way around. No matter what I do, my session will time out eventually. Tested using Opera 7.x, IE, Mozilla and Epiphany. ------------------------------------------------------------------------ November 25, 2003 - 16:00 : moshe weitzman reopening this case. i confirm the behavior that marco describes using rc6.org and drupal.org. i find it easiest to just turn cookie prompting on in order to watch what is happenning. what i am seeing, like marco described, is that our 'permanent cookie' which is supposed to last for a year is being overwritten in the next request with a standard session cookie that expires in the time frame specified in .htaccess. for drupal.org, standard sesson cookies last 1 month whereas the permanent cookie lasts for a year. i don't know how to fix this from within drupal. the cookie that we lay down for 'remember me' is working fine. the problem is the later overwrite which is caused by PHP's session handing, not drupal. ------------------------------------------------------------------------ November 26, 2003 - 13:35 : moshe weitzman To make matters more complicated, I cannot reproduce this using PHP as an ISAPI module on IIS ------------------------------------------------------------------------ November 26, 2003 - 20:07 : Dries Maybe we can set a "remember" bit in the session table and periodically wipe users who don't have the "remember"-bit set. The wiping part could be added to sess_gc() ... ------------------------------------------------------------------------ December 4, 2003 - 02:30 : joshk I have this problem w/musicforamerica.org The really maddening thing is that I have another install of drupal 4.3 on the same webserver and it works just fine. If the problem is with drupal's cookie being overwritten by a PHP session cookie, can this be fixed by giving the cookies different names? Sounds too simple to be the solution... ------------------------------------------------------------------------ December 12, 2003 - 17:48 : ykoehler http://ca.php.net/manual/en/function.session-set-cookie-params.php Even though drupal is sending a cookie, it should always set this PHP parameter so that the session_start() call will use the same value, or not send any cookie at all by itself and let session_start() do it with, again, a call to this function to set the correct parameter. The reason why you don't get the same on a site basis is probably due to the different php.ini used for those sites as the default depends on the installation and not drupal which is probably why only some get the bug if there's such a thing. ------------------------------------------------------------------------ December 30, 2003 - 21:50 : paul(a)murphymaphia.com I am having the opposite problem. Even if I check the "remember me" box my session ends when the browser closes and I'm forced to log in the next time I return to the site. No cookie is EVER set by my site. http://www.murphymaphia.com ------------------------------------------------------------------------ January 20, 2004 - 18:31 : mathias Charles Miller has written a persistent login cookie best practices [3] i feel is worth reading. [3] http://fishbowl.pastiche.org/2004/01/19/persistent_login_cookie_best_practi… ------------------------------------------------------------------------ February 11, 2004 - 19:20 : paul(a)murphymaphia.com Has any progress been made on this? I have spent a lot of time in the code and can't manage to track this problem down. If anyone has any ideas, thoughts, etc to share, post them here so we can get this solved. ------------------------------------------------------------------------ February 12, 2004 - 06:07 : dmjossel I have this problem (remember me feature not working) in Drupal 4.3.x on PHP 4.3.2. I do NOT have it on Drupal 4.2 on PHP 4.3.2, in exactly the same environment. So perhaps sessions have changed in PHP 4.3.x, but this still didn't break Drupal 4.2, only 4.3.x. ------------------------------------------------------------------------ February 26, 2004 - 14:47 : moshe weitzman Attachment: http://drupal.org/files/issues/_4drupal (5.3 KB) Here is a patch which attempts to resolve this problem. I took Josh's suggestion - just rename the permanent cookie so it get overwritten by the PHP session cookie. So this patch names our permanent cookie 'remember_me'. The value of this cookie is the current sessionID. This cookie is checked in sess_read(). It is set just as before, in user_login(). I refactored sess_read() a bit for cleaner flow. It uses a new helper function called sess_construct_user(). Feedback welcome. Since not everyone experienced a problem with remember me, I'm particlarly interested in feedback from those who did. ------------------------------------------------------------------------ March 2, 2004 - 11:43 : dmjossel No observable effect. Users who click "remember me" are still logged out after a period of inactivity or a browser restart, as is true in 4.3.2 (but not true in 4.2 on the same machine). Just out of curiosity I made similar changes in a copy of 4.3.2, renaming the cookie-- also with no effect. What *is* odd is that I used to see this problem using Drupal.org itself. But I seem now to have been logged in for quite awhile (several days) without having to reauthenticate, despite long periods of inactivity and browser restarts. Has some change other than this patch been made to CVS running on the live site? ------------------------------------------------------------------------ March 2, 2004 - 12:21 : dmjossel One more follow up: the patch re-enables the "remember me" button on logon and the preferences for the user.module, but not the "logout" button in the user info block. ------------------------------------------------------------------------ March 6, 2004 - 17:33 : moshe weitzman The logout link never left, so naturally this patch does not re-instate it. By "user-info" block, i'm guessing that you mean the 'Navigation' block which holds the menu(). Drupal.org issues session cookies for a month so you can remain logged in for a long time. Anyone else have feedback on this patch. It is working for me. ------------------------------------------------------------------------ March 6, 2004 - 18:01 : Jeremy(a)kerneltrap.org Your patch works perfectly for me. I tested with three browsers (from Linux): Mozilla Firefox, Konquerer, Internet Explorer (via Wine) I did the following with each: 1) with latest CVS installation, I log in then restart my browser. I have to relogin. 2) I applied your patch to my CVS installation. 3) I logged in w/o checking "remember me". I then restart my browser, and I'm not logged in. 4) I logged in w/ "remember me" checked. I restart my browser, and I'm still logged in. 5) I logged in w/ "remember me" checked. I click logout, then restart my browser. I have to login again. ------------------------------------------------------------------------ April 9, 2004 - 02:09 : Brian(a)brianpuccio.net Using weitzmann's patch works for me. I had no problem when running 4.3.0, 4.3.1, or 4.3.2 on my site, but adding 4.4.0 I had to log in each time. Applying the patch to my (next to stock, but ever so slightly modified) install of 4.4.0 fixes the problem and I am remembered across browser tab closings, browser closings and system restarts. Thank you greatly. ------------------------------------------------------------------------ April 11, 2004 - 18:18 : Jeremy(a)kerneltrap.org Attachment: http://drupal.org/files/issues/session.inc.patch (651 bytes) I believe there is a small bug in weitzman's patch. I've been running with it applied on KernelTrap.org for some time, with much positive feedback from users. However, I noticed that occasionally I become a phantom surfer -- I'm logged in and accessing pages, but I don't show up in the "Who's online" block. I suspect the online guests number is low, too. After a little digging, I came up with the attached simple patch. I have yet to confirm if it solves the phantom surfer problem. Essentially, when we log in with a cookie we also update the sessions table timestamp. To use, first apply weitzman's patch (earlier in this thread), then apply this one. ------------------------------------------------------------------------ April 11, 2004 - 22:28 : Jeremy(a)kerneltrap.org Attachment: http://drupal.org/files/issues/session.inc_0.patch (584 bytes) My earlier patch didn't work. It was redundant with sess_write(), and added nothing new. Hence, it didn't fix the "phantom user" that I've been experiencing. Now, however, I believe I fully understand what's going wrong. Essentially what's happening is a user is being loaded via the remember_me cookie, but their session id is different. Thus, the db_query in sess_write() fails to update a user session in the database. This patch detects that failure and acts accordingly by creating a new entry. This patch applies against drupal 4.4 with weitzman's patch [4] applied. [4] http://drupal.org/files/issues/_4drupal ------------------------------------------------------------------------ April 15, 2004 - 08:39 : mabster Still seems to be a bit flakey. I get logged out every once in a while at work for some reason (during the day). And every time I move from my work to my home machines (or vice versa) I need to login again. Does the cookie base itself on my IP address or something? Could it be that because I'm switching between two different PCs that it can't remember my session details? ------------------------------------------------------------------------ April 22, 2004 - 03:19 : dmjossel I've upgraded the site Rampancy.net to Drupal 4.4 and applied Weitzman's patch. The behavior I'm seeing now I don't completely understand. Logging in to the site, you can quit the browser and stay logged in. But after a period of inactivity, somewhere between 30 and 60 minutes, the session expires and you have to log in again. I don't see this behavior on drupal.org. php.ini on the server is set for session cookies to last for 30 days. Drupal, by default, is supposed to give cookies that last 1 year. Is there anything else I should be looking at? Apparently some admins have this problem and others don't. Server info: FreeBSD synfibers.com 4.7-RELEASE-p22 FreeBSD 4.7-RELEASE-p22 #29: Tu i386 Apache/1.3.27 OpenSSL/0.9.7 (Unix) PHP/4.3.4 registered session save handlers are files and user. (local value is user) ------------------------------------------------------------------------ April 22, 2004 - 04:20 : mabster Yes, dmjossel's description matches the behaviour on my site (www.madprops.org) We're a hosted site, so I'm not exactly sure of the server's details. I'm fairly certain it's Windows2003. Definitely a Windows flavour, anyway, which means that this problem (with the patch applied) is not restricted to Linux. ------------------------------------------------------------------------ April 23, 2004 - 11:26 : dmjossel Apologies first for using this like a forum... mabster, upload a file to the server with the phpinfo(); in it (inside PHP tags of course). What values does it show for cookie-related functions? For session_save_handler? Perhaps there is a common element in server configuration in these two cases, despite the different operating systems. ------------------------------------------------------------------------ April 23, 2004 - 11:48 : mabster session.save_handler = files session.cookie_domain = no value session.cookie_lifetime = 0 session.cookie_path = / session.use_cookies = On session.use_only_cookie = Off Other info (at least until someone tells me that publishing this info is dangerous and I remove the file) here [5]. [5] http://www.madprops.org/info.php ------------------------------------------------------------------------ April 23, 2004 - 17:12 : dmjossel Suggestions... try setting session.use_only_cookies =1 either in php.ini, or if you don't have access to that, by using ini_set in drupal's php.conf and see if that has any effect. Next change Drupal's site configuration for the user module, and toggle whether you allow users to choose whether or not to be logged out (this produces the "remember me" cookie if you've installed weitzman's patch) or choose "users are never logged out". Neither of these seem to help here, but perhaps they'd help you. I noticed that until I set my browser to "accept all cookies automatically" and set session.use_only_cookies =1, I was getting the PHPSESSID cookie, but not the remember_me cookie. Now I get them both... but still logged out after 30 minutes of idle time, no matter what. ------------------------------------------------------------------------ April 23, 2004 - 17:26 : moshe weitzman those are not the session values that ship with drupal (see .htaccess file). for example, session_save_handler has to be 'user'. otherwise, you are not using drupal's session table and your 'remember me' will fail. since you are using IIS, you have to set your php.ini with values like those found in .htaccess. .htaccess files are only respected by Apache (and even then, not always. depends on your web host). ------------------------------------------------------------------------ April 24, 2004 - 01:39 : mabster Just out of interest, weitzman: How does drupal.org's 'remember me' work? I installed a cookie inspector on my machine at work, and didn't see any 'remember me' values in drupal.org's cookie. Does it use a different system? I will see what our host can do about changing the php.ini values. Since there are many sites hosted on that one box, it'll be a long shot to get them to change it. ------------------------------------------------------------------------ April 24, 2004 - 18:21 : dmjossel Try tweaking the value of session.gc_maxlifetime either in the .htaccess file or in php.ini. The default value in the .htaccess file seems to be 1440 seconds-- or 24 minutes, almost exactly the amount of time my sessions were lasting before being forced to log in again. I've increased this value, and now I'm seeing the remember_me cookie stay with the same value, while the PHPSESSID cookie is constantly being replaced by a new one-- but I don't have to log in again. ------------------------------------------------------------------------ April 25, 2004 - 02:23 : dmjossel Well, it's the next morning here, and I'm still logged in at Rampancy.net and the other Drupal 4.3 sites that are hosted on the same machine. I think at least this might be a workaround for those who have this problem and Weitzman's patch alone doesn't solve it. ------------------------------------------------------------------------ April 26, 2004 - 02:02 : dmjossel After a longer period of inactivity (equal to the value of session.gc_maxlifetime) the sessions ALWAYS seem to log the user out, regardless of the remember_me cookie value, the PHPSESSID value, or the configuration settings for the user module. ------------------------------------------------------------------------ May 6, 2004 - 12:34 : Robert L I can confirm #41, have tried changing some of the sessions vars in .htaccess, but this did not solve the problem. Sessions are destroyed after some time of browser inactivity (some hours). At the browser side things look oke, it happens with Mozilla and IE. Have not tested the patch yet, I am not using the remember me cookie option, and this looks another unrelated (?) problem to me. I use PHP 4.3.6 with Apache 2. ------------------------------------------------------------------------ June 6, 2004 - 03:41 : Anonymous I fixed it very simply by adding the line: session_set_cookie_params(0, "/dev/null"); immediately before the call to session_start(). This causes the cookie that PHP sets to only apply to the path "/dev/null" which, of course, doesn't exist. Thus, the cookie that Drupal's setcookie() call sets, with a path of "/", is held on to by the browser, and Drupal goes back to its old behaviour. It's a hack, but it works. A better long-term solution would be for Drupal to use the session_set_cookie_params() call to set the expiry time, rather than its own call to setcookie(). Tim Bates ------------------------------------------------------------------------ June 6, 2004 - 18:37 : bertboerland(a)www.drop.org I am sorry to say, that adding a line like that in user.module doesnt do the trick for me (running php 4.2.3/drupal 4.). Can it be that this might work under certain conditions which differ from mine? Anyone else still working on this *critical* bug? I am not changing the status but I think it should still read "active"? ------------------------------------------------------------------------ June 8, 2004 - 09:58 : bertboerland(a)www.drop.org never mind my previous remark... ------------------------------------------------------------------------ August 10, 2004 - 02:53 : moshe weitzman perhaps someone will take interest in this bug. i hope not to release another drupal version without 'remember me'. ------------------------------------------------------------------------ August 13, 2004 - 22:49 : seanr This used to work for me. Now I hear it's been completely disabled. Why? I'd rather have a feature that works for most users and not some than not have the feature at all. ------------------------------------------------------------------------ September 22, 2004 - 17:39 : Anonymous We dropped the whole 'remember me' posiibility in drupal 4.5. If it is - strategically seen - a good move, is another story, but now marked this as "Won't fix". ------------------------------------------------------------------------ September 22, 2004 - 21:35 : moshe weitzman umm - thanks 'anonymous'. this is a valid feature request, even if it isn't a valid bug anymore. marking as such. ------------------------------------------------------------------------ October 14, 2004 - 04:45 : jasper this is a bug actually. If you don't think so, you really aren't thinking about user experience. ------------------------------------------------------------------------ October 19, 2004 - 19:48 : jasper I am having this problem with 4.5. After you login, the cookie that is set to expire in a month is overwritten by a session cookie, so remember me doesn;t work. I "fixed" this by hacking user.module to set its cookie to a non-existant path. Maybe that will mess something up. I notice that drupal.org overcomes this by setting the initial cookie to "host: drupal.org" and the second cookie to "domain: .drupal.org" Where is this documented? How do you do that? ------------------------------------------------------------------------ October 21, 2004 - 17:43 : Anonymous I was having the same problem. I changed user.module's call to setcookie() so that the cookie would expire after 2000000 seconds. That fixed it for me. Now I don't have to login every time I visit. I hope I didn't break anything else, though. setcookie(session_name(), session_id(), FALSE, $path); becomes: setcookie(session_name(), session_id(), time() + 2000000, $path); ------------------------------------------------------------------------ October 22, 2004 - 04:03 : dtan Ya, suddenly noticed that I had to login everytime . . . not a huge deal, but is a bit of a pain. Should this be a configurable option for the site?? Obviously from the length of this issue, people feel it is a useful feature. . . dtan ------------------------------------------------------------------------ October 27, 2004 - 05:32 : tvst I WANT THIS FEATURE BACK! Sure, there were problems with it -- but let's fix the bug instead of killing a nice feature. ------------------------------------------------------------------------ November 4, 2004 - 00:02 : Goba Dries just committed a patch, which removes that superflous cookie setting, so session time in upcoming versions will be determined by the PHP settings, and short lived cookies will not be set. Until new versions are released, it is completely safe to remove the setcookie line in user.module (and the preg line above that), and it solves the problem of users needing to login everytime. ------------------------------------------------------------------------ November 5, 2004 - 07:02 : Anonymous wow. thanks. this was breaking my sites ------------------------------------------------------------------------ December 14, 2004 - 18:06 : kbahey This way, the PHP settings are the ones that determine the session length. Wouldn't it be better to have an admin option that allows users to set their session length? with a global default for sessions (e.g. 1 week, 2 weeks, 1 month, ...etc.) If this option is enabled, then it can be overriden by the user individually too. This is a better scheme than having a forced global setting outside Drupal, on the PHP level for all users. What do others think? ------------------------------------------------------------------------ February 3, 2005 - 19:50 : kbahey Reviving this issue. The session length should be an option that the administrator, or the end user can set. We should not rely on the PHP settings alone. ------------------------------------------------------------------------ February 12, 2005 - 01:54 : kbahey Attachment: http://drupal.org/files/issues/use-module-session.patch (1.92 KB) I feel that removing the setcookie() call was not the right thing to do. Session length should not be relegated to .htaccess or php.ini, but should be an application feature. I am attaching a patch that reinstates this functionality via a configuration option. The sysadmin determines how long visitors should have their session for, and a cookie is set for them with the appropriate lifetime. Please look at this rationally and objectively and do not dismiss it offhand because 'too many options are bad'. I had to go through php.ini and .htaccess hell for the last few months because my hosting company has implemented PHP suExec (hence .htaccess cannot set php parameters), then moved to another machine with .htaccess reinstated. This also allows people (like me) who serve several domains from a single Drupal installation to set the session length differently for different domains. Moreover, the Drupal end user should not have to go through fiddling with .htaccess values to get this functionality back. ------------------------------------------------------------------------ February 12, 2005 - 12:51 : Bèr Kessels -1 for yet another config option. Thisis a (very) advanced feuature, that will never have to be changed on a site. Therefore we need to give it a good default, and if people really want to chage it, those few can do so in conf.php. Bèr ------------------------------------------------------------------------ February 12, 2005 - 14:57 : Goba Please *do not use setcookie()* to overwrite the session cookie! The problem before was that $path and $domain were not the same as set by the session handler cookie, and so the session handler cookie was not overwritten. This behaviour depends on host configuration... See, you introduce a $path variable in your patch, which is not set, and you don't care about the cookie domain... These were the main problems with the previous aproach, and this is why the setcookie() was removed. You should deal directly with the session ini settings! So please ini_set() the session cookie lifetime, if .htaccess is not enough for you, and let the session handler set the proper cookie. ------------------------------------------------------------------------ February 12, 2005 - 15:59 : kbahey Attachment: http://drupal.org/files/issues/user-module-session-2.patch (8.89 KB) Getting the sysadmin to tweek the .htaccess or php.ini is a tedious thing. If we can provide a better interface for them to do this, then it is better. Every time PHP gets upgraded by my hosting company or move machines, things do not work. With this patch, the sysadmin can set how long sessions are valid for. This version of the patch still overrides the session cookie, but uses the correct path. I am seeing reluctance to putting this in CVS, based on 'yet another option' objection, or it being a cookie. While I can sympathise with the objections, and see their point of view, I do not see another solution being proposed to those who asked for this feature to be brought back. See for example comments 46, 49, and 54. Taking away a feature is not a good thing. I would rather have had this be an end user settable option (a global default for the site, and a per user settable option). Until the feature is back with a technical solution that is acceptable to the powers that be, users can use this patch for CVS. -- View: http://drupal.org/node/2974 Edit: http://drupal.org/project/comments/add/2974

1 0

[drupal-devel] [feature] "remember me" doesn't work
by kbahey 12 Feb '05

12 Feb '05

Project: Drupal Version: cvs Component: user.module Category: feature requests Priority: normal Assigned to: kbahey Reported by: marco Updated by: kbahey Status: patch Attachment: http://drupal.org/files/issues/user-module-session-2.patch (8.89 KB) Getting the sysadmin to tweek the .htaccess or php.ini is a tedious thing. If we can provide a better interface for them to do this, then it is better. Every time PHP gets upgraded by my hosting company or move machines, things do not work. With this patch, the sysadmin can set how long sessions are valid for. This version of the patch still overrides the session cookie, but uses the correct path. I am seeing reluctance to putting this in CVS, based on 'yet another option' objection, or it being a cookie. While I can sympathise with the objections, and see their point of view, I do not see another solution being proposed to those who asked for this feature to be brought back. See for example comments 46, 49, and 54. Taking away a feature is not a good thing. I would rather have had this be an end user settable option (a global default for the site, and a per user settable option). Until the feature is back with a technical solution that is acceptable to the powers that be, users can use this patch for CVS. kbahey Previous comments: ------------------------------------------------------------------------ September 22, 2003 - 08:37 : marco "remember me" checkbox in the login box doesn't work; even if the checkbox is left unchecked the user is NOT forgotten when he quits the browser. Try logging in w/o "remember me", then quit the browser and open it again: you should be still logged in. What happens: when you login w/o checkbox user.module outputs a cookie with lifetime = 0 ("until session ends"); but user.module calls session_start() at the beginning, which outputs a cookie too, with the lifetime specified in .htaccess; and session_start() outputs this cookie always, so on the next page the cookie from user_login() will be overwritten. I run Mozilla 1.4; I can replicate with Drupal 4.0 and Drupal 4.2 on PHP 4.3.3, and I can replicate this on drupal.org which also runs PHP 4.3.3; OTOH I can't replicate on a site running Drupal 4.2 with PHP 4.2.2, which may mean session_start() changed with PHP 4.3.x; I looked in the changelog of PHP but couldn't find anything. I didn't have any report about this before upgrading to PHP 4.3.3, which also seems to strengthen the hypothesis of a changed behaviour in PHP. Another test I did also showed that with PHP 4.2.2 no cookie is printed by session_start() if a session cookie is found, while it is always printed in PHP 4.3.3; I double checked the configurations and didn't find anything which may cause this. If you want to investigate this, I suggest you to use Mozilla and Live HTTP Headers plugin. ------------------------------------------------------------------------ October 10, 2003 - 19:37 : moshe weitzman Can anyone confirm this? Also, how to fix? ------------------------------------------------------------------------ October 12, 2003 - 12:45 : axel(a)debian.linuxrulez.ru I agree it for Mozilla 1.0. On my site running on FreeBSD 4.7, PHP/4.3.0, Drupal CVS (Oct 3) this function also don't work. Though, with Galeon 1.2.5 cookie works ok. On localhost (Debian GNU/Linux 3.0, PHP 4.1.2, same Drupal cvs version) it works ok with Mozilla & Galeon. ------------------------------------------------------------------------ October 12, 2003 - 13:34 : al The original bug report is surely due to Drupal needing to unset the cookie that it originally stored? To fix this bug, we therefore need a check on the user login/validation stage which forcibly unsets the cookie if you don't do "remember me". I suspect Axel's problems with one of his sites and not the other are due to him blocking a cookie originally and having that site on his Mozilla's list of sites to ban cookies from, or similar. Axel - if you are genuinely having issues with remember me not working at all (and not the fault originally described in this report by Ax) then please open a different bug report. Please make sure it's a genuine problem first - i.e. clear your blocked cookies sites list in Mozilla. ------------------------------------------------------------------------ October 12, 2003 - 18:24 : axel(a)debian.linuxrulez.ru Well. I don't sure what is a bug, therefore first post the question about it to forum [1]. Answer to that question point me to this bug report. Already several users of my site [2] report me about problem with "remember me" (I don't know which browsers they use). And there are not any blocked sites in my Mozilla cookies list - from site I receive only cookie PHPSESSID that expire time shows "at end of session". [1] http://drupal.org/node/view/3601 [2] http://debian.linuxrulez.ru ------------------------------------------------------------------------ October 17, 2003 - 15:36 : dmo Expect "remember me" problems for users of Internet Explorer 6. Depending on the privacy settings, IE6 may automatically expire all cookies at the end of the browser session if your site doesn't have a compact P3P policy. See http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpriv/htm… and http://www.oreillynet.com/pub/a/javascript/2002/10/04/p3p.html for further details. ------------------------------------------------------------------------ October 17, 2003 - 21:53 : moshe weitzman since noone can reproduce this, i am marking as 'by design' ------------------------------------------------------------------------ November 25, 2003 - 02:41 : junyoung This is not a IE6 specific problem. I have seen the same symptom with IE5.5/6.0, Opera 7.0/7.1, and Konqueror 3.1.x so far. FWIW, my blog site is running with Drupal 4.2.0 + PHP 4.3.3. ------------------------------------------------------------------------ November 25, 2003 - 09:06 : remco(a)rc6.org Same problem on http://rc6.org, though the other way around. No matter what I do, my session will time out eventually. Tested using Opera 7.x, IE, Mozilla and Epiphany. ------------------------------------------------------------------------ November 25, 2003 - 10:00 : moshe weitzman reopening this case. i confirm the behavior that marco describes using rc6.org and drupal.org. i find it easiest to just turn cookie prompting on in order to watch what is happenning. what i am seeing, like marco described, is that our 'permanent cookie' which is supposed to last for a year is being overwritten in the next request with a standard session cookie that expires in the time frame specified in .htaccess. for drupal.org, standard sesson cookies last 1 month whereas the permanent cookie lasts for a year. i don't know how to fix this from within drupal. the cookie that we lay down for 'remember me' is working fine. the problem is the later overwrite which is caused by PHP's session handing, not drupal. ------------------------------------------------------------------------ November 26, 2003 - 07:35 : moshe weitzman To make matters more complicated, I cannot reproduce this using PHP as an ISAPI module on IIS ------------------------------------------------------------------------ November 26, 2003 - 14:07 : Dries Maybe we can set a "remember" bit in the session table and periodically wipe users who don't have the "remember"-bit set. The wiping part could be added to sess_gc() ... ------------------------------------------------------------------------ December 3, 2003 - 20:30 : joshk I have this problem w/musicforamerica.org The really maddening thing is that I have another install of drupal 4.3 on the same webserver and it works just fine. If the problem is with drupal's cookie being overwritten by a PHP session cookie, can this be fixed by giving the cookies different names? Sounds too simple to be the solution... ------------------------------------------------------------------------ December 12, 2003 - 11:48 : ykoehler http://ca.php.net/manual/en/function.session-set-cookie-params.php Even though drupal is sending a cookie, it should always set this PHP parameter so that the session_start() call will use the same value, or not send any cookie at all by itself and let session_start() do it with, again, a call to this function to set the correct parameter. The reason why you don't get the same on a site basis is probably due to the different php.ini used for those sites as the default depends on the installation and not drupal which is probably why only some get the bug if there's such a thing. ------------------------------------------------------------------------ December 30, 2003 - 15:50 : paul(a)murphymaphia.com I am having the opposite problem. Even if I check the "remember me" box my session ends when the browser closes and I'm forced to log in the next time I return to the site. No cookie is EVER set by my site. http://www.murphymaphia.com ------------------------------------------------------------------------ January 20, 2004 - 12:31 : mathias Charles Miller has written a persistent login cookie best practices [3] i feel is worth reading. [3] http://fishbowl.pastiche.org/2004/01/19/persistent_login_cookie_best_practi… ------------------------------------------------------------------------ February 11, 2004 - 13:20 : paul(a)murphymaphia.com Has any progress been made on this? I have spent a lot of time in the code and can't manage to track this problem down. If anyone has any ideas, thoughts, etc to share, post them here so we can get this solved. ------------------------------------------------------------------------ February 12, 2004 - 00:07 : dmjossel I have this problem (remember me feature not working) in Drupal 4.3.x on PHP 4.3.2. I do NOT have it on Drupal 4.2 on PHP 4.3.2, in exactly the same environment. So perhaps sessions have changed in PHP 4.3.x, but this still didn't break Drupal 4.2, only 4.3.x. ------------------------------------------------------------------------ February 26, 2004 - 08:47 : moshe weitzman Attachment: http://drupal.org/files/issues/_4drupal (5.3 KB) Here is a patch which attempts to resolve this problem. I took Josh's suggestion - just rename the permanent cookie so it get overwritten by the PHP session cookie. So this patch names our permanent cookie 'remember_me'. The value of this cookie is the current sessionID. This cookie is checked in sess_read(). It is set just as before, in user_login(). I refactored sess_read() a bit for cleaner flow. It uses a new helper function called sess_construct_user(). Feedback welcome. Since not everyone experienced a problem with remember me, I'm particlarly interested in feedback from those who did. ------------------------------------------------------------------------ March 2, 2004 - 05:43 : dmjossel No observable effect. Users who click "remember me" are still logged out after a period of inactivity or a browser restart, as is true in 4.3.2 (but not true in 4.2 on the same machine). Just out of curiosity I made similar changes in a copy of 4.3.2, renaming the cookie-- also with no effect. What *is* odd is that I used to see this problem using Drupal.org itself. But I seem now to have been logged in for quite awhile (several days) without having to reauthenticate, despite long periods of inactivity and browser restarts. Has some change other than this patch been made to CVS running on the live site? ------------------------------------------------------------------------ March 2, 2004 - 06:21 : dmjossel One more follow up: the patch re-enables the "remember me" button on logon and the preferences for the user.module, but not the "logout" button in the user info block. ------------------------------------------------------------------------ March 6, 2004 - 11:33 : moshe weitzman The logout link never left, so naturally this patch does not re-instate it. By "user-info" block, i'm guessing that you mean the 'Navigation' block which holds the menu(). Drupal.org issues session cookies for a month so you can remain logged in for a long time. Anyone else have feedback on this patch. It is working for me. ------------------------------------------------------------------------ March 6, 2004 - 12:01 : Jeremy(a)kerneltrap.org Your patch works perfectly for me. I tested with three browsers (from Linux): Mozilla Firefox, Konquerer, Internet Explorer (via Wine) I did the following with each: 1) with latest CVS installation, I log in then restart my browser. I have to relogin. 2) I applied your patch to my CVS installation. 3) I logged in w/o checking "remember me". I then restart my browser, and I'm not logged in. 4) I logged in w/ "remember me" checked. I restart my browser, and I'm still logged in. 5) I logged in w/ "remember me" checked. I click logout, then restart my browser. I have to login again. ------------------------------------------------------------------------ April 8, 2004 - 20:09 : Brian(a)brianpuccio.net Using weitzmann's patch works for me. I had no problem when running 4.3.0, 4.3.1, or 4.3.2 on my site, but adding 4.4.0 I had to log in each time. Applying the patch to my (next to stock, but ever so slightly modified) install of 4.4.0 fixes the problem and I am remembered across browser tab closings, browser closings and system restarts. Thank you greatly. ------------------------------------------------------------------------ April 11, 2004 - 12:18 : Jeremy(a)kerneltrap.org Attachment: http://drupal.org/files/issues/session.inc.patch (651 bytes) I believe there is a small bug in weitzman's patch. I've been running with it applied on KernelTrap.org for some time, with much positive feedback from users. However, I noticed that occasionally I become a phantom surfer -- I'm logged in and accessing pages, but I don't show up in the "Who's online" block. I suspect the online guests number is low, too. After a little digging, I came up with the attached simple patch. I have yet to confirm if it solves the phantom surfer problem. Essentially, when we log in with a cookie we also update the sessions table timestamp. To use, first apply weitzman's patch (earlier in this thread), then apply this one. ------------------------------------------------------------------------ April 11, 2004 - 16:28 : Jeremy(a)kerneltrap.org Attachment: http://drupal.org/files/issues/session.inc_0.patch (584 bytes) My earlier patch didn't work. It was redundant with sess_write(), and added nothing new. Hence, it didn't fix the "phantom user" that I've been experiencing. Now, however, I believe I fully understand what's going wrong. Essentially what's happening is a user is being loaded via the remember_me cookie, but their session id is different. Thus, the db_query in sess_write() fails to update a user session in the database. This patch detects that failure and acts accordingly by creating a new entry. This patch applies against drupal 4.4 with weitzman's patch [4] applied. [4] http://drupal.org/files/issues/_4drupal ------------------------------------------------------------------------ April 15, 2004 - 02:39 : mabster Still seems to be a bit flakey. I get logged out every once in a while at work for some reason (during the day). And every time I move from my work to my home machines (or vice versa) I need to login again. Does the cookie base itself on my IP address or something? Could it be that because I'm switching between two different PCs that it can't remember my session details? ------------------------------------------------------------------------ April 21, 2004 - 21:19 : dmjossel I've upgraded the site Rampancy.net to Drupal 4.4 and applied Weitzman's patch. The behavior I'm seeing now I don't completely understand. Logging in to the site, you can quit the browser and stay logged in. But after a period of inactivity, somewhere between 30 and 60 minutes, the session expires and you have to log in again. I don't see this behavior on drupal.org. php.ini on the server is set for session cookies to last for 30 days. Drupal, by default, is supposed to give cookies that last 1 year. Is there anything else I should be looking at? Apparently some admins have this problem and others don't. Server info: FreeBSD synfibers.com 4.7-RELEASE-p22 FreeBSD 4.7-RELEASE-p22 #29: Tu i386 Apache/1.3.27 OpenSSL/0.9.7 (Unix) PHP/4.3.4 registered session save handlers are files and user. (local value is user) ------------------------------------------------------------------------ April 21, 2004 - 22:20 : mabster Yes, dmjossel's description matches the behaviour on my site (www.madprops.org) We're a hosted site, so I'm not exactly sure of the server's details. I'm fairly certain it's Windows2003. Definitely a Windows flavour, anyway, which means that this problem (with the patch applied) is not restricted to Linux. ------------------------------------------------------------------------ April 23, 2004 - 05:26 : dmjossel Apologies first for using this like a forum... mabster, upload a file to the server with the phpinfo(); in it (inside PHP tags of course). What values does it show for cookie-related functions? For session_save_handler? Perhaps there is a common element in server configuration in these two cases, despite the different operating systems. ------------------------------------------------------------------------ April 23, 2004 - 05:48 : mabster session.save_handler = files session.cookie_domain = no value session.cookie_lifetime = 0 session.cookie_path = / session.use_cookies = On session.use_only_cookie = Off Other info (at least until someone tells me that publishing this info is dangerous and I remove the file) here [5]. [5] http://www.madprops.org/info.php ------------------------------------------------------------------------ April 23, 2004 - 11:12 : dmjossel Suggestions... try setting session.use_only_cookies =1 either in php.ini, or if you don't have access to that, by using ini_set in drupal's php.conf and see if that has any effect. Next change Drupal's site configuration for the user module, and toggle whether you allow users to choose whether or not to be logged out (this produces the "remember me" cookie if you've installed weitzman's patch) or choose "users are never logged out". Neither of these seem to help here, but perhaps they'd help you. I noticed that until I set my browser to "accept all cookies automatically" and set session.use_only_cookies =1, I was getting the PHPSESSID cookie, but not the remember_me cookie. Now I get them both... but still logged out after 30 minutes of idle time, no matter what. ------------------------------------------------------------------------ April 23, 2004 - 11:26 : moshe weitzman those are not the session values that ship with drupal (see .htaccess file). for example, session_save_handler has to be 'user'. otherwise, you are not using drupal's session table and your 'remember me' will fail. since you are using IIS, you have to set your php.ini with values like those found in .htaccess. .htaccess files are only respected by Apache (and even then, not always. depends on your web host). ------------------------------------------------------------------------ April 23, 2004 - 19:39 : mabster Just out of interest, weitzman: How does drupal.org's 'remember me' work? I installed a cookie inspector on my machine at work, and didn't see any 'remember me' values in drupal.org's cookie. Does it use a different system? I will see what our host can do about changing the php.ini values. Since there are many sites hosted on that one box, it'll be a long shot to get them to change it. ------------------------------------------------------------------------ April 24, 2004 - 12:21 : dmjossel Try tweaking the value of session.gc_maxlifetime either in the .htaccess file or in php.ini. The default value in the .htaccess file seems to be 1440 seconds-- or 24 minutes, almost exactly the amount of time my sessions were lasting before being forced to log in again. I've increased this value, and now I'm seeing the remember_me cookie stay with the same value, while the PHPSESSID cookie is constantly being replaced by a new one-- but I don't have to log in again. ------------------------------------------------------------------------ April 24, 2004 - 20:23 : dmjossel Well, it's the next morning here, and I'm still logged in at Rampancy.net and the other Drupal 4.3 sites that are hosted on the same machine. I think at least this might be a workaround for those who have this problem and Weitzman's patch alone doesn't solve it. ------------------------------------------------------------------------ April 25, 2004 - 20:02 : dmjossel After a longer period of inactivity (equal to the value of session.gc_maxlifetime) the sessions ALWAYS seem to log the user out, regardless of the remember_me cookie value, the PHPSESSID value, or the configuration settings for the user module. ------------------------------------------------------------------------ May 6, 2004 - 06:34 : Robert L I can confirm #41, have tried changing some of the sessions vars in .htaccess, but this did not solve the problem. Sessions are destroyed after some time of browser inactivity (some hours). At the browser side things look oke, it happens with Mozilla and IE. Have not tested the patch yet, I am not using the remember me cookie option, and this looks another unrelated (?) problem to me. I use PHP 4.3.6 with Apache 2. ------------------------------------------------------------------------ June 5, 2004 - 21:41 : Anonymous I fixed it very simply by adding the line: session_set_cookie_params(0, "/dev/null"); immediately before the call to session_start(). This causes the cookie that PHP sets to only apply to the path "/dev/null" which, of course, doesn't exist. Thus, the cookie that Drupal's setcookie() call sets, with a path of "/", is held on to by the browser, and Drupal goes back to its old behaviour. It's a hack, but it works. A better long-term solution would be for Drupal to use the session_set_cookie_params() call to set the expiry time, rather than its own call to setcookie(). Tim Bates ------------------------------------------------------------------------ June 6, 2004 - 12:37 : bertboerland(a)www.drop.org I am sorry to say, that adding a line like that in user.module doesnt do the trick for me (running php 4.2.3/drupal 4.). Can it be that this might work under certain conditions which differ from mine? Anyone else still working on this *critical* bug? I am not changing the status but I think it should still read "active"? ------------------------------------------------------------------------ June 8, 2004 - 03:58 : bertboerland(a)www.drop.org never mind my previous remark... ------------------------------------------------------------------------ August 9, 2004 - 20:53 : moshe weitzman perhaps someone will take interest in this bug. i hope not to release another drupal version without 'remember me'. ------------------------------------------------------------------------ August 13, 2004 - 16:49 : seanr This used to work for me. Now I hear it's been completely disabled. Why? I'd rather have a feature that works for most users and not some than not have the feature at all. ------------------------------------------------------------------------ September 22, 2004 - 11:39 : Anonymous We dropped the whole 'remember me' posiibility in drupal 4.5. If it is - strategically seen - a good move, is another story, but now marked this as "Won't fix". ------------------------------------------------------------------------ September 22, 2004 - 15:35 : moshe weitzman umm - thanks 'anonymous'. this is a valid feature request, even if it isn't a valid bug anymore. marking as such. ------------------------------------------------------------------------ October 13, 2004 - 22:45 : jasper this is a bug actually. If you don't think so, you really aren't thinking about user experience. ------------------------------------------------------------------------ October 19, 2004 - 13:48 : jasper I am having this problem with 4.5. After you login, the cookie that is set to expire in a month is overwritten by a session cookie, so remember me doesn;t work. I "fixed" this by hacking user.module to set its cookie to a non-existant path. Maybe that will mess something up. I notice that drupal.org overcomes this by setting the initial cookie to "host: drupal.org" and the second cookie to "domain: .drupal.org" Where is this documented? How do you do that? ------------------------------------------------------------------------ October 21, 2004 - 11:43 : Anonymous I was having the same problem. I changed user.module's call to setcookie() so that the cookie would expire after 2000000 seconds. That fixed it for me. Now I don't have to login every time I visit. I hope I didn't break anything else, though. setcookie(session_name(), session_id(), FALSE, $path); becomes: setcookie(session_name(), session_id(), time() + 2000000, $path); ------------------------------------------------------------------------ October 21, 2004 - 22:03 : dtan Ya, suddenly noticed that I had to login everytime . . . not a huge deal, but is a bit of a pain. Should this be a configurable option for the site?? Obviously from the length of this issue, people feel it is a useful feature. . . dtan ------------------------------------------------------------------------ October 26, 2004 - 23:32 : tvst I WANT THIS FEATURE BACK! Sure, there were problems with it -- but let's fix the bug instead of killing a nice feature. ------------------------------------------------------------------------ November 3, 2004 - 18:02 : Goba Dries just committed a patch, which removes that superflous cookie setting, so session time in upcoming versions will be determined by the PHP settings, and short lived cookies will not be set. Until new versions are released, it is completely safe to remove the setcookie line in user.module (and the preg line above that), and it solves the problem of users needing to login everytime. ------------------------------------------------------------------------ November 5, 2004 - 01:02 : Anonymous wow. thanks. this was breaking my sites ------------------------------------------------------------------------ December 14, 2004 - 12:06 : kbahey This way, the PHP settings are the ones that determine the session length. Wouldn't it be better to have an admin option that allows users to set their session length? with a global default for sessions (e.g. 1 week, 2 weeks, 1 month, ...etc.) If this option is enabled, then it can be overriden by the user individually too. This is a better scheme than having a forced global setting outside Drupal, on the PHP level for all users. What do others think? ------------------------------------------------------------------------ February 3, 2005 - 13:50 : kbahey Reviving this issue. The session length should be an option that the administrator, or the end user can set. We should not rely on the PHP settings alone. ------------------------------------------------------------------------ February 11, 2005 - 19:54 : kbahey Attachment: http://drupal.org/files/issues/use-module-session.patch (1.92 KB) I feel that removing the setcookie() call was not the right thing to do. Session length should not be relegated to .htaccess or php.ini, but should be an application feature. I am attaching a patch that reinstates this functionality via a configuration option. The sysadmin determines how long visitors should have their session for, and a cookie is set for them with the appropriate lifetime. Please look at this rationally and objectively and do not dismiss it offhand because 'too many options are bad'. I had to go through php.ini and .htaccess hell for the last few months because my hosting company has implemented PHP suExec (hence .htaccess cannot set php parameters), then moved to another machine with .htaccess reinstated. This also allows people (like me) who serve several domains from a single Drupal installation to set the session length differently for different domains. Moreover, the Drupal end user should not have to go through fiddling with .htaccess values to get this functionality back. ------------------------------------------------------------------------ February 12, 2005 - 06:51 : Bèr Kessels -1 for yet another config option. Thisis a (very) advanced feuature, that will never have to be changed on a site. Therefore we need to give it a good default, and if people really want to chage it, those few can do so in conf.php. Bèr ------------------------------------------------------------------------ February 12, 2005 - 08:57 : Goba Please *do not use setcookie()* to overwrite the session cookie! The problem before was that $path and $domain were not the same as set by the session handler cookie, and so the session handler cookie was not overwritten. This behaviour depends on host configuration... See, you introduce a $path variable in your patch, which is not set, and you don't care about the cookie domain... These were the main problems with the previous aproach, and this is why the setcookie() was removed. You should deal directly with the session ini settings! So please ini_set() the session cookie lifetime, if .htaccess is not enough for you, and let the session handler set the proper cookie. -- View: http://drupal.org/node/2974 Edit: http://drupal.org/project/comments/add/2974

1 0

[drupal-devel] [bug] Block delete link missing
by asimmonds 12 Feb '05

12 Feb '05

Project: Drupal Version: cvs Component: block.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: asimmonds Updated by: asimmonds Status: patch Attachment: http://drupal.org/files/issues/block_delete_1.patch (862 bytes) The block delete link seems to be missing, patch adds the link back in. asimmonds -- View: http://drupal.org/node/17216 Edit: http://drupal.org/project/comments/add/17216

2 2

[drupal-devel] [feature] "remember me" doesn't work
by Goba 12 Feb '05

12 Feb '05

Project: Drupal Version: cvs Component: user.module Category: feature requests Priority: normal Assigned to: kbahey Reported by: marco Updated by: Goba Status: patch Please *do not use setcookie()* to overwrite the session cookie! The problem before was that $path and $domain were not the same as set by the session handler cookie, and so the session handler cookie was not overwritten. This behaviour depends on host configuration... See, you introduce a $path variable in your patch, which is not set, and you don't care about the cookie domain... These were the main problems with the previous aproach, and this is why the setcookie() was removed. You should deal directly with the session ini settings! So please ini_set() the session cookie lifetime, if .htaccess is not enough for you, and let the session handler set the proper cookie. Goba Previous comments: ------------------------------------------------------------------------ September 22, 2003 - 14:37 : marco "remember me" checkbox in the login box doesn't work; even if the checkbox is left unchecked the user is NOT forgotten when he quits the browser. Try logging in w/o "remember me", then quit the browser and open it again: you should be still logged in. What happens: when you login w/o checkbox user.module outputs a cookie with lifetime = 0 ("until session ends"); but user.module calls session_start() at the beginning, which outputs a cookie too, with the lifetime specified in .htaccess; and session_start() outputs this cookie always, so on the next page the cookie from user_login() will be overwritten. I run Mozilla 1.4; I can replicate with Drupal 4.0 and Drupal 4.2 on PHP 4.3.3, and I can replicate this on drupal.org which also runs PHP 4.3.3; OTOH I can't replicate on a site running Drupal 4.2 with PHP 4.2.2, which may mean session_start() changed with PHP 4.3.x; I looked in the changelog of PHP but couldn't find anything. I didn't have any report about this before upgrading to PHP 4.3.3, which also seems to strengthen the hypothesis of a changed behaviour in PHP. Another test I did also showed that with PHP 4.2.2 no cookie is printed by session_start() if a session cookie is found, while it is always printed in PHP 4.3.3; I double checked the configurations and didn't find anything which may cause this. If you want to investigate this, I suggest you to use Mozilla and Live HTTP Headers plugin. ------------------------------------------------------------------------ October 11, 2003 - 01:37 : moshe weitzman Can anyone confirm this? Also, how to fix? ------------------------------------------------------------------------ October 12, 2003 - 18:45 : axel(a)debian.linuxrulez.ru I agree it for Mozilla 1.0. On my site running on FreeBSD 4.7, PHP/4.3.0, Drupal CVS (Oct 3) this function also don't work. Though, with Galeon 1.2.5 cookie works ok. On localhost (Debian GNU/Linux 3.0, PHP 4.1.2, same Drupal cvs version) it works ok with Mozilla & Galeon. ------------------------------------------------------------------------ October 12, 2003 - 19:34 : al The original bug report is surely due to Drupal needing to unset the cookie that it originally stored? To fix this bug, we therefore need a check on the user login/validation stage which forcibly unsets the cookie if you don't do "remember me". I suspect Axel's problems with one of his sites and not the other are due to him blocking a cookie originally and having that site on his Mozilla's list of sites to ban cookies from, or similar. Axel - if you are genuinely having issues with remember me not working at all (and not the fault originally described in this report by Ax) then please open a different bug report. Please make sure it's a genuine problem first - i.e. clear your blocked cookies sites list in Mozilla. ------------------------------------------------------------------------ October 13, 2003 - 00:24 : axel(a)debian.linuxrulez.ru Well. I don't sure what is a bug, therefore first post the question about it to forum [1]. Answer to that question point me to this bug report. Already several users of my site [2] report me about problem with "remember me" (I don't know which browsers they use). And there are not any blocked sites in my Mozilla cookies list - from site I receive only cookie PHPSESSID that expire time shows "at end of session". [1] http://drupal.org/node/view/3601 [2] http://debian.linuxrulez.ru ------------------------------------------------------------------------ October 17, 2003 - 21:36 : dmo Expect "remember me" problems for users of Internet Explorer 6. Depending on the privacy settings, IE6 may automatically expire all cookies at the end of the browser session if your site doesn't have a compact P3P policy. See http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpriv/htm… and http://www.oreillynet.com/pub/a/javascript/2002/10/04/p3p.html for further details. ------------------------------------------------------------------------ October 18, 2003 - 03:53 : moshe weitzman since noone can reproduce this, i am marking as 'by design' ------------------------------------------------------------------------ November 25, 2003 - 08:41 : junyoung This is not a IE6 specific problem. I have seen the same symptom with IE5.5/6.0, Opera 7.0/7.1, and Konqueror 3.1.x so far. FWIW, my blog site is running with Drupal 4.2.0 + PHP 4.3.3. ------------------------------------------------------------------------ November 25, 2003 - 15:06 : remco(a)rc6.org Same problem on http://rc6.org, though the other way around. No matter what I do, my session will time out eventually. Tested using Opera 7.x, IE, Mozilla and Epiphany. ------------------------------------------------------------------------ November 25, 2003 - 16:00 : moshe weitzman reopening this case. i confirm the behavior that marco describes using rc6.org and drupal.org. i find it easiest to just turn cookie prompting on in order to watch what is happenning. what i am seeing, like marco described, is that our 'permanent cookie' which is supposed to last for a year is being overwritten in the next request with a standard session cookie that expires in the time frame specified in .htaccess. for drupal.org, standard sesson cookies last 1 month whereas the permanent cookie lasts for a year. i don't know how to fix this from within drupal. the cookie that we lay down for 'remember me' is working fine. the problem is the later overwrite which is caused by PHP's session handing, not drupal. ------------------------------------------------------------------------ November 26, 2003 - 13:35 : moshe weitzman To make matters more complicated, I cannot reproduce this using PHP as an ISAPI module on IIS ------------------------------------------------------------------------ November 26, 2003 - 20:07 : Dries Maybe we can set a "remember" bit in the session table and periodically wipe users who don't have the "remember"-bit set. The wiping part could be added to sess_gc() ... ------------------------------------------------------------------------ December 4, 2003 - 02:30 : joshk I have this problem w/musicforamerica.org The really maddening thing is that I have another install of drupal 4.3 on the same webserver and it works just fine. If the problem is with drupal's cookie being overwritten by a PHP session cookie, can this be fixed by giving the cookies different names? Sounds too simple to be the solution... ------------------------------------------------------------------------ December 12, 2003 - 17:48 : ykoehler http://ca.php.net/manual/en/function.session-set-cookie-params.php Even though drupal is sending a cookie, it should always set this PHP parameter so that the session_start() call will use the same value, or not send any cookie at all by itself and let session_start() do it with, again, a call to this function to set the correct parameter. The reason why you don't get the same on a site basis is probably due to the different php.ini used for those sites as the default depends on the installation and not drupal which is probably why only some get the bug if there's such a thing. ------------------------------------------------------------------------ December 30, 2003 - 21:50 : paul(a)murphymaphia.com I am having the opposite problem. Even if I check the "remember me" box my session ends when the browser closes and I'm forced to log in the next time I return to the site. No cookie is EVER set by my site. http://www.murphymaphia.com ------------------------------------------------------------------------ January 20, 2004 - 18:31 : mathias Charles Miller has written a persistent login cookie best practices [3] i feel is worth reading. [3] http://fishbowl.pastiche.org/2004/01/19/persistent_login_cookie_best_practi… ------------------------------------------------------------------------ February 11, 2004 - 19:20 : paul(a)murphymaphia.com Has any progress been made on this? I have spent a lot of time in the code and can't manage to track this problem down. If anyone has any ideas, thoughts, etc to share, post them here so we can get this solved. ------------------------------------------------------------------------ February 12, 2004 - 06:07 : dmjossel I have this problem (remember me feature not working) in Drupal 4.3.x on PHP 4.3.2. I do NOT have it on Drupal 4.2 on PHP 4.3.2, in exactly the same environment. So perhaps sessions have changed in PHP 4.3.x, but this still didn't break Drupal 4.2, only 4.3.x. ------------------------------------------------------------------------ February 26, 2004 - 14:47 : moshe weitzman Attachment: http://drupal.org/files/issues/_4drupal (5.3 KB) Here is a patch which attempts to resolve this problem. I took Josh's suggestion - just rename the permanent cookie so it get overwritten by the PHP session cookie. So this patch names our permanent cookie 'remember_me'. The value of this cookie is the current sessionID. This cookie is checked in sess_read(). It is set just as before, in user_login(). I refactored sess_read() a bit for cleaner flow. It uses a new helper function called sess_construct_user(). Feedback welcome. Since not everyone experienced a problem with remember me, I'm particlarly interested in feedback from those who did. ------------------------------------------------------------------------ March 2, 2004 - 11:43 : dmjossel No observable effect. Users who click "remember me" are still logged out after a period of inactivity or a browser restart, as is true in 4.3.2 (but not true in 4.2 on the same machine). Just out of curiosity I made similar changes in a copy of 4.3.2, renaming the cookie-- also with no effect. What *is* odd is that I used to see this problem using Drupal.org itself. But I seem now to have been logged in for quite awhile (several days) without having to reauthenticate, despite long periods of inactivity and browser restarts. Has some change other than this patch been made to CVS running on the live site? ------------------------------------------------------------------------ March 2, 2004 - 12:21 : dmjossel One more follow up: the patch re-enables the "remember me" button on logon and the preferences for the user.module, but not the "logout" button in the user info block. ------------------------------------------------------------------------ March 6, 2004 - 17:33 : moshe weitzman The logout link never left, so naturally this patch does not re-instate it. By "user-info" block, i'm guessing that you mean the 'Navigation' block which holds the menu(). Drupal.org issues session cookies for a month so you can remain logged in for a long time. Anyone else have feedback on this patch. It is working for me. ------------------------------------------------------------------------ March 6, 2004 - 18:01 : Jeremy(a)kerneltrap.org Your patch works perfectly for me. I tested with three browsers (from Linux): Mozilla Firefox, Konquerer, Internet Explorer (via Wine) I did the following with each: 1) with latest CVS installation, I log in then restart my browser. I have to relogin. 2) I applied your patch to my CVS installation. 3) I logged in w/o checking "remember me". I then restart my browser, and I'm not logged in. 4) I logged in w/ "remember me" checked. I restart my browser, and I'm still logged in. 5) I logged in w/ "remember me" checked. I click logout, then restart my browser. I have to login again. ------------------------------------------------------------------------ April 9, 2004 - 02:09 : Brian(a)brianpuccio.net Using weitzmann's patch works for me. I had no problem when running 4.3.0, 4.3.1, or 4.3.2 on my site, but adding 4.4.0 I had to log in each time. Applying the patch to my (next to stock, but ever so slightly modified) install of 4.4.0 fixes the problem and I am remembered across browser tab closings, browser closings and system restarts. Thank you greatly. ------------------------------------------------------------------------ April 11, 2004 - 18:18 : Jeremy(a)kerneltrap.org Attachment: http://drupal.org/files/issues/session.inc.patch (651 bytes) I believe there is a small bug in weitzman's patch. I've been running with it applied on KernelTrap.org for some time, with much positive feedback from users. However, I noticed that occasionally I become a phantom surfer -- I'm logged in and accessing pages, but I don't show up in the "Who's online" block. I suspect the online guests number is low, too. After a little digging, I came up with the attached simple patch. I have yet to confirm if it solves the phantom surfer problem. Essentially, when we log in with a cookie we also update the sessions table timestamp. To use, first apply weitzman's patch (earlier in this thread), then apply this one. ------------------------------------------------------------------------ April 11, 2004 - 22:28 : Jeremy(a)kerneltrap.org Attachment: http://drupal.org/files/issues/session.inc_0.patch (584 bytes) My earlier patch didn't work. It was redundant with sess_write(), and added nothing new. Hence, it didn't fix the "phantom user" that I've been experiencing. Now, however, I believe I fully understand what's going wrong. Essentially what's happening is a user is being loaded via the remember_me cookie, but their session id is different. Thus, the db_query in sess_write() fails to update a user session in the database. This patch detects that failure and acts accordingly by creating a new entry. This patch applies against drupal 4.4 with weitzman's patch [4] applied. [4] http://drupal.org/files/issues/_4drupal ------------------------------------------------------------------------ April 15, 2004 - 08:39 : mabster Still seems to be a bit flakey. I get logged out every once in a while at work for some reason (during the day). And every time I move from my work to my home machines (or vice versa) I need to login again. Does the cookie base itself on my IP address or something? Could it be that because I'm switching between two different PCs that it can't remember my session details? ------------------------------------------------------------------------ April 22, 2004 - 03:19 : dmjossel I've upgraded the site Rampancy.net to Drupal 4.4 and applied Weitzman's patch. The behavior I'm seeing now I don't completely understand. Logging in to the site, you can quit the browser and stay logged in. But after a period of inactivity, somewhere between 30 and 60 minutes, the session expires and you have to log in again. I don't see this behavior on drupal.org. php.ini on the server is set for session cookies to last for 30 days. Drupal, by default, is supposed to give cookies that last 1 year. Is there anything else I should be looking at? Apparently some admins have this problem and others don't. Server info: FreeBSD synfibers.com 4.7-RELEASE-p22 FreeBSD 4.7-RELEASE-p22 #29: Tu i386 Apache/1.3.27 OpenSSL/0.9.7 (Unix) PHP/4.3.4 registered session save handlers are files and user. (local value is user) ------------------------------------------------------------------------ April 22, 2004 - 04:20 : mabster Yes, dmjossel's description matches the behaviour on my site (www.madprops.org) We're a hosted site, so I'm not exactly sure of the server's details. I'm fairly certain it's Windows2003. Definitely a Windows flavour, anyway, which means that this problem (with the patch applied) is not restricted to Linux. ------------------------------------------------------------------------ April 23, 2004 - 11:26 : dmjossel Apologies first for using this like a forum... mabster, upload a file to the server with the phpinfo(); in it (inside PHP tags of course). What values does it show for cookie-related functions? For session_save_handler? Perhaps there is a common element in server configuration in these two cases, despite the different operating systems. ------------------------------------------------------------------------ April 23, 2004 - 11:48 : mabster session.save_handler = files session.cookie_domain = no value session.cookie_lifetime = 0 session.cookie_path = / session.use_cookies = On session.use_only_cookie = Off Other info (at least until someone tells me that publishing this info is dangerous and I remove the file) here [5]. [5] http://www.madprops.org/info.php ------------------------------------------------------------------------ April 23, 2004 - 17:12 : dmjossel Suggestions... try setting session.use_only_cookies =1 either in php.ini, or if you don't have access to that, by using ini_set in drupal's php.conf and see if that has any effect. Next change Drupal's site configuration for the user module, and toggle whether you allow users to choose whether or not to be logged out (this produces the "remember me" cookie if you've installed weitzman's patch) or choose "users are never logged out". Neither of these seem to help here, but perhaps they'd help you. I noticed that until I set my browser to "accept all cookies automatically" and set session.use_only_cookies =1, I was getting the PHPSESSID cookie, but not the remember_me cookie. Now I get them both... but still logged out after 30 minutes of idle time, no matter what. ------------------------------------------------------------------------ April 23, 2004 - 17:26 : moshe weitzman those are not the session values that ship with drupal (see .htaccess file). for example, session_save_handler has to be 'user'. otherwise, you are not using drupal's session table and your 'remember me' will fail. since you are using IIS, you have to set your php.ini with values like those found in .htaccess. .htaccess files are only respected by Apache (and even then, not always. depends on your web host). ------------------------------------------------------------------------ April 24, 2004 - 01:39 : mabster Just out of interest, weitzman: How does drupal.org's 'remember me' work? I installed a cookie inspector on my machine at work, and didn't see any 'remember me' values in drupal.org's cookie. Does it use a different system? I will see what our host can do about changing the php.ini values. Since there are many sites hosted on that one box, it'll be a long shot to get them to change it. ------------------------------------------------------------------------ April 24, 2004 - 18:21 : dmjossel Try tweaking the value of session.gc_maxlifetime either in the .htaccess file or in php.ini. The default value in the .htaccess file seems to be 1440 seconds-- or 24 minutes, almost exactly the amount of time my sessions were lasting before being forced to log in again. I've increased this value, and now I'm seeing the remember_me cookie stay with the same value, while the PHPSESSID cookie is constantly being replaced by a new one-- but I don't have to log in again. ------------------------------------------------------------------------ April 25, 2004 - 02:23 : dmjossel Well, it's the next morning here, and I'm still logged in at Rampancy.net and the other Drupal 4.3 sites that are hosted on the same machine. I think at least this might be a workaround for those who have this problem and Weitzman's patch alone doesn't solve it. ------------------------------------------------------------------------ April 26, 2004 - 02:02 : dmjossel After a longer period of inactivity (equal to the value of session.gc_maxlifetime) the sessions ALWAYS seem to log the user out, regardless of the remember_me cookie value, the PHPSESSID value, or the configuration settings for the user module. ------------------------------------------------------------------------ May 6, 2004 - 12:34 : Robert L I can confirm #41, have tried changing some of the sessions vars in .htaccess, but this did not solve the problem. Sessions are destroyed after some time of browser inactivity (some hours). At the browser side things look oke, it happens with Mozilla and IE. Have not tested the patch yet, I am not using the remember me cookie option, and this looks another unrelated (?) problem to me. I use PHP 4.3.6 with Apache 2. ------------------------------------------------------------------------ June 6, 2004 - 03:41 : Anonymous I fixed it very simply by adding the line: session_set_cookie_params(0, "/dev/null"); immediately before the call to session_start(). This causes the cookie that PHP sets to only apply to the path "/dev/null" which, of course, doesn't exist. Thus, the cookie that Drupal's setcookie() call sets, with a path of "/", is held on to by the browser, and Drupal goes back to its old behaviour. It's a hack, but it works. A better long-term solution would be for Drupal to use the session_set_cookie_params() call to set the expiry time, rather than its own call to setcookie(). Tim Bates ------------------------------------------------------------------------ June 6, 2004 - 18:37 : bertboerland(a)www.drop.org I am sorry to say, that adding a line like that in user.module doesnt do the trick for me (running php 4.2.3/drupal 4.). Can it be that this might work under certain conditions which differ from mine? Anyone else still working on this *critical* bug? I am not changing the status but I think it should still read "active"? ------------------------------------------------------------------------ June 8, 2004 - 09:58 : bertboerland(a)www.drop.org never mind my previous remark... ------------------------------------------------------------------------ August 10, 2004 - 02:53 : moshe weitzman perhaps someone will take interest in this bug. i hope not to release another drupal version without 'remember me'. ------------------------------------------------------------------------ August 13, 2004 - 22:49 : seanr This used to work for me. Now I hear it's been completely disabled. Why? I'd rather have a feature that works for most users and not some than not have the feature at all. ------------------------------------------------------------------------ September 22, 2004 - 17:39 : Anonymous We dropped the whole 'remember me' posiibility in drupal 4.5. If it is - strategically seen - a good move, is another story, but now marked this as "Won't fix". ------------------------------------------------------------------------ September 22, 2004 - 21:35 : moshe weitzman umm - thanks 'anonymous'. this is a valid feature request, even if it isn't a valid bug anymore. marking as such. ------------------------------------------------------------------------ October 14, 2004 - 04:45 : jasper this is a bug actually. If you don't think so, you really aren't thinking about user experience. ------------------------------------------------------------------------ October 19, 2004 - 19:48 : jasper I am having this problem with 4.5. After you login, the cookie that is set to expire in a month is overwritten by a session cookie, so remember me doesn;t work. I "fixed" this by hacking user.module to set its cookie to a non-existant path. Maybe that will mess something up. I notice that drupal.org overcomes this by setting the initial cookie to "host: drupal.org" and the second cookie to "domain: .drupal.org" Where is this documented? How do you do that? ------------------------------------------------------------------------ October 21, 2004 - 17:43 : Anonymous I was having the same problem. I changed user.module's call to setcookie() so that the cookie would expire after 2000000 seconds. That fixed it for me. Now I don't have to login every time I visit. I hope I didn't break anything else, though. setcookie(session_name(), session_id(), FALSE, $path); becomes: setcookie(session_name(), session_id(), time() + 2000000, $path); ------------------------------------------------------------------------ October 22, 2004 - 04:03 : dtan Ya, suddenly noticed that I had to login everytime . . . not a huge deal, but is a bit of a pain. Should this be a configurable option for the site?? Obviously from the length of this issue, people feel it is a useful feature. . . dtan ------------------------------------------------------------------------ October 27, 2004 - 05:32 : tvst I WANT THIS FEATURE BACK! Sure, there were problems with it -- but let's fix the bug instead of killing a nice feature. ------------------------------------------------------------------------ November 4, 2004 - 00:02 : Goba Dries just committed a patch, which removes that superflous cookie setting, so session time in upcoming versions will be determined by the PHP settings, and short lived cookies will not be set. Until new versions are released, it is completely safe to remove the setcookie line in user.module (and the preg line above that), and it solves the problem of users needing to login everytime. ------------------------------------------------------------------------ November 5, 2004 - 07:02 : Anonymous wow. thanks. this was breaking my sites ------------------------------------------------------------------------ December 14, 2004 - 18:06 : kbahey This way, the PHP settings are the ones that determine the session length. Wouldn't it be better to have an admin option that allows users to set their session length? with a global default for sessions (e.g. 1 week, 2 weeks, 1 month, ...etc.) If this option is enabled, then it can be overriden by the user individually too. This is a better scheme than having a forced global setting outside Drupal, on the PHP level for all users. What do others think? ------------------------------------------------------------------------ February 3, 2005 - 19:50 : kbahey Reviving this issue. The session length should be an option that the administrator, or the end user can set. We should not rely on the PHP settings alone. ------------------------------------------------------------------------ February 12, 2005 - 01:54 : kbahey Attachment: http://drupal.org/files/issues/use-module-session.patch (1.92 KB) I feel that removing the setcookie() call was not the right thing to do. Session length should not be relegated to .htaccess or php.ini, but should be an application feature. I am attaching a patch that reinstates this functionality via a configuration option. The sysadmin determines how long visitors should have their session for, and a cookie is set for them with the appropriate lifetime. Please look at this rationally and objectively and do not dismiss it offhand because 'too many options are bad'. I had to go through php.ini and .htaccess hell for the last few months because my hosting company has implemented PHP suExec (hence .htaccess cannot set php parameters), then moved to another machine with .htaccess reinstated. This also allows people (like me) who serve several domains from a single Drupal installation to set the session length differently for different domains. Moreover, the Drupal end user should not have to go through fiddling with .htaccess values to get this functionality back. ------------------------------------------------------------------------ February 12, 2005 - 12:51 : Bèr Kessels -1 for yet another config option. Thisis a (very) advanced feuature, that will never have to be changed on a site. Therefore we need to give it a good default, and if people really want to chage it, those few can do so in conf.php. Bèr -- View: http://drupal.org/node/2974 Edit: http://drupal.org/project/comments/add/2974

1 0

[drupal-devel] [feature] "remember me" doesn't work
by Bèr Kessels 12 Feb '05

12 Feb '05

Project: Drupal Version: cvs Component: user.module Category: feature requests Priority: normal Assigned to: kbahey Reported by: marco Updated by: Bèr Kessels Status: patch -1 for yet another config option. Thisis a (very) advanced feuature, that will never have to be changed on a site. Therefore we need to give it a good default, and if people really want to chage it, those few can do so in conf.php. Bèr Bèr Kessels Previous comments: ------------------------------------------------------------------------ September 22, 2003 - 14:37 : marco "remember me" checkbox in the login box doesn't work; even if the checkbox is left unchecked the user is NOT forgotten when he quits the browser. Try logging in w/o "remember me", then quit the browser and open it again: you should be still logged in. What happens: when you login w/o checkbox user.module outputs a cookie with lifetime = 0 ("until session ends"); but user.module calls session_start() at the beginning, which outputs a cookie too, with the lifetime specified in .htaccess; and session_start() outputs this cookie always, so on the next page the cookie from user_login() will be overwritten. I run Mozilla 1.4; I can replicate with Drupal 4.0 and Drupal 4.2 on PHP 4.3.3, and I can replicate this on drupal.org which also runs PHP 4.3.3; OTOH I can't replicate on a site running Drupal 4.2 with PHP 4.2.2, which may mean session_start() changed with PHP 4.3.x; I looked in the changelog of PHP but couldn't find anything. I didn't have any report about this before upgrading to PHP 4.3.3, which also seems to strengthen the hypothesis of a changed behaviour in PHP. Another test I did also showed that with PHP 4.2.2 no cookie is printed by session_start() if a session cookie is found, while it is always printed in PHP 4.3.3; I double checked the configurations and didn't find anything which may cause this. If you want to investigate this, I suggest you to use Mozilla and Live HTTP Headers plugin. ------------------------------------------------------------------------ October 11, 2003 - 01:37 : moshe weitzman Can anyone confirm this? Also, how to fix? ------------------------------------------------------------------------ October 12, 2003 - 18:45 : axel(a)debian.linuxrulez.ru I agree it for Mozilla 1.0. On my site running on FreeBSD 4.7, PHP/4.3.0, Drupal CVS (Oct 3) this function also don't work. Though, with Galeon 1.2.5 cookie works ok. On localhost (Debian GNU/Linux 3.0, PHP 4.1.2, same Drupal cvs version) it works ok with Mozilla & Galeon. ------------------------------------------------------------------------ October 12, 2003 - 19:34 : al The original bug report is surely due to Drupal needing to unset the cookie that it originally stored? To fix this bug, we therefore need a check on the user login/validation stage which forcibly unsets the cookie if you don't do "remember me". I suspect Axel's problems with one of his sites and not the other are due to him blocking a cookie originally and having that site on his Mozilla's list of sites to ban cookies from, or similar. Axel - if you are genuinely having issues with remember me not working at all (and not the fault originally described in this report by Ax) then please open a different bug report. Please make sure it's a genuine problem first - i.e. clear your blocked cookies sites list in Mozilla. ------------------------------------------------------------------------ October 13, 2003 - 00:24 : axel(a)debian.linuxrulez.ru Well. I don't sure what is a bug, therefore first post the question about it to forum [1]. Answer to that question point me to this bug report. Already several users of my site [2] report me about problem with "remember me" (I don't know which browsers they use). And there are not any blocked sites in my Mozilla cookies list - from site I receive only cookie PHPSESSID that expire time shows "at end of session". [1] http://drupal.org/node/view/3601 [2] http://debian.linuxrulez.ru ------------------------------------------------------------------------ October 17, 2003 - 21:36 : dmo Expect "remember me" problems for users of Internet Explorer 6. Depending on the privacy settings, IE6 may automatically expire all cookies at the end of the browser session if your site doesn't have a compact P3P policy. See http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpriv/htm… and http://www.oreillynet.com/pub/a/javascript/2002/10/04/p3p.html for further details. ------------------------------------------------------------------------ October 18, 2003 - 03:53 : moshe weitzman since noone can reproduce this, i am marking as 'by design' ------------------------------------------------------------------------ November 25, 2003 - 08:41 : junyoung This is not a IE6 specific problem. I have seen the same symptom with IE5.5/6.0, Opera 7.0/7.1, and Konqueror 3.1.x so far. FWIW, my blog site is running with Drupal 4.2.0 + PHP 4.3.3. ------------------------------------------------------------------------ November 25, 2003 - 15:06 : remco(a)rc6.org Same problem on http://rc6.org, though the other way around. No matter what I do, my session will time out eventually. Tested using Opera 7.x, IE, Mozilla and Epiphany. ------------------------------------------------------------------------ November 25, 2003 - 16:00 : moshe weitzman reopening this case. i confirm the behavior that marco describes using rc6.org and drupal.org. i find it easiest to just turn cookie prompting on in order to watch what is happenning. what i am seeing, like marco described, is that our 'permanent cookie' which is supposed to last for a year is being overwritten in the next request with a standard session cookie that expires in the time frame specified in .htaccess. for drupal.org, standard sesson cookies last 1 month whereas the permanent cookie lasts for a year. i don't know how to fix this from within drupal. the cookie that we lay down for 'remember me' is working fine. the problem is the later overwrite which is caused by PHP's session handing, not drupal. ------------------------------------------------------------------------ November 26, 2003 - 13:35 : moshe weitzman To make matters more complicated, I cannot reproduce this using PHP as an ISAPI module on IIS ------------------------------------------------------------------------ November 26, 2003 - 20:07 : Dries Maybe we can set a "remember" bit in the session table and periodically wipe users who don't have the "remember"-bit set. The wiping part could be added to sess_gc() ... ------------------------------------------------------------------------ December 4, 2003 - 02:30 : joshk I have this problem w/musicforamerica.org The really maddening thing is that I have another install of drupal 4.3 on the same webserver and it works just fine. If the problem is with drupal's cookie being overwritten by a PHP session cookie, can this be fixed by giving the cookies different names? Sounds too simple to be the solution... ------------------------------------------------------------------------ December 12, 2003 - 17:48 : ykoehler http://ca.php.net/manual/en/function.session-set-cookie-params.php Even though drupal is sending a cookie, it should always set this PHP parameter so that the session_start() call will use the same value, or not send any cookie at all by itself and let session_start() do it with, again, a call to this function to set the correct parameter. The reason why you don't get the same on a site basis is probably due to the different php.ini used for those sites as the default depends on the installation and not drupal which is probably why only some get the bug if there's such a thing. ------------------------------------------------------------------------ December 30, 2003 - 21:50 : paul(a)murphymaphia.com I am having the opposite problem. Even if I check the "remember me" box my session ends when the browser closes and I'm forced to log in the next time I return to the site. No cookie is EVER set by my site. http://www.murphymaphia.com ------------------------------------------------------------------------ January 20, 2004 - 18:31 : mathias Charles Miller has written a persistent login cookie best practices [3] i feel is worth reading. [3] http://fishbowl.pastiche.org/2004/01/19/persistent_login_cookie_best_practi… ------------------------------------------------------------------------ February 11, 2004 - 19:20 : paul(a)murphymaphia.com Has any progress been made on this? I have spent a lot of time in the code and can't manage to track this problem down. If anyone has any ideas, thoughts, etc to share, post them here so we can get this solved. ------------------------------------------------------------------------ February 12, 2004 - 06:07 : dmjossel I have this problem (remember me feature not working) in Drupal 4.3.x on PHP 4.3.2. I do NOT have it on Drupal 4.2 on PHP 4.3.2, in exactly the same environment. So perhaps sessions have changed in PHP 4.3.x, but this still didn't break Drupal 4.2, only 4.3.x. ------------------------------------------------------------------------ February 26, 2004 - 14:47 : moshe weitzman Attachment: http://drupal.org/files/issues/_4drupal (5.3 KB) Here is a patch which attempts to resolve this problem. I took Josh's suggestion - just rename the permanent cookie so it get overwritten by the PHP session cookie. So this patch names our permanent cookie 'remember_me'. The value of this cookie is the current sessionID. This cookie is checked in sess_read(). It is set just as before, in user_login(). I refactored sess_read() a bit for cleaner flow. It uses a new helper function called sess_construct_user(). Feedback welcome. Since not everyone experienced a problem with remember me, I'm particlarly interested in feedback from those who did. ------------------------------------------------------------------------ March 2, 2004 - 11:43 : dmjossel No observable effect. Users who click "remember me" are still logged out after a period of inactivity or a browser restart, as is true in 4.3.2 (but not true in 4.2 on the same machine). Just out of curiosity I made similar changes in a copy of 4.3.2, renaming the cookie-- also with no effect. What *is* odd is that I used to see this problem using Drupal.org itself. But I seem now to have been logged in for quite awhile (several days) without having to reauthenticate, despite long periods of inactivity and browser restarts. Has some change other than this patch been made to CVS running on the live site? ------------------------------------------------------------------------ March 2, 2004 - 12:21 : dmjossel One more follow up: the patch re-enables the "remember me" button on logon and the preferences for the user.module, but not the "logout" button in the user info block. ------------------------------------------------------------------------ March 6, 2004 - 17:33 : moshe weitzman The logout link never left, so naturally this patch does not re-instate it. By "user-info" block, i'm guessing that you mean the 'Navigation' block which holds the menu(). Drupal.org issues session cookies for a month so you can remain logged in for a long time. Anyone else have feedback on this patch. It is working for me. ------------------------------------------------------------------------ March 6, 2004 - 18:01 : Jeremy(a)kerneltrap.org Your patch works perfectly for me. I tested with three browsers (from Linux): Mozilla Firefox, Konquerer, Internet Explorer (via Wine) I did the following with each: 1) with latest CVS installation, I log in then restart my browser. I have to relogin. 2) I applied your patch to my CVS installation. 3) I logged in w/o checking "remember me". I then restart my browser, and I'm not logged in. 4) I logged in w/ "remember me" checked. I restart my browser, and I'm still logged in. 5) I logged in w/ "remember me" checked. I click logout, then restart my browser. I have to login again. ------------------------------------------------------------------------ April 9, 2004 - 02:09 : Brian(a)brianpuccio.net Using weitzmann's patch works for me. I had no problem when running 4.3.0, 4.3.1, or 4.3.2 on my site, but adding 4.4.0 I had to log in each time. Applying the patch to my (next to stock, but ever so slightly modified) install of 4.4.0 fixes the problem and I am remembered across browser tab closings, browser closings and system restarts. Thank you greatly. ------------------------------------------------------------------------ April 11, 2004 - 18:18 : Jeremy(a)kerneltrap.org Attachment: http://drupal.org/files/issues/session.inc.patch (651 bytes) I believe there is a small bug in weitzman's patch. I've been running with it applied on KernelTrap.org for some time, with much positive feedback from users. However, I noticed that occasionally I become a phantom surfer -- I'm logged in and accessing pages, but I don't show up in the "Who's online" block. I suspect the online guests number is low, too. After a little digging, I came up with the attached simple patch. I have yet to confirm if it solves the phantom surfer problem. Essentially, when we log in with a cookie we also update the sessions table timestamp. To use, first apply weitzman's patch (earlier in this thread), then apply this one. ------------------------------------------------------------------------ April 11, 2004 - 22:28 : Jeremy(a)kerneltrap.org Attachment: http://drupal.org/files/issues/session.inc_0.patch (584 bytes) My earlier patch didn't work. It was redundant with sess_write(), and added nothing new. Hence, it didn't fix the "phantom user" that I've been experiencing. Now, however, I believe I fully understand what's going wrong. Essentially what's happening is a user is being loaded via the remember_me cookie, but their session id is different. Thus, the db_query in sess_write() fails to update a user session in the database. This patch detects that failure and acts accordingly by creating a new entry. This patch applies against drupal 4.4 with weitzman's patch [4] applied. [4] http://drupal.org/files/issues/_4drupal ------------------------------------------------------------------------ April 15, 2004 - 08:39 : mabster Still seems to be a bit flakey. I get logged out every once in a while at work for some reason (during the day). And every time I move from my work to my home machines (or vice versa) I need to login again. Does the cookie base itself on my IP address or something? Could it be that because I'm switching between two different PCs that it can't remember my session details? ------------------------------------------------------------------------ April 22, 2004 - 03:19 : dmjossel I've upgraded the site Rampancy.net to Drupal 4.4 and applied Weitzman's patch. The behavior I'm seeing now I don't completely understand. Logging in to the site, you can quit the browser and stay logged in. But after a period of inactivity, somewhere between 30 and 60 minutes, the session expires and you have to log in again. I don't see this behavior on drupal.org. php.ini on the server is set for session cookies to last for 30 days. Drupal, by default, is supposed to give cookies that last 1 year. Is there anything else I should be looking at? Apparently some admins have this problem and others don't. Server info: FreeBSD synfibers.com 4.7-RELEASE-p22 FreeBSD 4.7-RELEASE-p22 #29: Tu i386 Apache/1.3.27 OpenSSL/0.9.7 (Unix) PHP/4.3.4 registered session save handlers are files and user. (local value is user) ------------------------------------------------------------------------ April 22, 2004 - 04:20 : mabster Yes, dmjossel's description matches the behaviour on my site (www.madprops.org) We're a hosted site, so I'm not exactly sure of the server's details. I'm fairly certain it's Windows2003. Definitely a Windows flavour, anyway, which means that this problem (with the patch applied) is not restricted to Linux. ------------------------------------------------------------------------ April 23, 2004 - 11:26 : dmjossel Apologies first for using this like a forum... mabster, upload a file to the server with the phpinfo(); in it (inside PHP tags of course). What values does it show for cookie-related functions? For session_save_handler? Perhaps there is a common element in server configuration in these two cases, despite the different operating systems. ------------------------------------------------------------------------ April 23, 2004 - 11:48 : mabster session.save_handler = files session.cookie_domain = no value session.cookie_lifetime = 0 session.cookie_path = / session.use_cookies = On session.use_only_cookie = Off Other info (at least until someone tells me that publishing this info is dangerous and I remove the file) here [5]. [5] http://www.madprops.org/info.php ------------------------------------------------------------------------ April 23, 2004 - 17:12 : dmjossel Suggestions... try setting session.use_only_cookies =1 either in php.ini, or if you don't have access to that, by using ini_set in drupal's php.conf and see if that has any effect. Next change Drupal's site configuration for the user module, and toggle whether you allow users to choose whether or not to be logged out (this produces the "remember me" cookie if you've installed weitzman's patch) or choose "users are never logged out". Neither of these seem to help here, but perhaps they'd help you. I noticed that until I set my browser to "accept all cookies automatically" and set session.use_only_cookies =1, I was getting the PHPSESSID cookie, but not the remember_me cookie. Now I get them both... but still logged out after 30 minutes of idle time, no matter what. ------------------------------------------------------------------------ April 23, 2004 - 17:26 : moshe weitzman those are not the session values that ship with drupal (see .htaccess file). for example, session_save_handler has to be 'user'. otherwise, you are not using drupal's session table and your 'remember me' will fail. since you are using IIS, you have to set your php.ini with values like those found in .htaccess. .htaccess files are only respected by Apache (and even then, not always. depends on your web host). ------------------------------------------------------------------------ April 24, 2004 - 01:39 : mabster Just out of interest, weitzman: How does drupal.org's 'remember me' work? I installed a cookie inspector on my machine at work, and didn't see any 'remember me' values in drupal.org's cookie. Does it use a different system? I will see what our host can do about changing the php.ini values. Since there are many sites hosted on that one box, it'll be a long shot to get them to change it. ------------------------------------------------------------------------ April 24, 2004 - 18:21 : dmjossel Try tweaking the value of session.gc_maxlifetime either in the .htaccess file or in php.ini. The default value in the .htaccess file seems to be 1440 seconds-- or 24 minutes, almost exactly the amount of time my sessions were lasting before being forced to log in again. I've increased this value, and now I'm seeing the remember_me cookie stay with the same value, while the PHPSESSID cookie is constantly being replaced by a new one-- but I don't have to log in again. ------------------------------------------------------------------------ April 25, 2004 - 02:23 : dmjossel Well, it's the next morning here, and I'm still logged in at Rampancy.net and the other Drupal 4.3 sites that are hosted on the same machine. I think at least this might be a workaround for those who have this problem and Weitzman's patch alone doesn't solve it. ------------------------------------------------------------------------ April 26, 2004 - 02:02 : dmjossel After a longer period of inactivity (equal to the value of session.gc_maxlifetime) the sessions ALWAYS seem to log the user out, regardless of the remember_me cookie value, the PHPSESSID value, or the configuration settings for the user module. ------------------------------------------------------------------------ May 6, 2004 - 12:34 : Robert L I can confirm #41, have tried changing some of the sessions vars in .htaccess, but this did not solve the problem. Sessions are destroyed after some time of browser inactivity (some hours). At the browser side things look oke, it happens with Mozilla and IE. Have not tested the patch yet, I am not using the remember me cookie option, and this looks another unrelated (?) problem to me. I use PHP 4.3.6 with Apache 2. ------------------------------------------------------------------------ June 6, 2004 - 03:41 : Anonymous I fixed it very simply by adding the line: session_set_cookie_params(0, "/dev/null"); immediately before the call to session_start(). This causes the cookie that PHP sets to only apply to the path "/dev/null" which, of course, doesn't exist. Thus, the cookie that Drupal's setcookie() call sets, with a path of "/", is held on to by the browser, and Drupal goes back to its old behaviour. It's a hack, but it works. A better long-term solution would be for Drupal to use the session_set_cookie_params() call to set the expiry time, rather than its own call to setcookie(). Tim Bates ------------------------------------------------------------------------ June 6, 2004 - 18:37 : bertboerland(a)www.drop.org I am sorry to say, that adding a line like that in user.module doesnt do the trick for me (running php 4.2.3/drupal 4.). Can it be that this might work under certain conditions which differ from mine? Anyone else still working on this *critical* bug? I am not changing the status but I think it should still read "active"? ------------------------------------------------------------------------ June 8, 2004 - 09:58 : bertboerland(a)www.drop.org never mind my previous remark... ------------------------------------------------------------------------ August 10, 2004 - 02:53 : moshe weitzman perhaps someone will take interest in this bug. i hope not to release another drupal version without 'remember me'. ------------------------------------------------------------------------ August 13, 2004 - 22:49 : seanr This used to work for me. Now I hear it's been completely disabled. Why? I'd rather have a feature that works for most users and not some than not have the feature at all. ------------------------------------------------------------------------ September 22, 2004 - 17:39 : Anonymous We dropped the whole 'remember me' posiibility in drupal 4.5. If it is - strategically seen - a good move, is another story, but now marked this as "Won't fix". ------------------------------------------------------------------------ September 22, 2004 - 21:35 : moshe weitzman umm - thanks 'anonymous'. this is a valid feature request, even if it isn't a valid bug anymore. marking as such. ------------------------------------------------------------------------ October 14, 2004 - 04:45 : jasper this is a bug actually. If you don't think so, you really aren't thinking about user experience. ------------------------------------------------------------------------ October 19, 2004 - 19:48 : jasper I am having this problem with 4.5. After you login, the cookie that is set to expire in a month is overwritten by a session cookie, so remember me doesn;t work. I "fixed" this by hacking user.module to set its cookie to a non-existant path. Maybe that will mess something up. I notice that drupal.org overcomes this by setting the initial cookie to "host: drupal.org" and the second cookie to "domain: .drupal.org" Where is this documented? How do you do that? ------------------------------------------------------------------------ October 21, 2004 - 17:43 : Anonymous I was having the same problem. I changed user.module's call to setcookie() so that the cookie would expire after 2000000 seconds. That fixed it for me. Now I don't have to login every time I visit. I hope I didn't break anything else, though. setcookie(session_name(), session_id(), FALSE, $path); becomes: setcookie(session_name(), session_id(), time() + 2000000, $path); ------------------------------------------------------------------------ October 22, 2004 - 04:03 : dtan Ya, suddenly noticed that I had to login everytime . . . not a huge deal, but is a bit of a pain. Should this be a configurable option for the site?? Obviously from the length of this issue, people feel it is a useful feature. . . dtan ------------------------------------------------------------------------ October 27, 2004 - 05:32 : tvst I WANT THIS FEATURE BACK! Sure, there were problems with it -- but let's fix the bug instead of killing a nice feature. ------------------------------------------------------------------------ November 4, 2004 - 00:02 : Goba Dries just committed a patch, which removes that superflous cookie setting, so session time in upcoming versions will be determined by the PHP settings, and short lived cookies will not be set. Until new versions are released, it is completely safe to remove the setcookie line in user.module (and the preg line above that), and it solves the problem of users needing to login everytime. ------------------------------------------------------------------------ November 5, 2004 - 07:02 : Anonymous wow. thanks. this was breaking my sites ------------------------------------------------------------------------ December 14, 2004 - 18:06 : kbahey This way, the PHP settings are the ones that determine the session length. Wouldn't it be better to have an admin option that allows users to set their session length? with a global default for sessions (e.g. 1 week, 2 weeks, 1 month, ...etc.) If this option is enabled, then it can be overriden by the user individually too. This is a better scheme than having a forced global setting outside Drupal, on the PHP level for all users. What do others think? ------------------------------------------------------------------------ February 3, 2005 - 19:50 : kbahey Reviving this issue. The session length should be an option that the administrator, or the end user can set. We should not rely on the PHP settings alone. ------------------------------------------------------------------------ February 12, 2005 - 01:54 : kbahey Attachment: http://drupal.org/files/issues/use-module-session.patch (1.92 KB) I feel that removing the setcookie() call was not the right thing to do. Session length should not be relegated to .htaccess or php.ini, but should be an application feature. I am attaching a patch that reinstates this functionality via a configuration option. The sysadmin determines how long visitors should have their session for, and a cookie is set for them with the appropriate lifetime. Please look at this rationally and objectively and do not dismiss it offhand because 'too many options are bad'. I had to go through php.ini and .htaccess hell for the last few months because my hosting company has implemented PHP suExec (hence .htaccess cannot set php parameters), then moved to another machine with .htaccess reinstated. This also allows people (like me) who serve several domains from a single Drupal installation to set the session length differently for different domains. Moreover, the Drupal end user should not have to go through fiddling with .htaccess values to get this functionality back. -- View: http://drupal.org/node/2974 Edit: http://drupal.org/project/comments/add/2974

1 0

[drupal-devel] [feature] "remember me" doesn't work
by kbahey 12 Feb '05

12 Feb '05

Project: Drupal Version: cvs Component: user.module -Category: bug reports +Category: feature requests Priority: normal -Assigned to: Anonymous +Assigned to: kbahey Reported by: marco Updated by: kbahey -Status: active +Status: patch Attachment: http://drupal.org/files/issues/use-module-session.patch (1.92 KB) I feel that removing the setcookie() call was not the right thing to do. Session length should not be relegated to .htaccess or php.ini, but should be an application feature. I am attaching a patch that reinstates this functionality via a configuration option. The sysadmin determines how long visitors should have their session for, and a cookie is set for them with the appropriate lifetime. Please look at this rationally and objectively and do not dismiss it offhand because 'too many options are bad'. I had to go through php.ini and .htaccess hell for the last few months because my hosting company has implemented PHP suExec (hence .htaccess cannot set php parameters), then moved to another machine with .htaccess reinstated. This also allows people (like me) who serve several domains from a single Drupal installation to set the session length differently for different domains. Moreover, the Drupal end user should not have to go through fiddling with .htaccess values to get this functionality back. kbahey Previous comments: ------------------------------------------------------------------------ September 22, 2003 - 08:37 : marco "remember me" checkbox in the login box doesn't work; even if the checkbox is left unchecked the user is NOT forgotten when he quits the browser. Try logging in w/o "remember me", then quit the browser and open it again: you should be still logged in. What happens: when you login w/o checkbox user.module outputs a cookie with lifetime = 0 ("until session ends"); but user.module calls session_start() at the beginning, which outputs a cookie too, with the lifetime specified in .htaccess; and session_start() outputs this cookie always, so on the next page the cookie from user_login() will be overwritten. I run Mozilla 1.4; I can replicate with Drupal 4.0 and Drupal 4.2 on PHP 4.3.3, and I can replicate this on drupal.org which also runs PHP 4.3.3; OTOH I can't replicate on a site running Drupal 4.2 with PHP 4.2.2, which may mean session_start() changed with PHP 4.3.x; I looked in the changelog of PHP but couldn't find anything. I didn't have any report about this before upgrading to PHP 4.3.3, which also seems to strengthen the hypothesis of a changed behaviour in PHP. Another test I did also showed that with PHP 4.2.2 no cookie is printed by session_start() if a session cookie is found, while it is always printed in PHP 4.3.3; I double checked the configurations and didn't find anything which may cause this. If you want to investigate this, I suggest you to use Mozilla and Live HTTP Headers plugin. ------------------------------------------------------------------------ October 10, 2003 - 19:37 : moshe weitzman Can anyone confirm this? Also, how to fix? ------------------------------------------------------------------------ October 12, 2003 - 12:45 : axel(a)debian.linuxrulez.ru I agree it for Mozilla 1.0. On my site running on FreeBSD 4.7, PHP/4.3.0, Drupal CVS (Oct 3) this function also don't work. Though, with Galeon 1.2.5 cookie works ok. On localhost (Debian GNU/Linux 3.0, PHP 4.1.2, same Drupal cvs version) it works ok with Mozilla & Galeon. ------------------------------------------------------------------------ October 12, 2003 - 13:34 : al The original bug report is surely due to Drupal needing to unset the cookie that it originally stored? To fix this bug, we therefore need a check on the user login/validation stage which forcibly unsets the cookie if you don't do "remember me". I suspect Axel's problems with one of his sites and not the other are due to him blocking a cookie originally and having that site on his Mozilla's list of sites to ban cookies from, or similar. Axel - if you are genuinely having issues with remember me not working at all (and not the fault originally described in this report by Ax) then please open a different bug report. Please make sure it's a genuine problem first - i.e. clear your blocked cookies sites list in Mozilla. ------------------------------------------------------------------------ October 12, 2003 - 18:24 : axel(a)debian.linuxrulez.ru Well. I don't sure what is a bug, therefore first post the question about it to forum [1]. Answer to that question point me to this bug report. Already several users of my site [2] report me about problem with "remember me" (I don't know which browsers they use). And there are not any blocked sites in my Mozilla cookies list - from site I receive only cookie PHPSESSID that expire time shows "at end of session". [1] http://drupal.org/node/view/3601 [2] http://debian.linuxrulez.ru ------------------------------------------------------------------------ October 17, 2003 - 15:36 : dmo Expect "remember me" problems for users of Internet Explorer 6. Depending on the privacy settings, IE6 may automatically expire all cookies at the end of the browser session if your site doesn't have a compact P3P policy. See http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpriv/htm… and http://www.oreillynet.com/pub/a/javascript/2002/10/04/p3p.html for further details. ------------------------------------------------------------------------ October 17, 2003 - 21:53 : moshe weitzman since noone can reproduce this, i am marking as 'by design' ------------------------------------------------------------------------ November 25, 2003 - 02:41 : junyoung This is not a IE6 specific problem. I have seen the same symptom with IE5.5/6.0, Opera 7.0/7.1, and Konqueror 3.1.x so far. FWIW, my blog site is running with Drupal 4.2.0 + PHP 4.3.3. ------------------------------------------------------------------------ November 25, 2003 - 09:06 : remco(a)rc6.org Same problem on http://rc6.org, though the other way around. No matter what I do, my session will time out eventually. Tested using Opera 7.x, IE, Mozilla and Epiphany. ------------------------------------------------------------------------ November 25, 2003 - 10:00 : moshe weitzman reopening this case. i confirm the behavior that marco describes using rc6.org and drupal.org. i find it easiest to just turn cookie prompting on in order to watch what is happenning. what i am seeing, like marco described, is that our 'permanent cookie' which is supposed to last for a year is being overwritten in the next request with a standard session cookie that expires in the time frame specified in .htaccess. for drupal.org, standard sesson cookies last 1 month whereas the permanent cookie lasts for a year. i don't know how to fix this from within drupal. the cookie that we lay down for 'remember me' is working fine. the problem is the later overwrite which is caused by PHP's session handing, not drupal. ------------------------------------------------------------------------ November 26, 2003 - 07:35 : moshe weitzman To make matters more complicated, I cannot reproduce this using PHP as an ISAPI module on IIS ------------------------------------------------------------------------ November 26, 2003 - 14:07 : Dries Maybe we can set a "remember" bit in the session table and periodically wipe users who don't have the "remember"-bit set. The wiping part could be added to sess_gc() ... ------------------------------------------------------------------------ December 3, 2003 - 20:30 : joshk I have this problem w/musicforamerica.org The really maddening thing is that I have another install of drupal 4.3 on the same webserver and it works just fine. If the problem is with drupal's cookie being overwritten by a PHP session cookie, can this be fixed by giving the cookies different names? Sounds too simple to be the solution... ------------------------------------------------------------------------ December 12, 2003 - 11:48 : ykoehler http://ca.php.net/manual/en/function.session-set-cookie-params.php Even though drupal is sending a cookie, it should always set this PHP parameter so that the session_start() call will use the same value, or not send any cookie at all by itself and let session_start() do it with, again, a call to this function to set the correct parameter. The reason why you don't get the same on a site basis is probably due to the different php.ini used for those sites as the default depends on the installation and not drupal which is probably why only some get the bug if there's such a thing. ------------------------------------------------------------------------ December 30, 2003 - 15:50 : paul(a)murphymaphia.com I am having the opposite problem. Even if I check the "remember me" box my session ends when the browser closes and I'm forced to log in the next time I return to the site. No cookie is EVER set by my site. http://www.murphymaphia.com ------------------------------------------------------------------------ January 20, 2004 - 12:31 : mathias Charles Miller has written a persistent login cookie best practices [3] i feel is worth reading. [3] http://fishbowl.pastiche.org/2004/01/19/persistent_login_cookie_best_practi… ------------------------------------------------------------------------ February 11, 2004 - 13:20 : paul(a)murphymaphia.com Has any progress been made on this? I have spent a lot of time in the code and can't manage to track this problem down. If anyone has any ideas, thoughts, etc to share, post them here so we can get this solved. ------------------------------------------------------------------------ February 12, 2004 - 00:07 : dmjossel I have this problem (remember me feature not working) in Drupal 4.3.x on PHP 4.3.2. I do NOT have it on Drupal 4.2 on PHP 4.3.2, in exactly the same environment. So perhaps sessions have changed in PHP 4.3.x, but this still didn't break Drupal 4.2, only 4.3.x. ------------------------------------------------------------------------ February 26, 2004 - 08:47 : moshe weitzman Attachment: http://drupal.org/files/issues/_4drupal (5.3 KB) Here is a patch which attempts to resolve this problem. I took Josh's suggestion - just rename the permanent cookie so it get overwritten by the PHP session cookie. So this patch names our permanent cookie 'remember_me'. The value of this cookie is the current sessionID. This cookie is checked in sess_read(). It is set just as before, in user_login(). I refactored sess_read() a bit for cleaner flow. It uses a new helper function called sess_construct_user(). Feedback welcome. Since not everyone experienced a problem with remember me, I'm particlarly interested in feedback from those who did. ------------------------------------------------------------------------ March 2, 2004 - 05:43 : dmjossel No observable effect. Users who click "remember me" are still logged out after a period of inactivity or a browser restart, as is true in 4.3.2 (but not true in 4.2 on the same machine). Just out of curiosity I made similar changes in a copy of 4.3.2, renaming the cookie-- also with no effect. What *is* odd is that I used to see this problem using Drupal.org itself. But I seem now to have been logged in for quite awhile (several days) without having to reauthenticate, despite long periods of inactivity and browser restarts. Has some change other than this patch been made to CVS running on the live site? ------------------------------------------------------------------------ March 2, 2004 - 06:21 : dmjossel One more follow up: the patch re-enables the "remember me" button on logon and the preferences for the user.module, but not the "logout" button in the user info block. ------------------------------------------------------------------------ March 6, 2004 - 11:33 : moshe weitzman The logout link never left, so naturally this patch does not re-instate it. By "user-info" block, i'm guessing that you mean the 'Navigation' block which holds the menu(). Drupal.org issues session cookies for a month so you can remain logged in for a long time. Anyone else have feedback on this patch. It is working for me. ------------------------------------------------------------------------ March 6, 2004 - 12:01 : Jeremy(a)kerneltrap.org Your patch works perfectly for me. I tested with three browsers (from Linux): Mozilla Firefox, Konquerer, Internet Explorer (via Wine) I did the following with each: 1) with latest CVS installation, I log in then restart my browser. I have to relogin. 2) I applied your patch to my CVS installation. 3) I logged in w/o checking "remember me". I then restart my browser, and I'm not logged in. 4) I logged in w/ "remember me" checked. I restart my browser, and I'm still logged in. 5) I logged in w/ "remember me" checked. I click logout, then restart my browser. I have to login again. ------------------------------------------------------------------------ April 8, 2004 - 20:09 : Brian(a)brianpuccio.net Using weitzmann's patch works for me. I had no problem when running 4.3.0, 4.3.1, or 4.3.2 on my site, but adding 4.4.0 I had to log in each time. Applying the patch to my (next to stock, but ever so slightly modified) install of 4.4.0 fixes the problem and I am remembered across browser tab closings, browser closings and system restarts. Thank you greatly. ------------------------------------------------------------------------ April 11, 2004 - 12:18 : Jeremy(a)kerneltrap.org Attachment: http://drupal.org/files/issues/session.inc.patch (651 bytes) I believe there is a small bug in weitzman's patch. I've been running with it applied on KernelTrap.org for some time, with much positive feedback from users. However, I noticed that occasionally I become a phantom surfer -- I'm logged in and accessing pages, but I don't show up in the "Who's online" block. I suspect the online guests number is low, too. After a little digging, I came up with the attached simple patch. I have yet to confirm if it solves the phantom surfer problem. Essentially, when we log in with a cookie we also update the sessions table timestamp. To use, first apply weitzman's patch (earlier in this thread), then apply this one. ------------------------------------------------------------------------ April 11, 2004 - 16:28 : Jeremy(a)kerneltrap.org Attachment: http://drupal.org/files/issues/session.inc_0.patch (584 bytes) My earlier patch didn't work. It was redundant with sess_write(), and added nothing new. Hence, it didn't fix the "phantom user" that I've been experiencing. Now, however, I believe I fully understand what's going wrong. Essentially what's happening is a user is being loaded via the remember_me cookie, but their session id is different. Thus, the db_query in sess_write() fails to update a user session in the database. This patch detects that failure and acts accordingly by creating a new entry. This patch applies against drupal 4.4 with weitzman's patch [4] applied. [4] http://drupal.org/files/issues/_4drupal ------------------------------------------------------------------------ April 15, 2004 - 02:39 : mabster Still seems to be a bit flakey. I get logged out every once in a while at work for some reason (during the day). And every time I move from my work to my home machines (or vice versa) I need to login again. Does the cookie base itself on my IP address or something? Could it be that because I'm switching between two different PCs that it can't remember my session details? ------------------------------------------------------------------------ April 21, 2004 - 21:19 : dmjossel I've upgraded the site Rampancy.net to Drupal 4.4 and applied Weitzman's patch. The behavior I'm seeing now I don't completely understand. Logging in to the site, you can quit the browser and stay logged in. But after a period of inactivity, somewhere between 30 and 60 minutes, the session expires and you have to log in again. I don't see this behavior on drupal.org. php.ini on the server is set for session cookies to last for 30 days. Drupal, by default, is supposed to give cookies that last 1 year. Is there anything else I should be looking at? Apparently some admins have this problem and others don't. Server info: FreeBSD synfibers.com 4.7-RELEASE-p22 FreeBSD 4.7-RELEASE-p22 #29: Tu i386 Apache/1.3.27 OpenSSL/0.9.7 (Unix) PHP/4.3.4 registered session save handlers are files and user. (local value is user) ------------------------------------------------------------------------ April 21, 2004 - 22:20 : mabster Yes, dmjossel's description matches the behaviour on my site (www.madprops.org) We're a hosted site, so I'm not exactly sure of the server's details. I'm fairly certain it's Windows2003. Definitely a Windows flavour, anyway, which means that this problem (with the patch applied) is not restricted to Linux. ------------------------------------------------------------------------ April 23, 2004 - 05:26 : dmjossel Apologies first for using this like a forum... mabster, upload a file to the server with the phpinfo(); in it (inside PHP tags of course). What values does it show for cookie-related functions? For session_save_handler? Perhaps there is a common element in server configuration in these two cases, despite the different operating systems. ------------------------------------------------------------------------ April 23, 2004 - 05:48 : mabster session.save_handler = files session.cookie_domain = no value session.cookie_lifetime = 0 session.cookie_path = / session.use_cookies = On session.use_only_cookie = Off Other info (at least until someone tells me that publishing this info is dangerous and I remove the file) here [5]. [5] http://www.madprops.org/info.php ------------------------------------------------------------------------ April 23, 2004 - 11:12 : dmjossel Suggestions... try setting session.use_only_cookies =1 either in php.ini, or if you don't have access to that, by using ini_set in drupal's php.conf and see if that has any effect. Next change Drupal's site configuration for the user module, and toggle whether you allow users to choose whether or not to be logged out (this produces the "remember me" cookie if you've installed weitzman's patch) or choose "users are never logged out". Neither of these seem to help here, but perhaps they'd help you. I noticed that until I set my browser to "accept all cookies automatically" and set session.use_only_cookies =1, I was getting the PHPSESSID cookie, but not the remember_me cookie. Now I get them both... but still logged out after 30 minutes of idle time, no matter what. ------------------------------------------------------------------------ April 23, 2004 - 11:26 : moshe weitzman those are not the session values that ship with drupal (see .htaccess file). for example, session_save_handler has to be 'user'. otherwise, you are not using drupal's session table and your 'remember me' will fail. since you are using IIS, you have to set your php.ini with values like those found in .htaccess. .htaccess files are only respected by Apache (and even then, not always. depends on your web host). ------------------------------------------------------------------------ April 23, 2004 - 19:39 : mabster Just out of interest, weitzman: How does drupal.org's 'remember me' work? I installed a cookie inspector on my machine at work, and didn't see any 'remember me' values in drupal.org's cookie. Does it use a different system? I will see what our host can do about changing the php.ini values. Since there are many sites hosted on that one box, it'll be a long shot to get them to change it. ------------------------------------------------------------------------ April 24, 2004 - 12:21 : dmjossel Try tweaking the value of session.gc_maxlifetime either in the .htaccess file or in php.ini. The default value in the .htaccess file seems to be 1440 seconds-- or 24 minutes, almost exactly the amount of time my sessions were lasting before being forced to log in again. I've increased this value, and now I'm seeing the remember_me cookie stay with the same value, while the PHPSESSID cookie is constantly being replaced by a new one-- but I don't have to log in again. ------------------------------------------------------------------------ April 24, 2004 - 20:23 : dmjossel Well, it's the next morning here, and I'm still logged in at Rampancy.net and the other Drupal 4.3 sites that are hosted on the same machine. I think at least this might be a workaround for those who have this problem and Weitzman's patch alone doesn't solve it. ------------------------------------------------------------------------ April 25, 2004 - 20:02 : dmjossel After a longer period of inactivity (equal to the value of session.gc_maxlifetime) the sessions ALWAYS seem to log the user out, regardless of the remember_me cookie value, the PHPSESSID value, or the configuration settings for the user module. ------------------------------------------------------------------------ May 6, 2004 - 06:34 : Robert L I can confirm #41, have tried changing some of the sessions vars in .htaccess, but this did not solve the problem. Sessions are destroyed after some time of browser inactivity (some hours). At the browser side things look oke, it happens with Mozilla and IE. Have not tested the patch yet, I am not using the remember me cookie option, and this looks another unrelated (?) problem to me. I use PHP 4.3.6 with Apache 2. ------------------------------------------------------------------------ June 5, 2004 - 21:41 : Anonymous I fixed it very simply by adding the line: session_set_cookie_params(0, "/dev/null"); immediately before the call to session_start(). This causes the cookie that PHP sets to only apply to the path "/dev/null" which, of course, doesn't exist. Thus, the cookie that Drupal's setcookie() call sets, with a path of "/", is held on to by the browser, and Drupal goes back to its old behaviour. It's a hack, but it works. A better long-term solution would be for Drupal to use the session_set_cookie_params() call to set the expiry time, rather than its own call to setcookie(). Tim Bates ------------------------------------------------------------------------ June 6, 2004 - 12:37 : bertboerland(a)www.drop.org I am sorry to say, that adding a line like that in user.module doesnt do the trick for me (running php 4.2.3/drupal 4.). Can it be that this might work under certain conditions which differ from mine? Anyone else still working on this *critical* bug? I am not changing the status but I think it should still read "active"? ------------------------------------------------------------------------ June 8, 2004 - 03:58 : bertboerland(a)www.drop.org never mind my previous remark... ------------------------------------------------------------------------ August 9, 2004 - 20:53 : moshe weitzman perhaps someone will take interest in this bug. i hope not to release another drupal version without 'remember me'. ------------------------------------------------------------------------ August 13, 2004 - 16:49 : seanr This used to work for me. Now I hear it's been completely disabled. Why? I'd rather have a feature that works for most users and not some than not have the feature at all. ------------------------------------------------------------------------ September 22, 2004 - 11:39 : Anonymous We dropped the whole 'remember me' posiibility in drupal 4.5. If it is - strategically seen - a good move, is another story, but now marked this as "Won't fix". ------------------------------------------------------------------------ September 22, 2004 - 15:35 : moshe weitzman umm - thanks 'anonymous'. this is a valid feature request, even if it isn't a valid bug anymore. marking as such. ------------------------------------------------------------------------ October 13, 2004 - 22:45 : jasper this is a bug actually. If you don't think so, you really aren't thinking about user experience. ------------------------------------------------------------------------ October 19, 2004 - 13:48 : jasper I am having this problem with 4.5. After you login, the cookie that is set to expire in a month is overwritten by a session cookie, so remember me doesn;t work. I "fixed" this by hacking user.module to set its cookie to a non-existant path. Maybe that will mess something up. I notice that drupal.org overcomes this by setting the initial cookie to "host: drupal.org" and the second cookie to "domain: .drupal.org" Where is this documented? How do you do that? ------------------------------------------------------------------------ October 21, 2004 - 11:43 : Anonymous I was having the same problem. I changed user.module's call to setcookie() so that the cookie would expire after 2000000 seconds. That fixed it for me. Now I don't have to login every time I visit. I hope I didn't break anything else, though. setcookie(session_name(), session_id(), FALSE, $path); becomes: setcookie(session_name(), session_id(), time() + 2000000, $path); ------------------------------------------------------------------------ October 21, 2004 - 22:03 : dtan Ya, suddenly noticed that I had to login everytime . . . not a huge deal, but is a bit of a pain. Should this be a configurable option for the site?? Obviously from the length of this issue, people feel it is a useful feature. . . dtan ------------------------------------------------------------------------ October 26, 2004 - 23:32 : tvst I WANT THIS FEATURE BACK! Sure, there were problems with it -- but let's fix the bug instead of killing a nice feature. ------------------------------------------------------------------------ November 3, 2004 - 18:02 : Goba Dries just committed a patch, which removes that superflous cookie setting, so session time in upcoming versions will be determined by the PHP settings, and short lived cookies will not be set. Until new versions are released, it is completely safe to remove the setcookie line in user.module (and the preg line above that), and it solves the problem of users needing to login everytime. ------------------------------------------------------------------------ November 5, 2004 - 01:02 : Anonymous wow. thanks. this was breaking my sites ------------------------------------------------------------------------ December 14, 2004 - 12:06 : kbahey This way, the PHP settings are the ones that determine the session length. Wouldn't it be better to have an admin option that allows users to set their session length? with a global default for sessions (e.g. 1 week, 2 weeks, 1 month, ...etc.) If this option is enabled, then it can be overriden by the user individually too. This is a better scheme than having a forced global setting outside Drupal, on the PHP level for all users. What do others think? ------------------------------------------------------------------------ February 3, 2005 - 13:50 : kbahey Reviving this issue. The session length should be an option that the administrator, or the end user can set. We should not rely on the PHP settings alone. -- View: http://drupal.org/node/2974 Edit: http://drupal.org/project/comments/add/2974

1 0

[drupal-devel] Generating custom menu & sub-menu tabs
by gkrishna 12 Feb '05

12 Feb '05

Using drupal-4.5 Here is the custom menu list i added to the theme to get menu and sub-menu tabs (its jeremy's hacked code) When i click M_parent, the page refreshes, not listing any sub-tabs as desired. M_parent --> top level menu item M_child_1 --> child of M_parent M_child_2 --> child of M_parent I Step through the code to see the output ... Note: Complete code is given at the end $output .= "\n"; $menu = array(1882); print_r($menu); // output was M_parent as desired ... foreach ($menu as $mid) { $m = menu_get_menu(); print_r($m); // all menu ids just listing the last few lines of the menu output,.... [1883] => Array ( [title] => M_child_1 [path] => term/38 [children] => array ( ) [pid] => 1882 ) [1884] => Array ( [title] => M_child_2 [path] => term/39 [children] => array ( ) [pid] => 1882 ) [1882] => Array ( [title] => M_parent [path] => [children] => Array ( [0] => 1883 [1] => 1884 ) [pid] => 0 ) [0] => Array ( [title] => [path] => [children] => Array ( [0] => 1 [1] => 1882 ) ) // sub-menu tabs $output .= theme('menu_local_task', $mid, 1); // $output .= "\n"; switch ($path[0]) { case 'M_parent': $submenu = array(1883,1884); print_r($submenu); // desired output : M_child_1, M_child_2 but it is not getting listed in the menu sub tabs ... there was no output from the submenu ... menu table entires, mid pid path title description weight type ... 1882 0 M_parent 0 115 1883 1882 term/38 M_child_1 -2 118 1884 1882 term/39 M_child_2 8 118 I was told that someone was working on a more generic solution. Please let me know if i am going wrong somewhere Here is the complete code that can be added to the theme's (i use chameleon) header tab $tabs = ""; $output .= "<ul class=\"tabs first\">\n"; //$output .= "<ul class=\"tabs primary\">\n"; $menu = array(1882); print_r($menu); $active = 0; foreach ($menu as $mid) { $m = menu_get_menu(); print_r($m); $path = explode("/", drupal_get_path_alias($_GET['q'])); if ($path[0] == $m['items'][$mid]['path']) { $output .= theme('menu_local_task', $mid, 1); $active = 1; } else $output .= theme('menu_local_task', $mid, 0); }; $output .= "</ul>\n"; if ($active) { $output .= "<ul class=\"tabs second\">\n"; $output .= theme('menu_local_task', $mid, 1); // $output .= "<ul class=\"tabs secondary\">\n"; switch ($path[0]) { case 'M_parent': $submenu = array(1883,1884); print_r($submenu); break; default: $submenu = array(); } foreach ($submenu as $mid) { $output .= theme('menu_local_task', $mid, 0); } $output .= "</ul>\n"; // hack ends } // foreach ($menu as $mid)

1 0

[drupal-devel] [task] usability: redirect to proper page after edit/delete operations
by moshe weitzman 12 Feb '05

12 Feb '05

Project: Drupal Version: cvs Component: base system Category: tasks Priority: normal Assigned to: moshe weitzman Reported by: moshe weitzman Updated by: moshe weitzman Status: patch Attachment: http://drupal.org/files/issues/drdest.patch (11.05 KB) Here is a patch I've been wanting to finish for a while. This patch assures that you end up on the proper page after you edit/delete a node, comment, user, or url alias. This is true no matter if you go through the usual interface or the admin interface. Further, if click the 'edit' link from 3rd page of a custom sorted view (e.g. admin/comment&from=100&sort=asc&order=Author) you still are returned to the right page. The technique used here is generally available for module developers. I've minimally enhanced drupal_goto() so that it will redirect to the url specified in a 'destination' querystring parameter if such parameter exists. If it does not exist, we redirect just as today. No changes are required to existing drupal_goto() calls. A new helper function, drupal_get_destination() was added; it helps contruct the 'destination' string which is appended to add/edit links. The only downside I can see to this patch is that a few URLs are less pretty than before. These urls are only shown to admins. This could only be avoided by having each admin page implement its own way of passing a destination, or stashing the destination in the $_SESSION. We recently tried storing referer in $_SESSION, and it was eventually removed because of poor coordination when a user has multiple browser windows open. In addition to the above, - I cleaned up some 'destination' handling in user login code - I assured that after adding a new taxo term, we arrive back on the 'Add' page. That restores prior behavior moshe weitzman -- View: http://drupal.org/node/16246 Edit: http://drupal.org/project/comments/add/16246

9 10

[drupal-devel] [bug] Core help updates
by asimmonds 11 Feb '05

11 Feb '05

Project: Drupal Version: cvs Component: module system Category: bug reports Priority: normal Assigned to: Anonymous Reported by: asimmonds Updated by: asimmonds Status: patch Attachment: http://drupal.org/files/issues/help_updates_1.patch (29.5 KB) Patch to fix a number of small issues with the help: - permissions menu link updates in a number of modules help - anchor link fix in distributed auth help - "my account" link fix in user help - spelling correction in tracker.module help asimmonds -- View: http://drupal.org/node/17208 Edit: http://drupal.org/project/comments/add/17208

1 0

[drupal-devel] [task] Pager Queries, Node Access and Performance
by JonBob 11 Feb '05

11 Feb '05

Project: Drupal Version: cvs Component: node.module Category: tasks Priority: normal Assigned to: Anonymous Reported by: pyromanfo Updated by: JonBob -Status: active +Status: patch Attachment: http://drupal.org/files/issues/node_access.patch (2.91 KB) Here's a patch that splits the nid=0 check off into a separate query. If the user has such a grant, things should be really fast since we don't need any join or even DISTINCT() check. If not, the join is done as before, but without the "OR nid=0" piece. This ideally needs performance checking on systems using node access with nid=0 rows, using it without them, and not using it at all. JonBob Previous comments: ------------------------------------------------------------------------ February 1, 2005 - 10:54 : pyromanfo I've got a Drupal 4.5.2 site running with Taxonomy Access Control. When you go to view a taxonomy and it tries to do an access check, the SQL query takes literally minutes to complete. This is on a dual Xeon box, it's rather beefy and runs two other sites (vBulletin and a hacked up Postnuke site) just fine. The problem comes from the taxonomy_select_nodes function $sql_count = 'SELECT COUNT(DISTINCT(n.nid)) FROM {node} n '. node_access_join_sql() .' INNER JOIN {term_node} tn ON n.nid = tn.nid WHERE tn.tid IN ('. $str_tids .') AND n.status = 1 AND '. node_access_where_sql(); Which ends up looking like SELECT COUNT(DISTINCT(n.nid)) FROM node n INNER JOIN node_access na ON (na.nid = 0 OR na.nid = n.nid) INNER JOIN term_node tn0 ON n.nid = tn0.nid WHERE n.status = 1 AND na.grant_view = 1 AND CONCAT(na.realm, na.gid) IN ('all0','term_access1') AND tn0.tid IN (9) This will take several minutes to complete. The query next to it that selected the nodes themselves took 3 minutes to complete. Where is the problem exactly? I've seen elsewhere that this is a problem for node_privacy_byrole as well, which makes sense because really all the various access control modules are contributing here is an extra entry in the concat search. Let me know if you need any details of how the MySQL server is configured. Here's some data from my drupal database mysql> select count(nid) from node; +------------+ | count(nid) | +------------+ | 10376 | +------------+ 1 row in set (0.00 sec) mysql> select count(nid) from node_access; +------------+ | count(nid) | +------------+ | 41508 | +------------+ 1 row in set (0.00 sec) Drupal performs very snappily with the node_access stuff disabled, and otherwise it performs very well. A three minute increase in the execute time of an SQL query is just strange, there's something odd going on here I think. ------------------------------------------------------------------------ February 3, 2005 - 16:02 : pyromanfo Reducing the size of the 'realm' field of node_access to something manageable like 12 instead of the current 255 speeds up the query tremendously, still it's rather slow. I also added a search index on the grant_view permission, since the view permission is the only permission you'd want to check for more than one node usually. It did speed it up, however it still take a minute or so on my little test box. I'm going to tweak with it some more and see if I can get it performing better. ------------------------------------------------------------------------ February 3, 2005 - 18:12 : killes(a)www.drop.org Could you give us an estimate with numbers? Or even better, make available the database for testing? ------------------------------------------------------------------------ February 4, 2005 - 14:59 : pyromanfo I can't really make the database available without going through and setting all the text and titles to something random and the uid's to 2, I may try that. I can give you some more numbers tonight though when I start messing with it again. You want execution times and table sizes? Any other specific numbers? Should I just dump show status? ------------------------------------------------------------------------ February 4, 2005 - 15:21 : killes(a)www.drop.org Averages of execution times before and after would be fine, I think. The db would be great of course You could simple set all text to "foo" and email addresses to "root@localhost". ------------------------------------------------------------------------ February 5, 2005 - 12:31 : pyromanfo I'm running these tests on a similar database I haven't been developing on. Created from the same source data with the same script though, I just haven't been hacking it up and it runs on faster hardware. SELECT COUNT(DISTINCT(n.nid)) FROM node n INNER JOIN node_access na ON (na.nid = 0 OR na.nid = n.nid) INNER JOIN term_node tn0 ON n.nid = tn0.nid WHERE n.status = 1 AND na.grant_view = 1 AND CONCAT(na.realm, na.gid) IN ('all0','term_access1') AND tn0.tid IN (2); +------------------------+ | COUNT(DISTINCT(n.nid)) | +------------------------+ | 2993 | +------------------------+ 1 row in set (7 min 4.00 sec) Then I ran the following queries alter table node_access modify realm varchar(12) NOT NULL default ''; alter table node_access add index view_indx (nid,gid,realm,grant_view); Then I ran mysqlcheck --auto_repair -os Then the query again SELECT COUNT(DISTINCT(n.nid)) FROM node n INNER JOIN node_access na ON (na.nid = 0 OR na.nid = n.nid) INNER JOIN term_node tn0 ON n.nid = tn0.nid WHERE n.status = 1 AND na.grant_view = 1 AND CONCAT(na.realm, na.gid) IN ('all0','term_access1') AND tn0.tid IN (2); +------------------------+ | COUNT(DISTINCT(n.nid)) | +------------------------+ | 2993 | +------------------------+ 1 row in set (6 min 18.62 sec) Not as big a speed boost as I thought I was seeing unfortunately. Here's 'show variables' mysql> show variables; +---------------------------------+---------------------------------------------------+ | Variable_name | Value | +---------------------------------+---------------------------------------------------+ | back_log | 50 | | basedir | /usr/local/mysql/ | | binlog_cache_size | 32768 | | bulk_insert_buffer_size | 8388608 | | character_set_client | latin1 | | character_set_connection | latin1 | | character_set_database | latin1 | | character_set_results | latin1 | | character_set_server | latin1 | | character_set_system | utf8 | | character_sets_dir | /usr/local/mysql/share/mysql/charsets/ | | collation_connection | latin1_swedish_ci | | collation_database | latin1_swedish_ci | | collation_server | latin1_swedish_ci | | concurrent_insert | ON | | connect_timeout | 5 | | datadir | /usr/local/mysql/var/ | | date_format | %Y-%m-%d | | datetime_format | %Y-%m-%d %H:%i:%s | | default_week_format | 0 | | delay_key_write | ON | | delayed_insert_limit | 100 | | delayed_insert_timeout | 300 | | delayed_queue_size | 1000 | | expire_logs_days | 0 | | flush | OFF | | flush_time | 0 | | ft_boolean_syntax | + -><()~*:""&| | | ft_max_word_len | 84 | | ft_min_word_len | 4 | | ft_query_expansion_limit | 20 | | ft_stopword_file | (built-in) | | group_concat_max_len | 1024 | | have_archive | NO | | have_bdb | NO | | have_compress | YES | | have_crypt | YES | | have_csv | NO | | have_example_engine | NO | | have_geometry | YES | | have_innodb | YES | | have_isam | NO | | have_ndbcluster | NO | | have_openssl | NO | | have_query_cache | YES | | have_raid | NO | | have_rtree_keys | YES | | have_symlink | YES | | init_connect | | | init_file | | | init_slave | | | innodb_additional_mem_pool_size | 1048576 | | innodb_autoextend_increment | 8 | | innodb_buffer_pool_awe_mem_mb | 0 | | innodb_buffer_pool_size | 8388608 | | innodb_data_file_path | ibdata1:10M:autoextend | | innodb_data_home_dir | | | innodb_fast_shutdown | ON | | innodb_file_io_threads | 4 | | innodb_file_per_table | OFF | | innodb_locks_unsafe_for_binlog | OFF | | innodb_flush_log_at_trx_commit | 1 | | innodb_flush_method | | | innodb_force_recovery | 0 | | innodb_lock_wait_timeout | 50 | | innodb_log_arch_dir | | | innodb_log_archive | OFF | | innodb_log_buffer_size | 1048576 | | innodb_log_file_size | 5242880 | | innodb_log_files_in_group | 2 | | innodb_log_group_home_dir | ./ | | innodb_max_dirty_pages_pct | 90 | | innodb_table_locks | ON | | innodb_max_purge_lag | 0 | | innodb_mirrored_log_groups | 1 | | innodb_open_files | 300 | | innodb_thread_concurrency | 8 | | interactive_timeout | 28800 | | join_buffer_size | 131072 | | key_buffer_size | 8388600 | | key_cache_age_threshold | 300 | | key_cache_block_size | 1024 | | key_cache_division_limit | 100 | | language | /usr/local/mysql/share/mysql/english/ | | large_files_support | ON | | license | GPL | | local_infile | ON | | locked_in_memory | OFF | | log | OFF | | log_bin | OFF | | log_error | | | log_slave_updates | OFF | | log_slow_queries | OFF | | log_update | OFF | | log_warnings | 1 | | long_query_time | 10 | | low_priority_updates | OFF | | lower_case_file_system | OFF | | lower_case_table_names | 0 | | max_allowed_packet | 1048576 | | max_binlog_cache_size | 4294967295 | | max_binlog_size | 1073741824 | | max_connect_errors | 10 | | max_connections | 100 | | max_delayed_threads | 20 | | max_error_count | 64 | | max_heap_table_size | 16777216 | | max_insert_delayed_threads | 20 | | max_join_size | 4294967295 | | max_length_for_sort_data | 1024 | | max_relay_log_size | 0 | | max_seeks_for_key | 4294967295 | | max_sort_length | 1024 | | max_tmp_tables | 32 | | max_user_connections | 0 | | max_write_lock_count | 4294967295 | | myisam_data_pointer_size | 4 | | myisam_max_extra_sort_file_size | 2147483648 | | myisam_max_sort_file_size | 2147483647 | | myisam_recover_options | OFF | | myisam_repair_threads | 1 | | myisam_sort_buffer_size | 8388608 | | net_buffer_length | 16384 | | net_read_timeout | 30 | | net_retry_count | 10 | | net_write_timeout | 60 | | new | OFF | | old_passwords | ON | | open_files_limit | 1024 | | pid_file | ********** | | port | 3306 | | preload_buffer_size | 32768 | | protocol_version | 10 | | query_alloc_block_size | 8192 | | query_cache_limit | 1048576 | | query_cache_min_res_unit | 4096 | | query_cache_size | 0 | | query_cache_type | ON | | query_cache_wlock_invalidate | OFF | | query_prealloc_size | 8192 | | range_alloc_block_size | 2048 | | read_buffer_size | 131072 | | read_only | OFF | | read_rnd_buffer_size | 262144 | | relay_log_purge | ON | | rpl_recovery_rank | 0 | | secure_auth | OFF | | server_id | 0 | | skip_external_locking | ON | | skip_networking | OFF | | skip_show_database | OFF | | slave_net_timeout | 3600 | | slow_launch_time | 2 | | socket | /tmp/mysql.sock | | sort_buffer_size | 2097144 | | sql_mode | | | storage_engine | MyISAM | | sync_binlog | 0 | | sync_frm | ON | | system_time_zone | EST | | table_cache | 64 | | table_type | MyISAM | | thread_cache_size | 0 | | thread_stack | 196608 | | time_format | %H:%i:%s | | time_zone | SYSTEM | | tmp_table_size | 33554432 | | tmpdir | | | transaction_alloc_block_size | 8192 | | transaction_prealloc_size | 4096 | | tx_isolation | REPEATABLE-READ | | version | 4.1.7 | | version_comment | Source distribution | | version_compile_machine | i686 | | version_compile_os | pc-linux | | wait_timeout | 28800 | +---------------------------------+---------------------------------------------------+ 176 rows in set (0.03 sec) I'm attaching my test database which takes several minutes to execute a similar query If you want me to run the tests on the test database I can do that, it's just on a much skimpier machine and it takes quite a bit longer (Athlon 600, 256MB Ram vs Dual Xeon). ------------------------------------------------------------------------ February 5, 2005 - 12:33 : pyromanfo Oops, preview removed the test db, here it is. ------------------------------------------------------------------------ February 5, 2005 - 12:38 : pyromanfo It's too big, it's 4.47 MB, I'm gonna put it up on GWJ and link to it. Get it here [1] [1] http://www.gamerswithjobs.com/testdb/drupal_test_db.tar.bz2 ------------------------------------------------------------------------ February 5, 2005 - 12:46 : pyromanfo Attachment: http://drupal.org/files/issues/drupal_test_db.tar.bz2 (734.78 KB) Nevermind, I left in some sensitive info and forgot to wipe the search index, now it's much smaller. ------------------------------------------------------------------------ February 7, 2005 - 17:58 : killes(a)www.drop.org Thanks, but I think you stripped the DB a bit too much. If I execute the query it is very fast because it does not return anything... ------------------------------------------------------------------------ February 7, 2005 - 18:12 : killes(a)www.drop.org When I use the query from your original post, I get some result. I guess I will write a script and run some tests over night... ------------------------------------------------------------------------ February 7, 2005 - 18:55 : killes(a)www.drop.org Ok, here are some preliminary results: - The unchanged query from the original post runs nearly 14 minutes on the hardware redLED lent to us. - If I shorten the varchar field to 18 from 255, it gets about halfed. - neither adding an index for the realm nor the grant_view field does make a change - Omitting the "na.nid = 0 OR" part makes the query very fast (quarter of a second) - SELECT COUNT(DISTINCT(n.nid)) FROM node n INNER JOIN node_access na ON ( na.nid = n.nid) left jo in node_access nb ON nb.nid = 0 INNER JOIN term_node tn0 ON n.nid = tn0.nid WHERE n.status = 1 AND ((n a.grant_view = 1 AND CONCAT(na.realm, na.gid) IN ('all0','term_access1')) OR (nb.grant_view = 1 AND CON CAT(nb.realm, nb.gid) IN ('all0','term_access1'))) AND tn0.tid IN (9); This query is still very much faster (about half a second) than the original query and gives the same result for your database. I don't know if it is fully equivalent, though. Note that it is a left join. ------------------------------------------------------------------------ February 8, 2005 - 08:06 : pyromanfo The na.nid = 0 stuff is basically a catchall, that's sort of a default permission that overrides anything else. This is good when you're not using node_access, however when you are the na.nid=0 stuff probably isn't there, I know Node Privacy By Role and Taxonomy Access Control both delete the entries for nid=0. Perhaps it's a good idea to control this another way, by setting a variable and using that to determine whether or not some sort of node_access is installed, as it seems using nid = 0 as a default simply kills performance. ------------------------------------------------------------------------ February 8, 2005 - 08:08 : pyromanfo Oh, and thanks for taking a good look at it killes, I should've explained better. The DB I provided, the test DB, has a large number of nodes in tid=9, the other DB I ran the tests on has alot in tid=2. ------------------------------------------------------------------------ February 8, 2005 - 11:17 : Anonymous The more I think about replacing nid=0 with a configuration setting the more it makes sense. The two major node access modules right now have to have a seperate "enable/disable" setting to deal with nid=0, since it overrides everything. In fact, it seems like it's only purpose it to override all other node access settings with a universal default. Why not instead have a global configuration setting under permissions that enables or disable node level permissions, then the various node access modules wouldn't need a seperate disable/enable setting. Furthermore, this performance problem would disappear, because either the node_access stuff would be there and you aren't looking for nid=0, or it isn't and you don't care what's in node_access. It seems it'd save queries to node access when you're not using node level permissions, and make it cleaner to implement a node access modifying module. ------------------------------------------------------------------------ February 8, 2005 - 11:17 : pyromanfo I hate the site randomly logging you out, that was me above. ------------------------------------------------------------------------ February 8, 2005 - 14:23 : JonBob "The more I think about replacing nid=0 with a configuration setting the more it makes sense. The two major node access modules right now have to have a seperate "enable/disable" setting to deal with nid=0, since it overrides everything. In fact, it seems like it's only purpose it to override all other node access settings with a universal default." This is not the case. I think you're confusing the case of nid=0 with the case of realm=all. As an example of the utility of nid=0, consider the scenario given in the example access module [2]. This module implements a simple system whereby anyone can view "public" nodes, and only users with a specific permission can view "private" nodes. This can be rephrased as follows: anonymous users can only view "public" nodes, while privileged users can view all nodes. A grant with nid=0 takes care of the second case, so that the module only needs to deal with granting permission to view the public nodes as necessary. Gerhard's query works in the case where every node has at least one node_access entry with its nid, but I'm afraid it fails in the above example. A node that is private would not have any corresponding entry, and so the inner join would fail for it, returning no record. The left join doesn't even have a chance to be matched. It would be worth benchmarking the scenario in which the nid=0 possibility is removed from the query, but the node_access table has an entry added for each node instead of a single nid=0 entry. If this is faster than the OR in the join, the extra DB storage is probably worth the change. [2] http://drupaldocs.org/api/head/file/contributions/docs/developer/examples/n… ------------------------------------------------------------------------ February 8, 2005 - 20:08 : pyromanfo "As an example of the utility of nid=0, consider the scenario given in the example access module. This module implements a simple system whereby anyone can view "public" nodes, and only users with a specific permission can view "private" nodes. This can be rephrased as follows: anonymous users can only view "public" nodes, while privileged users can view all nodes. A grant with nid=0 takes care of the second case, so that the module only needs to deal with granting permission to view the public nodes as necessary. " I think there's a bug in the module, in the docs in the top shouldn't the initial SQL statement be adding that permission to gid=1? Though you're right, I'd forgotten because I hadn't seen any of the current modules use it. As for that performance comparison mysql> SELECT COUNT(DISTINCT(n.nid)) FROM node n INNER JOIN term_node tn0 ON n.nid = tn0.nid INNER JOIN node_access na ON (na.nid = n.nid) WHERE n.status = 1 AND na.grant_view = 1 AND CONCAT(na.realm, na.gid) IN ('all0','term_access1') AND tn0.tid IN (2); +------------------------+ | COUNT(DISTINCT(n.nid)) | +------------------------+ | 2993 | +------------------------+ 1 row in set (0.23 sec) mysql> update node_access set realm='blam' where realm='term_access'; Query OK, 41508 rows affected (5.42 sec) Rows matched: 41508 Changed: 41508 Warnings: 0 mysql> insert into node_access (nid,gid,realm,grant_view) values (0,1,'term_access',1); Query OK, 1 row affected (0.00 sec) mysql> SELECT COUNT(DISTINCT(n.nid)) FROM node n INNER JOIN term_node tn0 ON n.nid = tn0.nid INNER JOIN node_access na ON (na.nid = 0 OR na.nid=n.nid) WHERE n.status = 1 AND na.grant_view = 1 AND CONCAT(na.realm, na.gid) IN ('all0','term_access1') AND tn0.tid IN (2); +------------------------+ | COUNT(DISTINCT(n.nid)) | +------------------------+ | 2993 | +------------------------+ 1 row in set (0.16 sec) So I don't think it improves performance for the nid=0 case, though it is suprisingly slow. ------------------------------------------------------------------------ February 8, 2005 - 20:57 : moshe weitzman perhaps we should split the query into 2 queries in order to avoid the 'na.nid = 0' part of the JOIN. Alternatively, perhaps we could inject that clause only when needed using the db_rewrite_sql hook. not sure. ------------------------------------------------------------------------ February 9, 2005 - 23:36 : pyromanfo Splitting it into two queries would make sense I think. Basically you could have it entirely in node_access_join_sql and node_access_where_sql. There we can check for the nid=0 case for any gids and realms. Then if it returns true, we know we don't have to check anything else, so we return null for the SQL to enter. We could even store this in a static variable to avoid calling this twice for join_sql and where_sql So in the nid=0 case, this should be similarly fast as we're removing a table from the JOIN in exchange for checking node_access for one nid. mysql> select count(nid) from node_access where nid=0 and gid=1 and realm in ('all','term_access','blah'); +------------+ | count(nid) | +------------+ | 0 | +------------+ 1 row in set (0.37 sec) SELECT COUNT(DISTINCT(n.nid)) FROM node n INNER JOIN term_node tn0 ON n.nid = tn0.nid WHERE n.status = 1 AND tn0.tid IN (9); +------------------------+ | COUNT(DISTINCT(n.nid)) | +------------------------+ | 4202 | +------------------------+ 1 row in set (0.15 sec) SELECT COUNT(DISTINCT(n.nid)) FROM node n INNER JOIN node_access na ON (na.nid = 0 OR na.nid = n.nid) INNER JOIN term_node tn0 ON n.nid = tn0.nid WHERE n.status = 1 AND na.grant_view = 1 AND CONCAT(na.realm, na.gid) IN ('all0','blah1') AND tn0.tid IN (9); +------------------------+ | COUNT(DISTINCT(n.nid)) | +------------------------+ | 4202 | +------------------------+ 1 row in set (1.97 sec) It looks to be faster, actually. Then, when we don't get a result, we check node access with the 'na.nid=0 OR' removed. This is certain to be faster as the test have shown, taking the query down from 7 minutes to a matter of seconds. In either case, this method would be faster. Plus, it wouldn't require any changes to other modules, simply change the node_access_where_sql and node_access_join_sql functions. JonBob, would you be okay with that? I can code it if you think you'll accept the patch. ------------------------------------------------------------------------ February 10, 2005 - 08:38 : Anonymous Splitting the queries into two is probably the only way to go. However, I'd like to avoid calling the nid = 0 query if possible. My Drupal installations that use node access do not use nid = 0 at all. I think we could store the available (nid = 0) => realm combinations somewhere and only execute the query if a matching condition is found. Gerhard ------------------------------------------------------------------------ February 10, 2005 - 10:14 : moshe weitzman that nid=0 is going to be very fast when done all by itself. no need to introduce any other mechanism IMO. testing will tell us for sure though ------------------------------------------------------------------------ February 10, 2005 - 13:31 : killes(a)www.drop.org The nid = 0 query would be executed for every node query on a page call even if your access module doesn't use nid = 0 at all. Most implementations do not use nid = 0. If we can avoid a query we should do so. -- View: http://drupal.org/node/16558 Edit: http://drupal.org/project/comments/add/16558

1 0