cant access admin in ms install

[usermrpapa]

after fresh install of wp 3.0 and then visiting tools - network, and configuring the multi site stuff, the admin is no longer accessible. the front end all works fine, just cant get to the admin. it redirects and never gets there. I do show as logged in on the front end.

guessing this isnt a general issue, but just followed the network set up stuff...

using 3.0 nightly build...

[nacin]

It's a cookie issue. MS changes cookie defines, and WordPress bugs out. Pretty sure #12007 is related but there might be a better ticket I can't find.

We should definitely figure out a fix/workaround for this. Clearing your cookies I think does the trick.

[usermrpapa]

yes indeed. cleaning out the cookies and relogging in does solve the issue. guessing it will cause bunch of problems.

will leave open until there is another ticket identified or this one is used.

[wpmuguru]

Salts and Keys were added to MU at various points between 2.6 & 2.8. Every time one (or more) salt/key was added, some people reported this problem. Clearing cookies and/or browser cache has worked since 2.6. This isn't a problem with WordPress. For whatever reason (quite possibly a security measure), in some instances, the browser will not update the existing cookie with a new one.

The best we can do here is add information to the UI and/or the codex.

[usermrpapa]

while you are at it, should add more info to the network page when trying to 'activate' with a server name of localhost. No real indication of a problem or instructions to change. the message is not that informative. had to visit the code to figure out what was going on.

[nacin]

Replying to wpmuguru:

The best we can do here is add information to the UI and/or the codex.

I'm thinking we should use the existing salts and keys (those in the current config, or in the database) when generating the MS config file. We also have secret_salt_warning() that we can then use to get them to update their salts and keys further. I'm going to work that into the WPFS patch and see how it works.

Another option might be to clear cookies on network install, forcing them to get the new cookies on login and preventing a lockout. Otherwise the support forums will flood with every Tools > Network upgrade. And for good reason -- we really need to fix this.

I will play with these options and report back.

[dd32]

And for good reason -- we really need to fix this.

Agreed.

However, Whilst it sounds like the cookies are causing the issue here, Theres other code somewhere in MS which is redirecting improperly, it should be redirecting to the login form, where as currently, its not.

But yes, Use the existing salts+keys if they're defined (ie. not 'isnert key here') else generate a new set perhaps?

[automattor]

(In [13127]) use current site domain for cookie domain when cookie domain not set, See #12142

[wpmuguru]

Replying to nacin:

Replying to wpmuguru:

I'm thinking we should use the existing salts and keys (those in the current config, or in the database) when generating the MS config file. We also have secret_salt_warning() that we can then use to get them to update their salts and keys further. I'm going to work that into the WPFS patch and see how it works.

It does use the existing ones that are there. It adds any SALT/KEY that is missing to the generated wp-config.php. When this was happening with MU, the affected site admins were getting the SALT/KEY warnings and adding the recommended constants to their wp-config files.

Removing the constants from the generated file and showing the warnings when the admin turns on the network functionality will not resolve the issue.

[Raptor235]

Just a note on this bug.. I'm running on OS X, and I'm experiencing the same thing in FF... I can't login to any other network sites I've created but can login to the main parent site.

[kpdesign]

I experienced this issue after converting 3.0-alpha single to multisite yesterday.

Once the conversion was complete, I was unable to log in using Firefox 3.5.8 ("site is redirecting in a way that will never complete"). I opened another browser (Chrome) and could log in without issue. Once I closed Firefox and reopened it, I was able to log in again.

[nacin]

See also #11764 and #12616 as it relates to secret_salt_warning().

Upping priority and severity. This is probably the one remaining thing we need to get at before beta.

[wpmuguru]

Has anyone found a way to reliably (or even semi-reliably) reproducing the problem?

[nacin]

Here's one scenario:

• Install WP, but don't have all 8 keys and salts.
• Do Tools > Network upgrade.
• Add any missing key or salt.
• You won't be able to log in.

I've seen two different results in general. In one case, it goes into a redirect loop, which is what dd32 referred to above. In the other case I've noticed, it simply takes you back to the login form. I'm not sure how to reproduce each case specifically as I haven't tested this much.

