Login Session breaks while editing draft posts.

[norwat]

Since upgrading to WP 2.7, and including WP security features in config file (auth, secure_auth, logged_in, nonce keys), I have had some very inconsistent results working as administrator in Dashboard.

I have two blogs on one domain. I have tried a number of combinations: different security keys in config files for both blogs, same security keys in config files, different administrator usernames and passwords, same username and passwords. But none of it seems to make a difference, I always get the same results. I am able to work as administrator for a period, and then the dashboard freezes and keeps sending me to Log-in page. The only way to get things started again, is to clear cookies, relaunch browser, log in and out as various users, and after some combination of these (it appears to be different each time), I am able to log-in. Especially after one calendar date has passed.

I am really, really frustrated by this problem. There appears to be a bug or some conflict between cookies in all browsers (firefox, safari, camino, on Mac OS), and security features with WordPress, especially with two blogs located on one domain.

Is there a fix for this ... is there something I have missed in setting up blogs and configuring settings for multiple blogs on a single domain. Right now, I have removed security features, and everything is working beautifully.

[hakre]

this is only an assumption but the suggestion is genereally a good one:

change the userID of the one admin of the one blog to another numerical ID then on the other blog. maybe you are using 1 (default admin) on both blogs?

because both blogs are on the same domain, they share cookies (as you already assume) and because some of those cookies are tagged with the userID) those data might get shared and wordpress does not now any longer where it belongs to.

thanks for sharing your experience. a core developer should get a deeper insight into this issue so to double-check all the data exchange points passed here. i do not know enough how and which cookies wordpress is using.

how to change the userID of an admin? just create another admin account, log out, log in with the new admin account and then delete the old admin account and transfer that users data to the new admin.

please report back if changing the userID helps.

[Denis-de-Bernardy]

works fine on my end...

[norwat]

It is not possible to delete the #1_userID position. I have created a second user on one blog (with different user name), but still encounter problems. I am wondering if password log-in information is stored with cookies in browser cache ... so that clearing cookies only corrects one half of issue.

[hakre]

Norwat, I was able to delete the User with the UserID 1. I tested that with the current 2.8 trunk version before making the suggestion.

The information stored with the browser is stored in the cookies. When I perform a typical login with my new Admin user I get the following cookies (leaving Remember Me unchecked):

Name: wordpress_test_cookie
Content: WP+Cookie+check
Note: This is a cookie to test wether or not your Browser accepts Cookies

Name: wordpress_a0be5ceeffc28c7caa836f171da9c323
Content: Admin2%7C1242040204%7C4ab0fdcd8c4582ef39f6bf446ceadfa6
Path: /wordpress-trunk/wp-content/plugins
Note: I have no infos about this cookie. It is related to the Account Name ('Admin2' in this case). a0be5ceeffc28c7caa836f171da9c323 is the so called COOKIEHASH which is md5(get_option('siteurl')).

Name: wordpress_a0be5ceeffc28c7caa836f171da9c323
Content: Admin2%7C1242040204%7C4ab0fdcd8c4582ef39f6bf446ceadfa6
Path: /wordpress-trunk/wp-admin
Note: Same as above only with a different path.

Name: wordpress_logged_in_a0be5ceeffc28c7caa836f171da9c323
Content: Admin2%7C1242040204%7C8167f7683d14a5e2237358d63b2baa6a
Path: /wordpress-trunk/
Note: I have no infos about this cookie. It is related to the Account Name.

Name: wp-settings-2
Content: m0%3Dc%26m1%3Dc%26m2%3Dc%26m3%3Dc%26m4%3Dc%26m5%3Do%26m6%3Dc%26m7%3Dc%26m8%3Dc
Path: /wordpress-trunk/
Note: User Settings. This is bound to the UserID (2 in this case). This is mostly for Screen Options (Number of Rows displayed, which columns to display) in the Backend. It is not bound to a specific wordpress Installation only by the path. That is 'wordpress-trunk' in my case.

Name: wp-settings-time-2
Content: 1241867405
Path: /wordpress-trunk/
Note: Another user Setting, unknown to me which one. Bound to the UserID again.

