Page MenuHomePhabricator

CentralAuth logs off on rename
Closed, DeclinedPublic

Description

When a user with SUL account Foo asks for a username rename, say the rename of local account Foo2 into Foo, CentralAuth logs Foo off.


Version: unspecified
Severity: normal

Details

Reference
bz32077
TitleReferenceAuthorSource BranchDest Branch
Update function-schemata sub-module to HEAD (5f40813)repos/abstract-wiki/wikifunctions/function-evaluator!29jforrestersync-function-schematamain
Update function-schemata sub-module to HEAD (5f40813)repos/abstract-wiki/wikifunctions/wikilambda-cli!12jforrestersync-function-schematamain
Update function-schemata sub-module to HEAD (4927eba) (BREAKING - changes some test outputs)repos/abstract-wiki/wikifunctions/function-orchestrator!39apinesync-function-schematamain
Support degenerate quoted objects in the mixed validator, normalization, and canonicalization.repos/abstract-wiki/wikifunctions/function-schemata!22apineapine-norms-canonsmain
Customize query in GitLab

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 12:02 AM
bzimport set Reference to bz32077.
bzimport added a subscriber: Unknown Object (MLST).

I believe the username and id are stored in the cookies, so this is not possible to fix. It's hardly a big issue

A user renaming someone else to his own name? That isn't allowed. I think you
used too much Foos :)
Try adding some Bar.

Why would username and/or ID change for a SUL account when a non SUL username is moved into a SUL username?

It is certainly mildly irritating, hardly a major issue but never the less it is a bug.

Username renames are allowed for SUL usernames.

Just to point out the rename logs off on all wikis not just the wiki user was renamed on.

A user seeking a SUL rename would have a constant case of this as b'crats on individual wikis will not be renaming all at the same time.

The log off does not happen to the previous SUL account.

This really causes people to make IP edits. I do not see how cookies are relevant to be honest.

There's no way they open the editor logged in and save as IP. They would get a message about loss of session data, or open the editor already logged out.
Albeit admitedly that's easy to skip.

This is what happens. You are making edits normally. One second you are logged in, the other you are logged out because of renames of accounts on an unrelated wiki.

The renamed account isn't part of the SUL of the editing account so I really do not see why a rename in Spanish wikipedia affects a user editing Japanese wikisource.

So the problem is that when unattached account Foo is renamed into Bar, the SUL account Foo is logged out?

No. When an account from Foo is renamed into Bar, the user of the SUL Bar account is logged out. So the rename target is logged out.

In my case both Foo and Bar are my own SUL accounts. During the transition I got logged off at my Bar account every time a SUL Foo account was detached and renamed to Bar.

I suspect the problem would happen even if an unrelated account is renamed to Bar.

This behaviour could be a feature, not a bug. It happens that accounts are renamed and then recreated under the wrong name by automatic account creation, maybe logging out is useful?

How is it useful? It ONLY makes people make IP edits mid-edit! You are logged in when you click the edit button, and then you are logged off by the time you click save unless you make sure you are logged in.

A notification is present in preferences if user pays attention to global accounts and that is only if user expects the account rename. If user didn't even make the request it only appears like a random log off.

The logged out account and the renamed account has no relation aside from sharing the name. Any bureaucrat or steward can log-off a user by renaming an account on a wiki they never had edits.

This is particularly bad for those who want a SUL rename with multiple requests on multiple wikis. B'crats do not rename accounts all at once. You will be forced to log back in possibly multiple times an hour.

MarcoAurelio raised the priority of this task from Medium to High.May 5 2015, 6:14 PM
MarcoAurelio moved this task from Backlog to Done on the MediaWiki-extensions-CentralAuth board.