Hi, Is there a backdoor way to force admin login if everything fails? Something like the way $update_free_access is changed to TRUE to allow running update.php....? A client got locked out of D6.15 completely, including admin. Login seems to work (I see admin only links on logon), cookies are set, but only on the initial page.... any subsequent click is treated as done by an anonymous user (checked the watchdog this way). I've cleared all browser caches, Drupal caches via the db, also the Drupal sessions table, checked the cookie domain, the admin user record exists in the user table, etc. in settings.php, deleted and re-uploaded D6.15. Nothing in the php logs. Nothing unusual in watchdog - just access denied by anonymous... Spent an equivalent of a day on this but I know there is a ton of things I can still try - e.g. rebuild access rights. But I do need to log in first, only by myself. So... is there a way to force admin login? Cannot find this info anywhere. Thanks! Tomáš
You can always edit the database directly. It sounds like a cookie problem, though. Try setting the cookie domain explicitly in your settings.php file to just example.com (not www.example.com, or whatever). Also, check to make sure that uid 0 is still intact in the database. That's another common source of weirdness, in my experience. --Larry Garfield Tomáš Fülöpp (vacilando.org) wrote:
Hi,
Is there a backdoor way to force admin login if everything fails? Something like the way $update_free_access is changed to TRUE to allow running update.php....?
A client got locked out of D6.15 completely, including admin. Login seems to work (I see admin only links on logon), cookies are set, but only on the initial page.... any subsequent click is treated as done by an anonymous user (checked the watchdog this way). I've cleared all browser caches, Drupal caches via the db, also the Drupal sessions table, checked the cookie domain, the admin user record exists in the user table, etc. in settings.php, deleted and re-uploaded D6.15. Nothing in the php logs. Nothing unusual in watchdog - just access denied by anonymous... Spent an equivalent of a day on this but I know there is a ton of things I can still try - e.g. rebuild access rights. But I do need to log in first, only by myself. So... is there a way to force admin login? Cannot find this info anywhere.
Thanks!
Tomáš
Since this *really* sounds just like the "cookies not enabled in browser" situation, I just wanted to mention something I'm sure you already tried, which is accessing it from a different browser or computer. It's trivial to make all drupal logins stop working: You just turn off cookies in the browser, and it works just like you're describing. -Randy On Tue, Feb 23, 2010 at 5:30 PM, larry@garfieldtech.com < larry@garfieldtech.com> wrote:
You can always edit the database directly.
It sounds like a cookie problem, though. Try setting the cookie domain explicitly in your settings.php file to just example.com (not www.example.com, or whatever).
Also, check to make sure that uid 0 is still intact in the database. That's another common source of weirdness, in my experience.
--Larry Garfield
Tomáš Fülöpp (vacilando.org) wrote:
Hi,
Is there a backdoor way to force admin login if everything fails? Something like the way $update_free_access is changed to TRUE to allow running update.php....?
A client got locked out of D6.15 completely, including admin. Login seems to work (I see admin only links on logon), cookies are set, but only on the initial page.... any subsequent click is treated as done by an anonymous user (checked the watchdog this way). I've cleared all browser caches, Drupal caches via the db, also the Drupal sessions table, checked the cookie domain, the admin user record exists in the user table, etc. in settings.php, deleted and re-uploaded D6.15. Nothing in the php logs. Nothing unusual in watchdog - just access denied by anonymous... Spent an equivalent of a day on this but I know there is a ton of things I can still try - e.g. rebuild access rights. But I do need to log in first, only by myself. So... is there a way to force admin login? Cannot find this info anywhere.
Thanks!
Tomáš
-- Randy Fay Drupal Development, troubleshooting, and debugging randy@randyfay.com +1 970.462.7450
I've seen a corrupt sessions MySQL table cause problems too. -Don- On 2/23/2010 9:57 PM, Randy Fay wrote:
Since this *really* sounds just like the "cookies not enabled in browser" situation, I just wanted to mention something I'm sure you already tried, which is accessing it from a different browser or computer.
It's trivial to make all drupal logins stop working: You just turn off cookies in the browser, and it works just like you're describing.
-Randy
On Tue, Feb 23, 2010 at 5:30 PM, larry@garfieldtech.com <mailto:larry@garfieldtech.com> <larry@garfieldtech.com <mailto:larry@garfieldtech.com>> wrote:
You can always edit the database directly.
It sounds like a cookie problem, though. Try setting the cookie domain explicitly in your settings.php file to just example.com <http://example.com> (not www.example.com <http://www.example.com>, or whatever).
Also, check to make sure that uid 0 is still intact in the database. That's another common source of weirdness, in my experience.
--Larry Garfield
Tomáš Fülöpp (vacilando.org <http://vacilando.org>) wrote:
Hi,
Is there a backdoor way to force admin login if everything fails? Something like the way $update_free_access is changed to TRUE to allow running update.php....?
A client got locked out of D6.15 completely, including admin. Login seems to work (I see admin only links on logon), cookies are set, but only on the initial page.... any subsequent click is treated as done by an anonymous user (checked the watchdog this way). I've cleared all browser caches, Drupal caches via the db, also the Drupal sessions table, checked the cookie domain, the admin user record exists in the user table, etc. in settings.php, deleted and re-uploaded D6.15. Nothing in the php logs. Nothing unusual in watchdog - just access denied by anonymous... Spent an equivalent of a day on this but I know there is a ton of things I can still try - e.g. rebuild access rights. But I do need to log in first, only by myself. So... is there a way to force admin login? Cannot find this info anywhere.
Thanks!
Tomáš
-- Randy Fay Drupal Development, troubleshooting, and debugging randy@randyfay.com <mailto:randy@randyfay.com> +1 970.462.7450
Hi, Thanks for the quick comments. Quick replies: - It may be a cookie problem, but only in ways I am not understanding. It is not the case of blocked cookies in browser. After all, many other Drupal sites, same version, work. - User table record 0 (anon) is intact, so is record 1 (admin). - Setting cookie domain with www - tried, but no effect. After all, it's been working for more than a year without www. - Corrupt session table? I don't think so -- as I said, I truncated it. Also ran analysis and repair on it, and on all other tables as well, in fact. Now, there is *some* progress. I have set the site to maintenance mode by setting the "site_offline" variable. SURPRISE - I am not being kicked out of the session! Tried all sorts of things - access rebuild, cache clearing, switching off all but bare necessary modules, opening and saving permissions page and the admin user account, etc., logical and illogical things. Still, however, when I set the site out of the maintenance mode, it kicks me out of the session on second or third click. Sometimes more clicks. I think I went up to 5. I wonder why should it work in maintenance mode but not without it? Cookies seem to be OK, right? Session table as well. It must be something else.. but what? *This is the crucial question*: What is special about the maintenance mode that could be causing this difference? This should narrow down the possible causes. Thanks for any further ideas... Tomáš PS Btw, I've also installed the dev version of D6 (because of the menu router problem, which I was experiencing in D6.15 and I suspected that could be a problem), but it did not help. On Wed, Feb 24, 2010 at 04:31, Don <donald@fane.com> wrote:
I've seen a corrupt sessions MySQL table cause problems too.
-Don-
On 2/23/2010 9:57 PM, Randy Fay wrote:
Since this *really* sounds just like the "cookies not enabled in browser" situation, I just wanted to mention something I'm sure you already tried, which is accessing it from a different browser or computer.
It's trivial to make all drupal logins stop working: You just turn off cookies in the browser, and it works just like you're describing.
-Randy
On Tue, Feb 23, 2010 at 5:30 PM, larry@garfieldtech.com < larry@garfieldtech.com> wrote:
You can always edit the database directly.
It sounds like a cookie problem, though. Try setting the cookie domain explicitly in your settings.php file to just example.com (not www.example.com, or whatever).
Also, check to make sure that uid 0 is still intact in the database. That's another common source of weirdness, in my experience.
--Larry Garfield
Tomáš Fülöpp (vacilando.org) wrote:
Hi,
Is there a backdoor way to force admin login if everything fails? Something like the way $update_free_access is changed to TRUE to allow running update.php....?
A client got locked out of D6.15 completely, including admin. Login seems to work (I see admin only links on logon), cookies are set, but only on the initial page.... any subsequent click is treated as done by an anonymous user (checked the watchdog this way). I've cleared all browser caches, Drupal caches via the db, also the Drupal sessions table, checked the cookie domain, the admin user record exists in the user table, etc. in settings.php, deleted and re-uploaded D6.15. Nothing in the php logs. Nothing unusual in watchdog - just access denied by anonymous... Spent an equivalent of a day on this but I know there is a ton of things I can still try - e.g. rebuild access rights. But I do need to log in first, only by myself. So... is there a way to force admin login? Cannot find this info anywhere.
Thanks!
Tomáš
-- Randy Fay Drupal Development, troubleshooting, and debugging randy@randyfay.com +1 970.462.7450
It's possible that it is a time zone issue / session length issue. We were having a problem on another (non-Drupal site) where the user would be logged out immediately or in a very short time. It turned out that their timezone settings were incorrect which caused the cookie to expire immediately rather than after our one hour default session length. Fixing the timezone worked as did increasing the default session length. Regards, Mark Noble On 2/24/2010 5:29 AM, Tomáš Fülöpp (vacilando.org) wrote:
Hi,
Thanks for the quick comments. Quick replies:
* It may be a cookie problem, but only in ways I am not understanding. It is not the case of blocked cookies in browser. After all, many other Drupal sites, same version, work. * User table record 0 (anon) is intact, so is record 1 (admin). * Setting cookie domain with www - tried, but no effect. After all, it's been working for more than a year without www. * Corrupt session table? I don't think so -- as I said, I truncated it. Also ran analysis and repair on it, and on all other tables as well, in fact.
Now, there is _some_ progress. I have set the site to maintenance mode by setting the "site_offline" variable. SURPRISE - I am not being kicked out of the session! Tried all sorts of things - access rebuild, cache clearing, switching off all but bare necessary modules, opening and saving permissions page and the admin user account, etc., logical and illogical things.
Still, however, when I set the site out of the maintenance mode, it kicks me out of the session on second or third click. Sometimes more clicks. I think I went up to 5.
I wonder why should it work in maintenance mode but not without it? Cookies seem to be OK, right? Session table as well. It must be something else.. but what? _This is the crucial question_: What is special about the maintenance mode that could be causing this difference? This should narrow down the possible causes.
Thanks for any further ideas...
Tomáš
PS Btw, I've also installed the dev version of D6 (because of the menu router problem, which I was experiencing in D6.15 and I suspected that could be a problem), but it did not help.
On Wed, Feb 24, 2010 at 04:31, Don <donald@fane.com <mailto:donald@fane.com>> wrote:
I've seen a corrupt sessions MySQL table cause problems too.
-Don-
On 2/23/2010 9:57 PM, Randy Fay wrote:
Since this *really* sounds just like the "cookies not enabled in browser" situation, I just wanted to mention something I'm sure you already tried, which is accessing it from a different browser or computer.
It's trivial to make all drupal logins stop working: You just turn off cookies in the browser, and it works just like you're describing.
-Randy
On Tue, Feb 23, 2010 at 5:30 PM, larry@garfieldtech.com <mailto:larry@garfieldtech.com> <larry@garfieldtech.com <mailto:larry@garfieldtech.com>> wrote:
You can always edit the database directly.
It sounds like a cookie problem, though. Try setting the cookie domain explicitly in your settings.php file to just example.com <http://example.com> (not www.example.com <http://www.example.com>, or whatever).
Also, check to make sure that uid 0 is still intact in the database. That's another common source of weirdness, in my experience.
--Larry Garfield
Tomáš Fülöpp (vacilando.org <http://vacilando.org>) wrote:
Hi,
Is there a backdoor way to force admin login if everything fails? Something like the way $update_free_access is changed to TRUE to allow running update.php....?
A client got locked out of D6.15 completely, including admin. Login seems to work (I see admin only links on logon), cookies are set, but only on the initial page.... any subsequent click is treated as done by an anonymous user (checked the watchdog this way). I've cleared all browser caches, Drupal caches via the db, also the Drupal sessions table, checked the cookie domain, the admin user record exists in the user table, etc. in settings.php, deleted and re-uploaded D6.15. Nothing in the php logs. Nothing unusual in watchdog - just access denied by anonymous... Spent an equivalent of a day on this but I know there is a ton of things I can still try - e.g. rebuild access rights. But I do need to log in first, only by myself. So... is there a way to force admin login? Cannot find this info anywhere.
Thanks!
Tomáš
-- Randy Fay Drupal Development, troubleshooting, and debugging randy@randyfay.com <mailto:randy@randyfay.com> +1 970.462.7450
Good idea, Mark. Checked time zone -- but it is correct. Anyway, if that were the problem then it would not work in maintenance mode, I assume. On Wed, Feb 24, 2010 at 15:27, Mark Noble <mark-d-noble@comcast.net> wrote:
It's possible that it is a time zone issue / session length issue. We were having a problem on another (non-Drupal site) where the user would be logged out immediately or in a very short time. It turned out that their timezone settings were incorrect which caused the cookie to expire immediately rather than after our one hour default session length. Fixing the timezone worked as did increasing the default session length.
Regards, Mark Noble
On 2/24/2010 5:29 AM, Tomáš Fülöpp (vacilando.org) wrote:
Hi,
Thanks for the quick comments. Quick replies:
- It may be a cookie problem, but only in ways I am not understanding. It is not the case of blocked cookies in browser. After all, many other Drupal sites, same version, work. - User table record 0 (anon) is intact, so is record 1 (admin). - Setting cookie domain with www - tried, but no effect. After all, it's been working for more than a year without www. - Corrupt session table? I don't think so -- as I said, I truncated it. Also ran analysis and repair on it, and on all other tables as well, in fact.
Now, there is *some* progress. I have set the site to maintenance mode by setting the "site_offline" variable. SURPRISE - I am not being kicked out of the session! Tried all sorts of things - access rebuild, cache clearing, switching off all but bare necessary modules, opening and saving permissions page and the admin user account, etc., logical and illogical things.
Still, however, when I set the site out of the maintenance mode, it kicks me out of the session on second or third click. Sometimes more clicks. I think I went up to 5.
I wonder why should it work in maintenance mode but not without it? Cookies seem to be OK, right? Session table as well. It must be something else.. but what? *This is the crucial question*: What is special about the maintenance mode that could be causing this difference? This should narrow down the possible causes.
Thanks for any further ideas...
Tomáš
PS Btw, I've also installed the dev version of D6 (because of the menu router problem, which I was experiencing in D6.15 and I suspected that could be a problem), but it did not help.
On Wed, Feb 24, 2010 at 04:31, Don <donald@fane.com> wrote:
I've seen a corrupt sessions MySQL table cause problems too.
-Don-
On 2/23/2010 9:57 PM, Randy Fay wrote:
Since this *really* sounds just like the "cookies not enabled in browser" situation, I just wanted to mention something I'm sure you already tried, which is accessing it from a different browser or computer.
It's trivial to make all drupal logins stop working: You just turn off cookies in the browser, and it works just like you're describing.
-Randy
On Tue, Feb 23, 2010 at 5:30 PM, larry@garfieldtech.com < larry@garfieldtech.com> wrote:
You can always edit the database directly.
It sounds like a cookie problem, though. Try setting the cookie domain explicitly in your settings.php file to just example.com (not www.example.com, or whatever).
Also, check to make sure that uid 0 is still intact in the database. That's another common source of weirdness, in my experience.
--Larry Garfield
Tomáš Fülöpp (vacilando.org) wrote:
Hi,
Is there a backdoor way to force admin login if everything fails? Something like the way $update_free_access is changed to TRUE to allow running update.php....?
A client got locked out of D6.15 completely, including admin. Login seems to work (I see admin only links on logon), cookies are set, but only on the initial page.... any subsequent click is treated as done by an anonymous user (checked the watchdog this way). I've cleared all browser caches, Drupal caches via the db, also the Drupal sessions table, checked the cookie domain, the admin user record exists in the user table, etc. in settings.php, deleted and re-uploaded D6.15. Nothing in the php logs. Nothing unusual in watchdog - just access denied by anonymous... Spent an equivalent of a day on this but I know there is a ton of things I can still try - e.g. rebuild access rights. But I do need to log in first, only by myself. So... is there a way to force admin login? Cannot find this info anywhere.
Thanks!
Tomáš
-- Randy Fay Drupal Development, troubleshooting, and debugging randy@randyfay.com +1 970.462.7450
If the site has been working for a year now without any problems, something had to change, right? What changed? New modules maybe? What modules do you have installed? Maybe one of them is dumping your session or something. On Wed, Feb 24, 2010 at 7:55 AM, Tomáš Fülöpp (vacilando.org) < tomi@vacilando.org> wrote:
Good idea, Mark. Checked time zone -- but it is correct. Anyway, if that were the problem then it would not work in maintenance mode, I assume.
On Wed, Feb 24, 2010 at 15:27, Mark Noble <mark-d-noble@comcast.net>wrote:
It's possible that it is a time zone issue / session length issue. We were having a problem on another (non-Drupal site) where the user would be logged out immediately or in a very short time. It turned out that their timezone settings were incorrect which caused the cookie to expire immediately rather than after our one hour default session length. Fixing the timezone worked as did increasing the default session length.
Regards, Mark Noble
On 2/24/2010 5:29 AM, Tomáš Fülöpp (vacilando.org) wrote:
Hi,
Thanks for the quick comments. Quick replies:
- It may be a cookie problem, but only in ways I am not understanding. It is not the case of blocked cookies in browser. After all, many other Drupal sites, same version, work. - User table record 0 (anon) is intact, so is record 1 (admin). - Setting cookie domain with www - tried, but no effect. After all, it's been working for more than a year without www. - Corrupt session table? I don't think so -- as I said, I truncated it. Also ran analysis and repair on it, and on all other tables as well, in fact.
Now, there is *some* progress. I have set the site to maintenance mode by setting the "site_offline" variable. SURPRISE - I am not being kicked out of the session! Tried all sorts of things - access rebuild, cache clearing, switching off all but bare necessary modules, opening and saving permissions page and the admin user account, etc., logical and illogical things.
Still, however, when I set the site out of the maintenance mode, it kicks me out of the session on second or third click. Sometimes more clicks. I think I went up to 5.
I wonder why should it work in maintenance mode but not without it? Cookies seem to be OK, right? Session table as well. It must be something else.. but what? *This is the crucial question*: What is special about the maintenance mode that could be causing this difference? This should narrow down the possible causes.
Thanks for any further ideas...
Tomáš
PS Btw, I've also installed the dev version of D6 (because of the menu router problem, which I was experiencing in D6.15 and I suspected that could be a problem), but it did not help.
On Wed, Feb 24, 2010 at 04:31, Don <donald@fane.com> wrote:
I've seen a corrupt sessions MySQL table cause problems too.
-Don-
On 2/23/2010 9:57 PM, Randy Fay wrote:
Since this *really* sounds just like the "cookies not enabled in browser" situation, I just wanted to mention something I'm sure you already tried, which is accessing it from a different browser or computer.
It's trivial to make all drupal logins stop working: You just turn off cookies in the browser, and it works just like you're describing.
-Randy
On Tue, Feb 23, 2010 at 5:30 PM, larry@garfieldtech.com < larry@garfieldtech.com> wrote:
You can always edit the database directly.
It sounds like a cookie problem, though. Try setting the cookie domain explicitly in your settings.php file to just example.com (not www.example.com, or whatever).
Also, check to make sure that uid 0 is still intact in the database. That's another common source of weirdness, in my experience.
--Larry Garfield
Tomáš Fülöpp (vacilando.org) wrote:
Hi,
Is there a backdoor way to force admin login if everything fails? Something like the way $update_free_access is changed to TRUE to allow running update.php....?
A client got locked out of D6.15 completely, including admin. Login seems to work (I see admin only links on logon), cookies are set, but only on the initial page.... any subsequent click is treated as done by an anonymous user (checked the watchdog this way). I've cleared all browser caches, Drupal caches via the db, also the Drupal sessions table, checked the cookie domain, the admin user record exists in the user table, etc. in settings.php, deleted and re-uploaded D6.15. Nothing in the php logs. Nothing unusual in watchdog - just access denied by anonymous... Spent an equivalent of a day on this but I know there is a ton of things I can still try - e.g. rebuild access rights. But I do need to log in first, only by myself. So... is there a way to force admin login? Cannot find this info anywhere.
Thanks!
Tomáš
-- Randy Fay Drupal Development, troubleshooting, and debugging randy@randyfay.com +1 970.462.7450
Cameron, yes, something must've changed.. module or something else. So, third day, still no luck. (I had to log in 600x today alone!) But I found something for sure. It is related to Views (current stable version). I stay logged in whenever browsing admin or content types, but when I access a Views table, any of them (of profiles or content types alike), suddenly I am logged out. There is no "access denied", because these views are all public (unrestricted permissions), they do show, but there are no admin links etc around on that moment. And nothing in php log, nothing useful in watchdog. Like usually in despair in small hours, I start to consider the work of black magic.... :-( Thanks in any case to those who've added their 2 cents of ideas. On Wed, Feb 24, 2010 at 16:15, Cameron Eagans <cweagans@gmail.com> wrote:
If the site has been working for a year now without any problems, something had to change, right? What changed? New modules maybe? What modules do you have installed? Maybe one of them is dumping your session or something.
On Wed, Feb 24, 2010 at 7:55 AM, Tomáš Fülöpp (vacilando.org) < tomi@vacilando.org> wrote:
Good idea, Mark. Checked time zone -- but it is correct. Anyway, if that were the problem then it would not work in maintenance mode, I assume.
On Wed, Feb 24, 2010 at 15:27, Mark Noble <mark-d-noble@comcast.net>wrote:
It's possible that it is a time zone issue / session length issue. We were having a problem on another (non-Drupal site) where the user would be logged out immediately or in a very short time. It turned out that their timezone settings were incorrect which caused the cookie to expire immediately rather than after our one hour default session length. Fixing the timezone worked as did increasing the default session length.
Regards, Mark Noble
On 2/24/2010 5:29 AM, Tomáš Fülöpp (vacilando.org) wrote:
Hi,
Thanks for the quick comments. Quick replies:
- It may be a cookie problem, but only in ways I am not understanding. It is not the case of blocked cookies in browser. After all, many other Drupal sites, same version, work. - User table record 0 (anon) is intact, so is record 1 (admin). - Setting cookie domain with www - tried, but no effect. After all, it's been working for more than a year without www. - Corrupt session table? I don't think so -- as I said, I truncated it. Also ran analysis and repair on it, and on all other tables as well, in fact.
Now, there is *some* progress. I have set the site to maintenance mode by setting the "site_offline" variable. SURPRISE - I am not being kicked out of the session! Tried all sorts of things - access rebuild, cache clearing, switching off all but bare necessary modules, opening and saving permissions page and the admin user account, etc., logical and illogical things.
Still, however, when I set the site out of the maintenance mode, it kicks me out of the session on second or third click. Sometimes more clicks. I think I went up to 5.
I wonder why should it work in maintenance mode but not without it? Cookies seem to be OK, right? Session table as well. It must be something else.. but what? *This is the crucial question*: What is special about the maintenance mode that could be causing this difference? This should narrow down the possible causes.
Thanks for any further ideas...
Tomáš
PS Btw, I've also installed the dev version of D6 (because of the menu router problem, which I was experiencing in D6.15 and I suspected that could be a problem), but it did not help.
On Wed, Feb 24, 2010 at 04:31, Don <donald@fane.com> wrote:
I've seen a corrupt sessions MySQL table cause problems too.
-Don-
On 2/23/2010 9:57 PM, Randy Fay wrote:
Since this *really* sounds just like the "cookies not enabled in browser" situation, I just wanted to mention something I'm sure you already tried, which is accessing it from a different browser or computer.
It's trivial to make all drupal logins stop working: You just turn off cookies in the browser, and it works just like you're describing.
-Randy
On Tue, Feb 23, 2010 at 5:30 PM, larry@garfieldtech.com < larry@garfieldtech.com> wrote:
You can always edit the database directly.
It sounds like a cookie problem, though. Try setting the cookie domain explicitly in your settings.php file to just example.com (not www.example.com, or whatever).
Also, check to make sure that uid 0 is still intact in the database. That's another common source of weirdness, in my experience.
--Larry Garfield
Tomáš Fülöpp (vacilando.org) wrote:
Hi,
Is there a backdoor way to force admin login if everything fails? Something like the way $update_free_access is changed to TRUE to allow running update.php....?
A client got locked out of D6.15 completely, including admin. Login seems to work (I see admin only links on logon), cookies are set, but only on the initial page.... any subsequent click is treated as done by an anonymous user (checked the watchdog this way). I've cleared all browser caches, Drupal caches via the db, also the Drupal sessions table, checked the cookie domain, the admin user record exists in the user table, etc. in settings.php, deleted and re-uploaded D6.15. Nothing in the php logs. Nothing unusual in watchdog - just access denied by anonymous... Spent an equivalent of a day on this but I know there is a ton of things I can still try - e.g. rebuild access rights. But I do need to log in first, only by myself. So... is there a way to force admin login? Cannot find this info anywhere.
Thanks!
Tomáš
-- Randy Fay Drupal Development, troubleshooting, and debugging randy@randyfay.com +1 970.462.7450
I'll bet on a $user->uid = 0; or $user = user_load(0); Somewhere in a view php block or theme code affecting your view. If that's it, see http://drupal.org/node/218104 Regards, Greg On Wed, Feb 24, 2010 at 5:03 PM, Tomáš Fülöpp (vacilando.org) <tomi@vacilando.org> wrote:
Cameron, yes, something must've changed.. module or something else.
So, third day, still no luck. (I had to log in 600x today alone!)
But I found something for sure. It is related to Views (current stable version). I stay logged in whenever browsing admin or content types, but when I access a Views table, any of them (of profiles or content types alike), suddenly I am logged out. There is no "access denied", because these views are all public (unrestricted permissions), they do show, but there are no admin links etc around on that moment. And nothing in php log, nothing useful in watchdog. Like usually in despair in small hours, I start to consider the work of black magic.... :-(
Thanks in any case to those who've added their 2 cents of ideas.
On Wed, Feb 24, 2010 at 16:15, Cameron Eagans <cweagans@gmail.com> wrote:
If the site has been working for a year now without any problems, something had to change, right? What changed? New modules maybe? What modules do you have installed? Maybe one of them is dumping your session or something.
On Wed, Feb 24, 2010 at 7:55 AM, Tomáš Fülöpp (vacilando.org) <tomi@vacilando.org> wrote:
Good idea, Mark. Checked time zone -- but it is correct. Anyway, if that were the problem then it would not work in maintenance mode, I assume.
On Wed, Feb 24, 2010 at 15:27, Mark Noble <mark-d-noble@comcast.net> wrote:
It's possible that it is a time zone issue / session length issue. We were having a problem on another (non-Drupal site) where the user would be logged out immediately or in a very short time. It turned out that their timezone settings were incorrect which caused the cookie to expire immediately rather than after our one hour default session length. Fixing the timezone worked as did increasing the default session length.
Regards, Mark Noble
On 2/24/2010 5:29 AM, Tomáš Fülöpp (vacilando.org) wrote:
Hi,
Thanks for the quick comments. Quick replies:
It may be a cookie problem, but only in ways I am not understanding. It is not the case of blocked cookies in browser. After all, many other Drupal sites, same version, work. User table record 0 (anon) is intact, so is record 1 (admin). Setting cookie domain with www - tried, but no effect. After all, it's been working for more than a year without www. Corrupt session table? I don't think so -- as I said, I truncated it. Also ran analysis and repair on it, and on all other tables as well, in fact.
Now, there is some progress. I have set the site to maintenance mode by setting the "site_offline" variable. SURPRISE - I am not being kicked out of the session! Tried all sorts of things - access rebuild, cache clearing, switching off all but bare necessary modules, opening and saving permissions page and the admin user account, etc., logical and illogical things.
Still, however, when I set the site out of the maintenance mode, it kicks me out of the session on second or third click. Sometimes more clicks. I think I went up to 5.
I wonder why should it work in maintenance mode but not without it? Cookies seem to be OK, right? Session table as well. It must be something else.. but what? This is the crucial question: What is special about the maintenance mode that could be causing this difference? This should narrow down the possible causes.
Thanks for any further ideas...
Tomáš
PS Btw, I've also installed the dev version of D6 (because of the menu router problem, which I was experiencing in D6.15 and I suspected that could be a problem), but it did not help.
On Wed, Feb 24, 2010 at 04:31, Don <donald@fane.com> wrote:
I've seen a corrupt sessions MySQL table cause problems too.
-Don-
On 2/23/2010 9:57 PM, Randy Fay wrote:
Since this *really* sounds just like the "cookies not enabled in browser" situation, I just wanted to mention something I'm sure you already tried, which is accessing it from a different browser or computer.
It's trivial to make all drupal logins stop working: You just turn off cookies in the browser, and it works just like you're describing.
-Randy
On Tue, Feb 23, 2010 at 5:30 PM, larry@garfieldtech.com <larry@garfieldtech.com> wrote:
You can always edit the database directly.
It sounds like a cookie problem, though. Try setting the cookie domain explicitly in your settings.php file to just example.com (not www.example.com, or whatever).
Also, check to make sure that uid 0 is still intact in the database. That's another common source of weirdness, in my experience.
--Larry Garfield
Tomáš Fülöpp (vacilando.org) wrote: > > Hi, > > Is there a backdoor way to force admin login if everything fails? > Something like the way $update_free_access is changed to TRUE to allow > running update.php....? > > A client got locked out of D6.15 completely, including admin. Login > seems to work (I see admin only links on logon), cookies are set, but only > on the initial page.... any subsequent click is treated as done by an > anonymous user (checked the watchdog this way). I've cleared all browser > caches, Drupal caches via the db, also the Drupal sessions table, checked > the cookie domain, the admin user record exists in the user table, etc. in > settings.php, deleted and re-uploaded D6.15. Nothing in the php logs. > Nothing unusual in watchdog - just access denied by anonymous... Spent an > equivalent of a day on this but I know there is a ton of things I can still > try - e.g. rebuild access rights. But I do need to log in first, only by > myself. So... is there a way to force admin login? Cannot find this info > anywhere. > > Thanks! > > Tomáš >
-- Randy Fay Drupal Development, troubleshooting, and debugging randy@randyfay.com +1 970.462.7450
-- Greg Knaddison | 303-800-5623 | http://growingventuresolutions.com Mastering Drupal - http://www.masteringdrupal.com
The saga still continues -- but finally I am very close to solution. I wonder if anybody has an idea to help me in the last meter/yard... Forget about views causing the problem. I have found out that users (incl superadmin) are logged out when *images are displayed*! For historical reasons, the site has tens of thousands images like e.g. http://WWW.DOMAIN.TLD/en/system/files/images/image.jpg which are in fact in http://WWW.DOMAIN.TLD/sites/DOMAIN.TLD/files/images/image.jpg And accessing any page (be it a view or node) that shows an image located in /system causes this logout. I am sure about it - I blocked images in the browser, logged in, browsed happily, then in a different tab I loaded just the image http://WWW.DOMAIN.TLD/en/system/files/images/image.jpg and when I returned to the page I was logged in to, the following click was to an anonymous page. I've spent hours looking at /admin/settings/file-system but it is simply providing the usual path site/DOMAIN.TLD/files and anyway, the image http://WWW.DOMAIN.TLD/en/system/files/images/image.jpg does show to anonymous, so the private system works, it's just that it kills the session. I've allowed permission "view uploaded files" but again, that's not important. So the question is -- what could have caused change. *Why did http://WWW.DOMAIN.TLD/en/system/files/images/image.jpg show for a year without a problem and now its mere appearance kills the user session.* I realize this thread possibly shifts from development / debugging issue to a support one, but I hope you can bear with me for the final run. It's been a crazy marathon with a site others have admin rights to so I had to discover and guess what they inadvertently changed... Thanks for any tip, .t On Thu, Feb 25, 2010 at 01:05, Greg Knaddison <greg.knaddison@gmail.com>wrote:
I'll bet on a
$user->uid = 0; or $user = user_load(0);
Somewhere in a view php block or theme code affecting your view. If that's it, see http://drupal.org/node/218104
Regards, Greg
On Wed, Feb 24, 2010 at 5:03 PM, Tomáš Fülöpp (vacilando.org) <tomi@vacilando.org> wrote:
Cameron, yes, something must've changed.. module or something else.
So, third day, still no luck. (I had to log in 600x today alone!)
But I found something for sure. It is related to Views (current stable version). I stay logged in whenever browsing admin or content types, but when I access a Views table, any of them (of profiles or content types alike), suddenly I am logged out. There is no "access denied", because these views are all public (unrestricted permissions), they do show, but there are no admin links etc around on that moment. And nothing in php log, nothing useful in watchdog. Like usually in despair in small hours, I start to consider the work of black magic.... :-(
Thanks in any case to those who've added their 2 cents of ideas.
On Wed, Feb 24, 2010 at 16:15, Cameron Eagans <cweagans@gmail.com> wrote:
If the site has been working for a year now without any problems, something had to change, right? What changed? New modules maybe? What modules do you have installed? Maybe one of them is dumping your session
or
something.
On Wed, Feb 24, 2010 at 7:55 AM, Tomáš Fülöpp (vacilando.org) <tomi@vacilando.org> wrote:
Good idea, Mark. Checked time zone -- but it is correct. Anyway, if
that
were the problem then it would not work in maintenance mode, I assume.
On Wed, Feb 24, 2010 at 15:27, Mark Noble <mark-d-noble@comcast.net> wrote:
It's possible that it is a time zone issue / session length issue. We were having a problem on another (non-Drupal site) where the user
would be
logged out immediately or in a very short time. It turned out that their timezone settings were incorrect which caused the cookie to expire immediately rather than after our one hour default session length. Fixing the timezone worked as did increasing the default session length.
Regards, Mark Noble
On 2/24/2010 5:29 AM, Tomáš Fülöpp (vacilando.org) wrote:
Hi,
Thanks for the quick comments. Quick replies:
It may be a cookie problem, but only in ways I am not understanding. It is not the case of blocked cookies in browser. After all, many other Drupal sites, same version, work. User table record 0 (anon) is intact, so is record 1 (admin). Setting cookie domain with www - tried, but no effect. After all, it's been working for more than a year without www. Corrupt session table? I don't think so -- as I said, I truncated it. Also ran analysis and repair on it, and on all other tables as well, in fact.
Now, there is some progress. I have set the site to maintenance mode by setting the "site_offline" variable. SURPRISE - I am not being kicked out of the session! Tried all sorts of things - access rebuild, cache clearing, switching off all but bare necessary modules, opening and saving permissions page and the admin user account, etc., logical and illogical things.
Still, however, when I set the site out of the maintenance mode, it kicks me out of the session on second or third click. Sometimes more clicks. I think I went up to 5.
I wonder why should it work in maintenance mode but not without it? Cookies seem to be OK, right? Session table as well. It must be something else.. but what? This is the crucial question: What is special about the maintenance mode that could be causing this difference? This should narrow down the possible causes.
Thanks for any further ideas...
Tomáš
PS Btw, I've also installed the dev version of D6 (because of the menu router problem, which I was experiencing in D6.15 and I suspected that could be a problem), but it did not help.
On Wed, Feb 24, 2010 at 04:31, Don <donald@fane.com> wrote:
I've seen a corrupt sessions MySQL table cause problems too.
-Don-
On 2/23/2010 9:57 PM, Randy Fay wrote:
Since this *really* sounds just like the "cookies not enabled in browser" situation, I just wanted to mention something I'm sure you
already
tried, which is accessing it from a different browser or computer.
It's trivial to make all drupal logins stop working: You just turn off cookies in the browser, and it works just like you're describing.
-Randy
On Tue, Feb 23, 2010 at 5:30 PM, larry@garfieldtech.com <larry@garfieldtech.com> wrote: > > You can always edit the database directly. > > It sounds like a cookie problem, though. Try setting the cookie > domain explicitly in your settings.php file to just example.com(not > www.example.com, or whatever). > > Also, check to make sure that uid 0 is still intact in the database. > That's another common source of weirdness, in my experience. > > --Larry Garfield > > Tomáš Fülöpp (vacilando.org) wrote: >> >> Hi, >> >> Is there a backdoor way to force admin login if everything fails? >> Something like the way $update_free_access is changed to TRUE to allow >> running update.php....? >> >> A client got locked out of D6.15 completely, including admin. Login >> seems to work (I see admin only links on logon), cookies are set, but only >> on the initial page.... any subsequent click is treated as done by an >> anonymous user (checked the watchdog this way). I've cleared all browser >> caches, Drupal caches via the db, also the Drupal sessions table, checked >> the cookie domain, the admin user record exists in the user table, etc. in >> settings.php, deleted and re-uploaded D6.15. Nothing in the php logs. >> Nothing unusual in watchdog - just access denied by anonymous... Spent an >> equivalent of a day on this but I know there is a ton of things I can still >> try - e.g. rebuild access rights. But I do need to log in first, only by >> myself. So... is there a way to force admin login? Cannot find this info >> anywhere. >> >> Thanks! >> >> Tomáš >>
-- Randy Fay Drupal Development, troubleshooting, and debugging randy@randyfay.com +1 970.462.7450
-- Greg Knaddison | 303-800-5623 | http://growingventuresolutions.com Mastering Drupal - http://www.masteringdrupal.com
Tomáš Fülöpp (vacilando.org) wrote:
--8<-- So the question is -- what could have caused change. /Why did http://WWW.DOMAIN.TLD/en/system/files/images/image.jpg show for a year without a problem and now its mere appearance kills the user session./
I realize this thread possibly shifts from development / debugging issue to a support one, but I hope you can bear with me for the final run. It's been a crazy marathon with a site others have admin rights to so I had to discover and guess what they inadvertently changed...
Does the hosts syslog or httpd's access and error log give a clue? Was apache or php upgraded or a new module added? -- Earnie -- http://www.give-me-an-offer.com
That's the thing -- there is no error message anywhere :-( Not in PHP error log, not in dblog / watchdog, no Drupal message, and no problem highlighted in /admin/reports/status. Total mystery -- how can an image on a valid private path display but it kills the session? PHP / Apache upgrade may have happened -- I can pose this question to the cloud admins -- but what specifically would wreak this kind of havoc... what should they look for? Thanks.. .t On Thu, Mar 4, 2010 at 13:27, Drupal <earnie@users.sourceforge.net> wrote:
Tomáš Fülöpp (vacilando.org) wrote:
--8<--
So the question is -- what could have caused change. /Why did http://WWW.DOMAIN.TLD/en/system/files/images/image.jpg show for a year without a problem and now its mere appearance kills the user session./
I realize this thread possibly shifts from development / debugging issue to a support one, but I hope you can bear with me for the final run. It's been a crazy marathon with a site others have admin rights to so I had to discover and guess what they inadvertently changed...
Does the hosts syslog or httpd's access and error log give a clue? Was apache or php upgraded or a new module added?
-- Earnie -- http://www.give-me-an-offer.com
One thing that will be happening to us all shortly is php5.3 showing up everywhere, and Drupal is only slowly coming to readiness for that. Depending on the version you have and the contrib modules you have there may be many repercussions. PHP 5.3 is a major version upgrade but is being treated in many places as a minor version upgrade with some pretty significant consequences. I have no idea how that could relate to the problems you have, of course. -Randy On Thu, Mar 4, 2010 at 6:27 AM, Tomáš Fülöpp (vacilando.org) < tomi@vacilando.org> wrote:
That's the thing -- there is no error message anywhere :-( Not in PHP error log, not in dblog / watchdog, no Drupal message, and no problem highlighted in /admin/reports/status. Total mystery -- how can an image on a valid private path display but it kills the session?
PHP / Apache upgrade may have happened -- I can pose this question to the cloud admins -- but what specifically would wreak this kind of havoc... what should they look for?
Thanks..
.t
On Thu, Mar 4, 2010 at 13:27, Drupal <earnie@users.sourceforge.net> wrote:
Tomáš Fülöpp (vacilando.org) wrote:
--8<--
So the question is -- what could have caused change. /Why did http://WWW.DOMAIN.TLD/en/system/files/images/image.jpg show for a year without a problem and now its mere appearance kills the user session./
I realize this thread possibly shifts from development / debugging issue to a support one, but I hope you can bear with me for the final run. It's been a crazy marathon with a site others have admin rights to so I had to discover and guess what they inadvertently changed...
Does the hosts syslog or httpd's access and error log give a clue? Was apache or php upgraded or a new module added?
-- Earnie -- http://www.give-me-an-offer.com
-- Randy Fay Drupal Development, troubleshooting, and debugging randy@randyfay.com +1 970.462.7450
Good point, Randy. But in our case it's PHP 5.2.6. And to answer Earnie - no, PHP / server config have not changed recently and in fact other D6 sites run on the same cloud happily, so this problem won't come down to PHP / Apache versions. One possibly interesting bit from my conversation with the tech help: ** I just talked to our sysops team and out cache server will drop the cookie, so the cahce will have to be saved to a file as outlined here * http://cloudsites.rackspacecloud.com/index.php/Why_are_my_PHP_sessions_not_w... *But I assume this is irrelevant, because cookies are saved for other pages, even for other images, except for when they are on the private (/system) path. .t On Thu, Mar 4, 2010 at 14:48, Randy Fay <randy@randyfay.com> wrote:
One thing that will be happening to us all shortly is php5.3 showing up everywhere, and Drupal is only slowly coming to readiness for that. Depending on the version you have and the contrib modules you have there may be many repercussions.
PHP 5.3 is a major version upgrade but is being treated in many places as a minor version upgrade with some pretty significant consequences. I have no idea how that could relate to the problems you have, of course.
-Randy
On Thu, Mar 4, 2010 at 6:27 AM, Tomáš Fülöpp (vacilando.org) < tomi@vacilando.org> wrote:
That's the thing -- there is no error message anywhere :-( Not in PHP error log, not in dblog / watchdog, no Drupal message, and no problem highlighted in /admin/reports/status. Total mystery -- how can an image on a valid private path display but it kills the session?
PHP / Apache upgrade may have happened -- I can pose this question to the cloud admins -- but what specifically would wreak this kind of havoc... what should they look for?
Thanks..
.t
On Thu, Mar 4, 2010 at 13:27, Drupal <earnie@users.sourceforge.net>wrote:
Tomáš Fülöpp (vacilando.org) wrote:
--8<--
So the question is -- what could have caused change. /Why did http://WWW.DOMAIN.TLD/en/system/files/images/image.jpg show for a year without a problem and now its mere appearance kills the user session./
I realize this thread possibly shifts from development / debugging issue to a support one, but I hope you can bear with me for the final run. It's been a crazy marathon with a site others have admin rights to so I had to discover and guess what they inadvertently changed...
Does the hosts syslog or httpd's access and error log give a clue? Was apache or php upgraded or a new module added?
-- Earnie -- http://www.give-me-an-offer.com
-- Randy Fay Drupal Development, troubleshooting, and debugging randy@randyfay.com +1 970.462.7450
participants (8)
-
Cameron Eagans -
Don -
Drupal -
Greg Knaddison -
larry＠garfieldtech.com -
Mark Noble -
Randy Fay -
Tomáš Fülöpp (vacilando.org)