This setup is using the default configuration keys:

define('AUTH_KEY', 'put your unique phrase here');
define('SECURE_AUTH_KEY', 'put your unique phrase here');
define('LOGGED_IN_KEY', 'put your unique phrase here');
define('NONCE_KEY', 'put your unique phrase here');

This is the cookies array viewed from the Server Side in PHP (path: /wordpress-trunk/wp-admin/):

array
  'wordpress_a0be5ceeffc28c7caa836f171da9c323' => string 'Admin2|1242040204|4ab0fdcd8c4582ef39f6bf446ceadfa6' (length=50)
  'wordpress_test_cookie' => string 'WP Cookie check' (length=15)
  'wordpress_logged_in_a0be5ceeffc28c7caa836f171da9c323' => string 'Admin2|1242040204|8167f7683d14a5e2237358d63b2baa6a' (length=50)
  'wp-settings-2' => string 'm0=c&m1=c&m2=c&m3=c&m4=c&m5=o&m6=c&m7=c&m8=c' (length=44)
  'wp-settings-time-2' => string '1241867405' (length=10)

As far as I can see there is no duplicate use of cookies between two wordpress installations on the same server. Because of set Pathes for the cookies this should not happen.

There is some cookie stored information that is not aware of the current host/path the wordpress blog is published under and it is auth related: wp_parse_auth_cookie().

What I'm missing is the PHP Session Cookie. I can't find it. But it looks anyway that way that PHP Session Management is not used at all. To check this I disabled it on the fly and everything still works.

To analyze further I suggest you name the siteurls of the two blogs sothat it is easier to gain a better picutre.

[hakre]

Replying to Denis-de-Bernardy:

works fine on my end...

Which version? Reporter is using 2.7.1.

[Denis-de-Bernardy]

It's shared cookies across three WP 2.7.1 and a BB 1.0 alpha. There is a custom cookie handler (the one from WP 2.8) due to BB 1.0.

[norwat]

I am now having the same problem with the security keys removed from my config document. I'm thinking there may be a source that is not related to cookies.

I am using the "Press This" item for some of my posts (in the menu bar of the browser). From time to time, I then go to the admin dashboard to alter or add an item. I thought the problem had to do with cookies (and two blogs on same domain), but maybe it is the interaction of "press this" and admin log-ins.

The Problem: WordPress kicks me back to the log-in administration page, but I am not logged out of WordPress. So when I try to log-in, I only get to the last previously viewed page, and on my second action get booted back to the log-in page. When I try a different browser ... same thing, I am unable to log-in and remain logged in for longer than a single action.

This is the same problem I wrote about above, but it is happening with no security features and also after removing cookies. There is nothing I can do to log-back in to the dashboard, until there is some time that has passed (and the server perhaps recognizes a period of inactivity and logs me out?). Sorry, I am a bit confused about the source of the problem, and so do not know what to describe where to look for a solution. But I'm definitely having a difficult time with this?

[Denis-de-Bernardy]

have you tried to define the cookie domain and the cookie path, so as to force the two, in case it makes a difference?

[norwat]

I think I am narrowing it down.

The problem is when I am working on a post that is a "draft" (not an item that has been posted) and I want to add an item under the "new custom field." The javascript button doesn't work. I click on it, and nothing happens, and I get logged out of the administration dashboard back to log-in page (but I am actually still logged in).

The problem just occurred, and I was able to log-in under a new user (and the warning appeared on the top of the page saying I was still logged in and was working on page). I was still unable to add a "new custom field" under the new user, but was able to publish the post (and then add the field).

There appears to be a bug with the java feature on "add new custom field" when working with a post that has already been saved as a draft

[Denis-de-Bernardy]

passing this over to andrew, in case it rings a bell on his end.

[azaozz]

