Help talk:Unified login/Archives/2022

can't log in to WP-ii

Hi. Don't know where to ask about this: I can't log in to ii-wikipedia. Are they not part of the unified login? They don't show up in my global acct, but there've been other wikis that didn't show up there until after I made an edit. (Please ping.) Kwamikagami (talk) 07:43, 26 January 2022 (UTC)

@Kwamikagami: You mean w:ii:? It was closed in 2007. NguoiDungKhongDinhDanh 07:52, 26 January 2022 (UTC)

That would explain it! Thanks. Should Wikidata still link to its articles? Kwamikagami (talk) 07:54, 26 January 2022 (UTC)

@Kwamikagami: Its content was moved to Incubator (see incubator:Wp/ii) so probably no. NguoiDungKhongDinhDanh 07:57, 26 January 2022 (UTC)
Okay, I'll delink from 'Moon'. Kwamikagami (talk) 07:58, 26 January 2022 (UTC)

old announcements

Following points were on the help page, though are so old as to not be relevant to current help

and other old components


Tasks

Discussions

History

Early discussions can be seen on the Single login page.

Brion Vibber discussed how this might work in the December 2005 Berlin roundup, uploaded implementation notes to the code base in April 2006, and it was the subject of a presentation at Wikimania 2006.

Brion announced a successful migration test in November 2006. Data collection took two hours and automatic merging took five hours. 4,457,075 primary accounts were confirmed, with 578,128 secondary accounts merged automatically based on matching email addresses or by cannibalizing unused accounts. 134,242 secondary accounts will need to be merged with user interaction (71,741 unique user names have accounts left unmerged).

Unified login was implemented for administrators only in March 2008, and Steward requests/SUL requests (now a redirect to SRUC) was created to resolve conflicts in unified logins. Unified login was enabled for all users on May 27, 2008 on an opt-in basis. On August 22, 2008, CentralAuth was set to make a global account for all users registered after this date. The change removed the need for manual merging of accounts.

On 30 April 2013, the Wikimedia Foundation announced that the unified login system would be changing so that there would be only unique global accounts with the same username across all Wikimedia projects; there would be no two users sharing the same username on different wikis. With SUL finalization, all non-global accounts will be converted to global accounts where possible and if there is clash in the username, they will be renamed to have a "~" and the wiki name will be appended to the username. For example, an account with the username "Example" on the Dutch Wiktionary, which will be renamed, would become "Example~nlwiktionary". Initially, it was announced to take place in May 2013. However, this was delayed to August 2013, and in August 2013, this expectation was removed.

As part of this process, GlobalRenameUser function was introduced in July 2014 and the local rename user tool was removed from bureaucrats' toolset in September 2014.

The mass renaming process of users with conflicts in username started on 15 April 2015 and was finished by 22 April 2015. Since 15 July 2015, only users with unified global accounts are allowed to login on Wikimedia projects.

JavaScript required

For technical reasons related to HTTP cookies, Special:CentralLogin doesn't work without JavaScript, so I'm making note of it for future reference. RAN1 (talk) 20:38, 21 October 2022 (UTC)

logging into all accounts simultaneously?

" Special:UserLogin now logs the user in to every unified wiki simultaneously " doesn't work for me. I login at meta.wikimedia.org, then try en.wikipedia.org, but have to login again. And it doesn't seem to be a cookie problem because I stay logged in in meta.wikimedia.org. --Utonsal (talk) 23:34, 28 October 2022 (UTC)

@Utonsal: Each wikisister will set its own set of cookies, so meta is in wikisister "wikimedia.org" and enWP is on the "wikipedia.org", so most likely is a cookie issue if failing. Try to flick your browser to request permission, or check your settings and search for the cookie.  — billinghurst sDrewth 09:16, 29 October 2022 (UTC)

Wikidata: Not working + bad interaction design

Central login isn’t working for Wikidata, but to make things worse, it doesn’t warn you until after you have made your first edit, so unless you remember Wikidata requires a separate login, you are almost guaranteed to leak your IP by trying to connect a Wikipedia page.

Which is like even worse than not having central login, because if you don’t have central login you will remember to log in when you switch wikis.

Can this be either fixed (if technically possible), or at least have the warning appear before you edit (i.e., have the warning appear as soon as you hit Edit, as opposed to after you hit Publish). Thanks. Al12si (talk) 20:15, 20 November 2022 (UTC)

