Page MenuHomeMiraheze

Logging in on custom domain fails to properly set centralauth cookies
Closed, ResolvedPublic

Description

Earlier today, I attempted to login as Voidwalker on testwiki (publictestwiki.com), but encountered an interesting error: the centralauth session cookies never got set, no matter how many times I tried to login. Furthermore, attempting to login on meta would either cause "No active login attempt is in progress for your session." or result in the same issue as testwiki. Attempting to clear cookies in the browser had no effect, as did changing browsers entirely. Eventually, by logging in, and immediately clicking logout, I was able to clear all session data, and was then able to properly initiate a login on meta that worked.

Further experimenting with the issue resulted in being able to login on testwiki, but all other wikis not saving login cookies. I attempted loginwiki, and that only resulted in the "fake" login (that immediately loses the cookie). All attempts to login on meta resulted in "No active login" errors. Attempting to clear all browser cookies had no effect, except to deprive me access to testwiki (which had, until then, been keeping me logged in). This also appears to have made the "No active login" issue propagate to loginwiki. In this case, attempting to logout on testwiki failed to fix the issue.

Event Timeline

Void triaged this task as High priority.Jun 4 2018, 02:30
Void created this task.
Paladox added a subscriber: John.
Paladox added a subscriber: Paladox.
MacFan4000 raised the priority of this task from High to Unbreak Now!.Jun 4 2018, 11:43

UBN as this can affect site usability.

Just going to log here that I can't reproduce the problem as described.

Void lowered the priority of this task from Unbreak Now! to High.EditedJun 4 2018, 19:18

Can neither confirm fix, nor original circumstances. In this case, logging in to Meta, logging out, and then logging in failed.

I cannot seem to remain logged in as Voidwalker

@Void clean your cookies?

though im guessing this is redis since centralauth requires shared cache https://www.mediawiki.org/wiki/Extension:CentralAuth#Cache_issues

@Void did you go back to main page after seeing "No active login attempt is in progress for your session."? If no then doing that should fix it :)

Hmm, @Paladox I think I just got auto-logged-in on testwiki. Will need to confirm.

I still cannot seem to login as Voidwalker. After enough fiddling, the login seems stable

I've opened up my cookies to try and take a look at what's going on, and here's my best guess:

Intended behavior (as seen on successful login to account Void):
Sets a minimum of ten cookies.

  • Three under login.miraheze.org
    • loginwikiUserID
    • loginwikiUserName
    • loginwiki_session
  • Three under meta.miraheze.org
    • metawikiUserID
    • metawikiUserName
    • metawiki_session
    • (There are others, but I believe they are irrelevant)
  • Four under .miraheze.org
    • centralauth_Session
    • centralauth_Token
    • centralauth_User
    • forceHTTPS (irrelevant)

Failed behavior (as seen on broken login for Voidwalker):

  • login.miraheze.org
    • loginwikiUserID
    • loginwikiUserName
    • loginwiki_session
  • meta.miraheze.org
    • loginnotify_prevlogins
    • metawikiUserName

A temporary login also generates:

  • meta.miraheze.org
    • UseCDNCache
    • UseDC

But those temporary cookies last less than a minute, and when they expire, so does the session.

As a note, some of the testing above may have been influenced by not selecting the "Keep me logged in" option.

And, once again, I'm not getting any centralauth cookies. I've cleared everything, I've gone back to the previous page.... I don't know what to do. I've even got "No login attempt ..." immediately after clearing cookies. The few times I get in, I'm immediately logged out whenever I go to a new page or refresh the current one. Clicking logout doesn't help.

@Void would changing your password invalidate the session?

Possibly, I'm going to try it. As a note, I checked with T168858 (upstream) and discovered that it was setting the same headers.

Just logging here to say that attempting to change password failed.

Also to log, it was possible to login via API, and then log back out. This made the account accessible through the web interface, and furthermore, updated the password to its new value.

Users on the miraheze channel are reporting problem.

@Void could you pass the command you used to use the api please? I guess that is a fix for now invalidates the session thus can login.

FYI, I got the same issue on my main account when freshly attempting a login on testwiki. It was resolved by clearing the publictestwiki.com specific cookies and refreshing the page. Then I was logged in automatically. (I had already logged in on meta).

It would not be easy to provide a single command for other users to use, as I used a part of the Void-bot framework.

MacFan4000 raised the priority of this task from High to Unbreak Now!.Jun 5 2018, 18:52
MacFan4000 added a subscriber: Fastpager200.

This has to be fixed ASAP

There are two issues here, that are completely separate. One is the auto-logout, the other is not being able to directly login on custom domains (which seems to have passed).

I must recommend that all users login first on metawiki or loginwiki before attempting to login on any custom domain.

Next, and perhaps more serious, the fix I attempted by using the API no longer seems to achieve anything.

Possibly related, visiting wiki1776.miraheze.org and union.miraheze.org clears login cookies for an undetermined reason. It does not seem to trigger any other issues.

Actually, visiting any private wiki seems to have the same results.

Edit: Does not seem to apply to certain staff wikis.

Edit 2: Can no longer replicate.

I can reproduce this issue as soon as i ran resetGlobalUserTokens.php on test1wiki.

This is spreading now, once the user_token has expired users will start to experence this on there wiki.

Login is now broken for me on all wiki's.

We have fixed this now, was a stupid change done by me when i was hacking to get importDump to work without redis due to redis OOM frequently.

Anyways fixed it now!

Paladox lowered the priority of this task from Unbreak Now! to High.Jun 5 2018, 22:36
Paladox claimed this task.

I note this task was closed and marked as resolved. However, we found we were still having problems logging into our private wiki: https://pwiki.arkcls.com. We would get the following message:

There seems to be a problem with your login session; this action has been canceled as a precaution against session hijacking. Go back to the previous page, reload that page and then try again.

If our users followed the instructions in the message above then they still get the same problem.

However, we have managed to resolve the problem in the following manner:

  1. From within a browser delete all cookies relating to the private wiki: (pwiki.arkcls.com in our case)
  2. Then go to private wiki home page. You will be now prompted to accept cookies before you can continue using your miraheze private wiki.
  3. Now click the login link and login with the users credentials in the usual manner
  4. It should all work now

Hope this is some help.

Yes, we knew about that