This sounds more like a support question (assuming it's for 2.7). Does it happen in all newer browsers? Two things to try: delete both wp-admin and wp-includes directories and upload fresh copies from freshly extracted source, set the browser to always delete cookies on exit.

There were some problems with the js for saving custom fields but they were fixed in trunk some time ago.

[norwat]

I tried this, and no difference. I am testing issues in most current browsers for Mac OS (Firefox, Safari, and Camino). I replaced wp-admin and wp-includes with current versions, removed cookies, and I still can't log-in (once dashboard freezes). It's not just the "custom fields" button that triggers this issue. Today, I also tried to schedule a post to a different date (after using "press this" feature), and same issue.

I think it may have to do with the "press this" feature. After authoring a post and saving it, I click on the "edit post" tab, and whatever I do on dashboard at this point (or at least updating custom field or schedule post feature, since this has what has triggered issue for me) I get the problem.

I am pretty sure it is not a support issue, but a bug. I am anxious to resolve this issue.

[norwat]

Update ... let me try and explain what I think (from my limited understanding) is happening, and why this is a bug. The Press-This feature appears to work independent of the dashboard, meaning there is a separate log-in process when you author a post with this feature. There appears to be a bug moving back and forth between the two log-in processes: 1) authoring a post with Press This, and 2) editing a post in the admin dashboard. Once my dashboard freezes, and I am unable to make any changes in WordPress without getting sent back to log-in window, I am still able to use the Press This feature to upload content and post to blog accordingly. The fact that I am prevented from updating content across all browser platforms (Safari, Firefox, and Camino) in administration window leads me to think there is something with the log-in feature that is triggered by a process in "press this," and leaves me without the ability to edit posts. The software/database appears to think, and sometimes gives me the message, that I am already logged on ... and appears to be incapable of tracking my movements back and forth between "press this" and the "administration dashboard," and keeping track of "who" is accessing files (regardless of cookies being removed or not).

[norwat]

Perhaps this is helpful to know ... I turned off all my plugins (and then turned them on again), and the problem disappeared.

Maybe it cleared up on its own (as it has done in the past), or working with plug-ins has something to do with it. But I thought it was worth mentioning.

[azaozz]

PressThis works pretty much like the rest of the admin but in a smaller window. This problem may have something to do with a plugin or with your computer.

Lets think the opposite way: if this was a rare bug in 2.7 (it has been downloaded over 5.3 mil. times) there would have been thousands of people affected.

Next thing to try would be to access your installs from another computer and see if this happens again (to rule out your computer). Then turn off the plugins one by one to see which makes a difference.

[Denis-de-Bernardy]

Replying to norwat:

Perhaps this is helpful to know ... I turned off all my plugins (and then turned them on again), and the problem disappeared.

thing is, by merely mentioning this, you're highlighting that it's plugin-related and invalid.

please re-open if you can reproduce the issue with all plugins disabled and when the default theme. if so, be sure to highlight how. If not, please contact the plugin or theme author whose piece of software is causing it.

[norwat]

I ABSOLUTELY must re-open this ticket. This is a persistent little bug. It has now completely closed down my site, and made the dashboard unworkable (no matter the browser, computer platform, or plug-in activation). I have searched the user forums, and it seems I am not alone in having this problem (of staying logged in to dashboard). And yet, nobody has suggested a solution.

I have been on the phone three times with my web host (with excellent customer support and input on wordpress ... liquidweb), and they report there is no problem with login to database, php pages, or apache server. They watched logs, and received no error messages. One time, simply them logging into dashboard twice in a row cleared up the error. But on subsequent tries (on two follow up calls), they were not able to get the dashboard working again. The wordpress dashboard is "BROKEN" on my site ... and the software seems incapable to track log-in information, cookies, or something else (clearing ALL private data makes NO difference). I am also thinking someone may have hacked my site. I had a new unknown user created on one site with admin functions (the site with secure_auth and other security keys still active), which I promptly deleted. I examined content of site, and nothing appears to have been changed. I mention this for information purposes only, this problem appears to be widespread looking at the user formus, which is a clear indication to me that it is something that WordPress "absolutely must" address.

[Denis-de-Bernardy]

Trouble is, short of having a step by step means to reproduce the issue -- with the default theme and no plugins active -- there are no chances this will get fixed.

[norwat]

I'm sorry for all the trouble and frustration. I finally have it figured out. It was a plug in called WP-CMS Post Control. I am in contact with the developer and am closing this ticket.