@Al12si: Wikidata is working fine for central login, please check that you have your cookies suitable enabled as that is usually the issue that we see. Do some good cache purging. With regard to a warning for IP editing, that already exists for the wikis in a traditional edit page (tested right now), so if you think that needs to be exist for WD's style of editing, that will need to be recommended to them specifically. Best to ask at d:Wikidata:Project chat.  — billinghurst sDrewth 22:27, 21 November 2022 (UTC)
@Billinghurst My cookies are fine (and the fact that only Wikidata is not working shows that cookies isn’t my problem). I also perpetually run in private mode so caches aren’t the problem — if anything this always happens after a browser restart which means a cache clear will actually cause the problem.
If anything it’d be the auto-block features that modern browsers use that’s blocking the cookies. This could be something that the designers of central login didn’t envision when the feature was designed a decade ago when privacy browsers didn’t exist. A solution would be to add instructions to the login screen to tell users what domains to whitelist. — Al12si (talk) 22:33, 21 November 2022 (UTC)
@Al12si: That it doesn't work for you is not an indication that it doesn't work; if it is working for others, then it is working, and there is something about a configuration, you may well have rejected cookies for WD, how can I tell? Wikidata is a different interface methodology, and not a traditional WMF wiki textbox, so you will need to talk to them about how they manage IP edits differently and for your proposed intervention. For technical design issues, where you have considerations about how you believe that some features of modern browsers may be interacting and you have identified what you consider a bug, then please create a bug report at phabricator:, a general statement here on this talk page of "It is not working for me, fix it" isn't going to resolve the issue.  — billinghurst sDrewth 22:45, 21 November 2022 (UTC)
PS: @Billinghurst: I suspect the problem with meta, mentioned in the question right above mine, is the exact same issue. Modern browsers automatically block cross-site cookies by default, that’s probably why not all accounts are logged in. This problem can only get worse as this kind of browser becomes more and more mainstream. Al12si (talk) 22:49, 21 November 2022 (UTC)
PPS: @Billinghurst Assuming our two issues are the same, that’s two people complaining about the same problem in less than a month. Most people wouldn’t even talk about it (if only for the fact that it’s extremely hard to even find this talk page); I’d say it’s not prudent to claim it’s “working for most people”. Al12si (talk) 22:54, 21 November 2022 (UTC)
@Al12si: there are so many users of WD and the sister WMFs, and essentially zero complaints on a daily basis, so I think that it is reasonable to say that it is working. This is not to say that there are not people having issues and this may continue to occur, however, these are bugs to be reported that contain all the information of the browser used, and the settings that users have in place. All of those issues need to be recorded as bugs in phabricator.  — billinghurst sDrewth 04:50, 22 November 2022 (UTC)
@Billinghurst As I mentioned, this talk page is extremely difficult to find. Took me literally four months to realize this talk page even exists. A lack of complaints does not mean a lack of problems when the channel for complaints is not perceivable.
The Phabricator ticket you ask for will eventually arrive — later after I test it on Opera GX and other modern browsers. But you cannot dismiss the problem if default browser behaviour is going to guarantee people can’t log on to every wiki.
I will unsubscribe from this thread since this isn’t going anywhere. I’ll suggest to my home wiki’s admins to remove the link to this talk page since this talk page isn’t helping people. — Al12si (talk) 06:15, 22 November 2022 (UTC)
@Al12si: This talk page talks about unified logins, in comparison to the previous situation of separate accounts on every wiki that were not connected, it is a page of its time. Me explaining all of that to you in detail will just be a waste of your time, and mine, trust me that I know. Your representation of this as being anything else is your misunderstanding its purpose.
This link Special:CentralAuth/Al12si clearly shows that unified login exists for you, you have a wikidata account. That is all it does, gives you all the accounts under your username, and no one else can have that exact username.
This page is not for the underlying aspects of how that is achieved on a daily basis as you navigate through wikis. It is inaccurate to state that the login system has been static since that occurrence. What you are bringing forward is a bug or a feature request, and both of those belong on phabricator. You can sit there and argue with me as much as you like, it doesn't change the advice on where to get your assistance. It is not here.  — billinghurst sDrewth 08:31, 22 November 2022 (UTC)
The fact that another person did exactly what I did shows that to users, this talk page is perceived to be the way to report problems before taking things to Phabricator.
Yes, I know unified login exists for me (otherwise why would I say login only doesn’t work on Wikidata?). That’s exactly the problem here. And I’ve seen that page you’ve shown me — that’s how I found out this talk page exists.
Please don’t trash users like this; a lot of things are very opaque here. If two users did exactly the same thing it’s a pattern. If this talk page isn’t supposed to be for bug reports (before escalating to Phabricator) then Wikimedia has a communication problem because from our POV we are told to come here, only to be told don’t come here.
PS: Please do not ping me; I have already unsubscribed from this thread thank you very much. — Al12si (talk) 08:43, 22 November 2022 (UTC)
The page is very specific on what it is. This page cannot control what other people say it is.

I didn't trash users, I have pointed you to where you can get help for the two issues that you raised, and said that this is not the place for the help that you seek. You seem to expect magic from another volunteer. <shrug>

I have added a message box to the top of this talk page "For current day issues with a login to Wikimedia, please log a bug report in phabricator:."
Even though it is not directly related to unified logins, I have added a question/answer that points people with these issues, where they persist, to phabricator.  — billinghurst sDrewth 06:58, 23 November 2022 (UTC)
@Billinghurst: Sending people to Phabricator is not productive, because it’s not what people are used to:
  • Different UI and workflow. Instead of just telling what the problem is, one has to hunt for project tags if one wants to have their issue noticed.
  • Much harder to find recent duplicates. On a talk page, even a newbie can be expected to scroll through previous topics to see if their problem has been discussed recently; on Phabricator, even I have problems finding tasks, with six years of experience.
  • Slower feedback cycle. New tasks are usually subscribed to by only a few people, so the reporter gets feedback more slowly than on a highly watched talk page.
  • Separate login. If people have issues even with normal SUL (they may not be able to log in at all), is it really a good idea to send them to a site where they have to create a new account, but that account needs access to their SUL account? (Or an LDAP account, but newbies will almost certainly have no LDAP account.)
Instead, people should be directed to Tech (and if there’s really a software bug/room for improvement, and no Phabricator task exists yet, experienced users watching that page can create it). I would’ve changed /Intro, but it has been fully protected without comment… Maybe you could unprotect it? —Tacsipacsi (talk) 22:43, 2 December 2022 (UTC)
Return to "Unified login/Archives/2022" page.