WordPress.org

Make WordPress Core

Opened 10 years ago

Closed 9 years ago

Last modified 6 years ago

#12142 closed defect (bug) (fixed)

cant access admin in ms install

Reported by: usermrpapa Owned by:
Milestone: 3.0 Priority: normal
Severity: normal Version: 3.0
Component: Multisite Keywords:
Focuses: Cc:
PR Number:

Description

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...

Attachments (1)

12142.diff (3.0 KB) - added by ryan 10 years ago.
Force reauth if cookie validation fails in auth_redirect()

Download all attachments as: .zip

Change History (51)

#1 @nacin
10 years ago

  • Milestone changed from Unassigned to 3.0

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.

#2 @usermrpapa
10 years ago

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.

#3 follow-up: @wpmuguru
10 years ago

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.

#4 @usermrpapa
10 years ago

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.

#5 in reply to: ↑ 3 ; follow-up: @nacin
10 years ago

  • Severity changed from normal to major

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.

#6 @dd32
10 years ago

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?

#7 @automattor
10 years ago

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

#8 in reply to: ↑ 5 @wpmuguru
10 years ago

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.

#9 @Raptor235
10 years ago

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.

#10 @kpdesign
10 years ago

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.

#11 @nacin
10 years ago

  • Priority changed from normal to high
  • Severity changed from major to critical

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.

#12 @wpmuguru
10 years ago

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

#13 follow-up: @nacin
10 years ago

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.

#14 in reply to: ↑ 13 @wpmuguru
10 years ago

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.

#15 @wpmuguru
10 years ago

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

#16 @wpmuguru
10 years ago

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

#17 @wpmuguru
10 years ago

  • Resolution set to fixed
  • Status changed from new to closed

Closing this pending new reports of the issue.

#18 @nacin
10 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

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.

#19 @delayedinsanity
10 years ago

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).

#20 @nacin
10 years ago

  • Priority changed from high to highest omg bbq
  • Severity changed from critical to blocker

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...

#21 @delayedinsanity
10 years ago

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.

#22 @delayedinsanity
10 years ago

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

#23 @westi
10 years ago

  • Cc westi added

#24 @nacin
10 years ago

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

#25 @ipstenu
10 years ago

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' );

#26 follow-up: @wpmuguru
10 years ago

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

#27 @wpmuguru
10 years ago

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

#28 in reply to: ↑ 26 ; follow-up: @andrea_r
10 years ago

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.

#29 in reply to: ↑ 28 @nacin
10 years ago

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?

#30 @wpmuguru
10 years ago

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

#31 follow-up: @nabha
10 years ago

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.

#32 in reply to: ↑ 31 @nabha
10 years ago

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
10 years ago

Force reauth if cookie validation fails in auth_redirect()

#33 @ryan
10 years ago

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.

#34 @ryan
10 years ago

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

#35 @nacin
10 years ago

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

#36 @wpmuguru
10 years ago

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.

#37 follow-up: @nacin
10 years ago

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?

#38 in reply to: ↑ 37 @wpmuguru
10 years ago

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.

#40 @nacin
10 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

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

Resolving as fixed.

#41 @darfuria
10 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

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

#42 @ryan
10 years ago

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

#43 @wpmuguru
10 years ago

  • Keywords needs-codex added

#44 @wpmuguru
10 years ago

  • Priority changed from highest omg bbq to normal
  • Severity changed from blocker to normal

#45 @michaelh
10 years ago

  • Keywords needs-codex removed

#46 @nacin
10 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

#47 @sareiodata
9 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened
  • Version set to 3.0

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.

#48 @nacin
9 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

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

#49 @sareiodata
9 years ago

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

My bad.

This ticket was mentioned in IRC in #wordpress-dev by ddebernardy. View the logs.


6 years ago

Note: See TracTickets for help on using tickets.