I haven't been able to walk through the load process and watch this occur, but I should be able to devote some time later to it.

[wpmuguru]

Replying to nacin:

Here's one scenario:

• Install WP, but don't have all 8 keys and salts.
• Do Tools > Network upgrade.
• Add any missing key or salt.
• You won't be able to log in.

I removed all of them & installed network. I did get the rewrite loop, but closing the browser and restarting allowed me to log in.

One way we probably could reduce the frequency of this is switch the salts/keys to alphanumeric characters only.

[wpmuguru]

(In [13760]) force users to re-login after installing network, see #12142

[wpmuguru]

That will only have an effect if existing network tables are dropped.

[wpmuguru]

Closing this pending new reports of the issue.

[nacin]

I've closed a few duplicate tickets of this issue and seen a few emails about it.

Some people are adding in the new defines when prompted, either in network.php or due to the nag, and then they find they can't log in, so they remove it, and their install is lacking the newer salts and keys.

This needs to be handled properly. [13760] should be replaced with wp_logout() or wp_clear_auth_cookie(), and we need to investigate whether A) there is a looping issue with MS, and B) we can invalidate cookies if we can detect new keys.

[delayedinsanity]

This is still occurring.

Fresh install of revision 14078, Apache 2.2.11, PHP 5.3.0, MySQL 5.1.36

Clean database, installed and defined WP_ALLOW_MULTISITE, logged in and activated via Network (tried both sub-directory and sub-domain to narrow it down, but neither worked). Salts are all there, added required content to wp-config.php and .htaccess with no other modifications to installation.

I can get to the dashboard in Safari, but not in FireFox or Chrome. I've cleared the cache, cookies, everything in FF, and still not able to log in. When I tried in Chrome it was off a fresh install of Chrome with no visits made to any other sites so there wasn't even a cache to clear.

Real pain in the butt for trying to develop locally, having to run two browsers with one on the dashboard and the other viewing the front end (can't stand safari's tabs behavior on Windows 7... but that's unrelated).

[nacin]

Did you define the constants before or after you installed WP (not MS, just WP)?

What's the host name you're using? (i.e. localhost.localdomain) Are you running WP in a subdirectory? (i.e. localhost.localdomain/wp30)

If you remove the salt definitions (perhaps even one by one), do things start to work?

Can you compare the cookie values, paths and domains?

Is it simply returning you to wp-login.php, or is it putting you in a redirect loop?

Anything else you can provide...

[delayedinsanity]

Order of events:

Checked out 3.0 from SVN
Install on a fresh database
Logged into dashboard for first time
Added WP_ALLOW_MULTISITE to wp-config.php
Visited Network under Tools menu and activated
Added defines to wp-config.php
created .htaccess >> can't log back in.

Nothing else, didn't enable permalinks, didn't configure user account or anything prior to turning on MultiSite.

I'm running this under two seperate local hosts, 'sandbox.loc', and 'wordpress.net' (it just redirects to .org anyways... :D ).

Hey wait... when I changed the domain from sandbox.loc to workdamnit.loc I can log in.

FF was simply returning me to wp-login.php - Safari was putting me into a redirect loop.

I'll try another fresh install to see if removing the salts will help, since changing my domain names isn't something I really want to rely on. :) Will report back when I'm done.

[delayedinsanity]

Oops. I should have known better than to use >> as my bullet for the above list. Sorry about the formatting screw up.

[nacin]

I just spent a solid hour trying to reproduce this. No dice. New steps to reproduce would be helpful.

[ipstenu]

I saw this once when I was running a 'non standard' blog as my main site blog (that is the blog with the ID 3 is my main blog). I couldn't log in, couldn't get to the admin side, but the blog itself was fine, and I could get to other MS blogs on the same install!

Changing these lines in wp-config.php fixed it for me:

define('SITE_ID_CURRENT_SITE', 3);
define('BLOGID_CURRENT_SITE', '3' );

[wpmuguru]

(In [14380]) only use domain cookies in a subdomain install, see #12142

[wpmuguru]

