_ck_

What is in your siteurl field on the Settings->General screen?

both the wordpress and blog url are set to https://example.com/blog
(obviously changed to generic path)

I can only login if I use one of the following:

@define('ADMIN_COOKIE_PATH', '/');
@define('ADMIN_COOKIE_PATH', '/blog/');
@define('ADMIN_COOKIE_PATH', '/blog/wp-admin/');

(using the last one for now)

Otto42, my workaround actually also works if I set the path to
/blog/wp-admin/
so I guess there’s no need to argue this point, it’s mute.

If you want to edit my post to reflect the wp-admin part so you feel better about that, you are welcome to ??

It’s obvious WP is calculating that path incorrectly on some installs, and again, I am not certain of what exactly triggers it. I can’t examine the cookie via live headers because it doesn’t get set without the manual define.

Otto42, sending the cookie only over SSL for admin access is one thing but most people on shared hosting won’t be doing that.

The idea that a hacker could somehow spy on your connection/session and pick up the cookie for your regular login but not wait long enough until you do a transaction that uses wp-admin is silly.

(the moderators are very sensitive around here today)

Nah it’s not about being sensitive, they just want to make sure the right info goes out (and probably don’t like seeing problems). I’m a mod on the bbPress side and I’m the same way.

I just happen to think I know what I am doing or at least just enough to be helpful ??

Sending the admin cookie to the entire blog (instead of just the admin area) absolutely reduces the security.

Locking a cookie to specific path instead of the webroot only inconveniences the legitimate user – a hacker will simply change the cookie path as desired, WordPress doesn’t verify the path, only that the hash passes. It’s up to the browser to verify/limit the path.

The whole point is to make the admin cookie *only* go to the admin area.

The path change may make some browsers not even bother to send the cookie which might have been devised as “security” but it’s a false sense of security.

In what configurations, specifically?

The configurations that are failing admin login seem to include (but not limited to) installs that are not in the webroot. I would need more time to figure it out but to be honest, it’s not my job. They obviously did not test enough (and that’s typical for WP).

Otto42, I don’t think you understand what the value does or what a cookie path is. Changing the cookie’s path value does not remove it’s separation (or security).

It’s remains a separate cookie.

It’s just pointing by default to an incorrect path in some configurations which is why the browser can’t login (or stayed logged in).

They’ll have to fix this in 2.6.1 I guess.

Try my fix:
https://www.ads-software.com/support/topic/188964/page/2#post-803992

Try my fix:
https://www.ads-software.com/support/topic/188964/page/2#post-803992

Okay I found the REAL fix for the admin access.
Took a bit of digging in the code.
https://www.ads-software.com/support/topic/188964/page/2#post-803992

Okay I figured out a REAL fix for the admin access.
Took a bit of digging in the code.

It has to do with a bug in the new cookie for admin access
and how they (incorrectly) try to fall back to the default path.

go into your wp-config.php
and add this line:
@define('ADMIN_COOKIE_PATH', '/');

NOTE ‘/’ will be your blog path.
If you find that ‘/’ doesn’t work, make it ‘/blog/` or whatever your path is.

Otto42, it’s not just cookies either.
It’s a real problem within the 2.6 changes.

Otto42, people are having this issue even with upgrades via SVN switch.
So it’s not just a matter of missing files.

There’s definitely been a cookie issue that’s been overlooked.
I suspect it has to do with the cookie domain or path for admin login.

I actually have regular login working fine, it’s admin login that’s in endless-loop mode. Considering the admin login is what they tinkered (heavily) with, I suspect we’ll get a bug fix release or workaround issued by the end of today.

WP 2.6 has a new secret key, ugh:
https://www.ads-software.com/support/topic/170987?replies=3#post-803741

Ditto on this issue.

I have found the “Disable Core Update” does not actually work in preventing all activity. The reason is because the default priority for the add_action is too low.

edit the plugin and change the first line to this simple addition:
add_action( 'init', create_function( '$a', "remove_action( 'init', 'wp_version_check' );" ),2);

(only thing that is different is the “,2” which sets a very high priority)

This change is tested working.