(In [14386]) allow subdir multisite on ip address, see #12142

[andrea_r]

Replying to wpmuguru:

(In [14380]) only use domain cookies in a subdomain install, see #12142

I'm being forced to login again when moving between the sites. Checking in my browser, it seems to set two different cookies.

[nacin]

Replying to andrea_r:

I'm being forced to login again when moving between the sites. Checking in my browser, it seems to set two different cookies.

What are the names, values, domains and paths of the two types of cookies? I'd imagine the domain on one is like "trunk.local" while the other is ".trunk.local," and that it's a subdomain install?

[wpmuguru]

(In [14458]) use same salts/keys across network, see #12142

[nabha]

We had this installed in a local dev site, ​http://anandadev-local -- after enabled multisite, I couldn't login. Clearing cookies, trying different browsers, etc. didn't fix it.

What has fixed it, at least for now, is changing the site to ​http://www.anandadev-local.org/ (a non-existent domain). We're using IIS 6 with Windows Server 2003.

[nabha]

Replying to nabha:

We had this installed in a local dev site, ​http://anandadev-local -- after enabled multisite, I couldn't login. Clearing cookies, trying different browsers, etc. didn't fix it.

What has fixed it, at least for now, is changing the site to ​http://www.anandadev-local.org/ (a non-existent domain). We're using IIS 6 with Windows Server 2003.

Update: This was with 3.0 beta 1 (didn't know the appropriate Trac protocol). I upgraded to the latest nightly and had the same problem before starting afresh. Things are working okay now with ​http://www.anandadev-local.org/.

[ryan]

Force reauth if cookie validation fails in auth_redirect()

[ryan]

Patch does the following:

• Add reauth=1 flag to login url when auth_redirect() redirects to wp-login.php after the auth cookie fails validation
• wp-login.php clears cookies and forces log in if reauth=1.
• If reauth=1 wp-login.php does not attempt to redirect to wp-admin, even if the cookie seems good.

Basically, this forces reauth/login whenever auth_redirect() does not think the user is logged in. This should resolve the situation where one cookie seems good but another does not.

[ryan]

(In [14556]) Force reauth when auth_redirect() redirects to login. see #12142

[nacin]

I think on reauth we need to clear both domain and host cookies to avoid single->multi constants.

[wpmuguru]

Single and multi do not use the same cookies. The cookie name has a suffix of a md5 of the siteurl in single and the siteurl + '/' in multi. Clearing cookies with whatever the current setting is will be sufficient.

[nacin]

Good call, forgot about that. I've always been confused by siteurl + '/' though. Shouldn't that be sans-slash, and what are we breaking by storing the slash in sitemeta yet not in blog options?

[wpmuguru]

Replying to nacin:

Good call, forgot about that. I've always been confused by siteurl + '/' though. Shouldn't that be sans-slash, and what are we breaking by storing the slash in sitemeta yet not in blog options?

What we should do in 3.1 is move the cookie name hash generation away from using the siteurl option. The only reason the meta_key is siteurl is so that get_site_option can be used in both single & network to retrieve the seed for the cookie name hash. That's the only use of that sitemeta value.

I could have done something different in [13760], but I did that a few days before one of the earlier beta target dates and was trying to do the minimal change possible. Kicking myself now.

[wpmuguru]

related #13504

[nacin]

Well, we'll see more issues once RC is out the door if we haven't done enough here.

Resolving as fixed.

[darfuria]

Just done a fresh install of RC2 and I get this issue.

[ryan]

At this point, I think we just have to document it and live with it for 3.0.

[michaelh]

​http://codex.wordpress.org/Tools_Network_SubPanel#Troubleshooting

I'll let someone else close this.

[sareiodata]

I have the same issue with WP 3.0 final.

Tried a fresh installation with sub-directories.

From the entire discussion I really can't tell how to go around the problem.

[nacin]

Please visit the Multisite support forum, ​http://wordpress.org/support/forum/14. You'll need to clear your cookies, cache, etc.

[sareiodata]

Ok. So this is fixed in the latest trunk version but never made it to 3.0

My bad.