Page MenuHomePhabricator

[Bug] Login issue with add language links widget
Closed, ResolvedPublic

Description

"Whenever I try to add an interwiki link by following the "Add link" link in the "Languages" section, the following error message pops up: "You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature." However, if I visit Wikidata it seems I am already logged in there with my global login. This problem occurs not just with English Wikipedia but with other Wikipedias. Is this a known issue? Regardless, this error message is supremely unhelpful; it doesn't provide any indication as to what the "central data repository" is or how to log in there. —Psychonaut (talk) 17:43, 11 May 2013 (UTC)"

(Reported at http://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#.22You_need_to_be_logged_in.22_error_when_trying_to_add_interwiki_links)

See Also:
T68521: Link for adding interwiki does not work on Swedish Wikipedia

Event Timeline

bzimport raised the priority of this task from to High.Nov 22 2014, 1:30 AM
bzimport set Reference to bz48389.
bzimport added a subscriber: Unknown Object (MLST).

Related URL: https://gerrit.wikimedia.org/r/63393 (Gerrit Change Iae53b39dd20342f5719fd5c67d2891284f1b39bf)

psychonaut wrote:

I experience this problem with Mozilla/5.0 (X11; Linux x86_64; rv:20.0) Gecko/20100101 Firefox/20.0 SeaMonkey/2.17. I have a few add-ons installed but will try again with them removed and post the results.

psychonaut wrote:

The problem also occurs in safe mode (i.e., with all add-ons disabled). It occurs when I'm logged into and accesing Wikipedia via either HTTP or HTTPS. However, some further experimentation shows that the error message is triggered only sometimes. Other times following the "Add link" gives me the "Link with page" popup as expected.

(In reply to comment #2)

I experience this problem with Mozilla/5.0 (X11; Linux x86_64; rv:20.0)
Gecko/20100101 Firefox/20.0 SeaMonkey/2.17. I have a few add-ons installed
but
will try again with them removed and post the results.

Then the above patch probably wont solve (or moreover avoid) the mentioned problem. I can't reproduce this problem with neither Firefox 20 nor Seamonkey 2.17 on Fedora.

The only possible cause I can think of right now is that you are logged in via https on Wikidata.org while only being logged in via http on enwiki for some reason (different non-global accounts maybe?).

Tristan: Can you answer Marius' last question please?

psychonaut wrote:

No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem:

0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata.

  1. I visit https://en.wikipedia.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in.
  1. I enter my username and password and click on "Log in". I get logged in and redirected to the main page.
  1. I visit https://en.wikipedia.org/wiki/Smriti_Irani or any other article which doesn't have any interwiki links.
  1. I click on "Add links" in the "Languages" section of the left bar. A dialog appears which says "You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature".
  1. I click on "central data repository" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in.
  1. I enter my username and password and click on "Log in". I get logged in and redirected to the main page.
  1. I visit https://en.wikipedia.org/wiki/Smriti_Irani again and click on "Add links" in the "Languages" section of the left bar. A dialog appears which says "You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature".
  1. I click on "central data repository" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. This time according to the top of the page I am already logged in.

So it seems that the "Add links" function *always* tells me I am not logged in, whether or not I really am logged in.

(In reply to comment #6)

So it seems that the "Add links" function *always* tells me I am not logged
in,
whether or not I really am logged in.

Do you have any uncommon settings regarding cookies? In theory you shouldn't even have to do 5). The fact that you also have to manually log in on wikidata seems strange to me and it would be great to get more details about what exactly is going on here.

@Lydia: Do we often get such reports (how big is the impact of this)?

CCed Chris Steipp because of the SUL login issues mentioned above (point 5).

There are a few reports - definitely enough to make me think something is very fishy here.

This can certainly happen if the user has 3rd-party cookies disabled. In that case, they won't be logged into any of the other projects when the login. Since they're not logged into wikidata when they visit wikidata directly, that does sounds like they're not being logged in properly. It will be hard to track down without capturing the headers when they visit the site though.

You might be able to fix this feature by using a centralauth token from the local wiki, before making the call to wikidata.

psychonaut wrote:

Yes, I've got third-party cookies disabled, though I'd hardly call this an "unusual" configuration. It's useful and common enough that Mozilla is considering making it the default setting for its browsers. If accepting third-party cookies is required to add interwiki links now, then if/when Mozilla makes the switch, it's going to stop working for some 20% of all Wikimedia users.

In the meantime, if third-party cookies are required, please update the "You need to be logged in" message to say so.

The "real" solution for this would be OAuth, right?

(In reply to comment #11)

The "real" solution for this would be OAuth, right?

No. OAuth could be a solution for third party client wikis, but not for Wikimedia ones (we have CentralAuth for this purpose).

The issue over here essentially comes down to a CentralAuth shortcoming (see my mail).

For me it seems fine now.
Is there anything else we can do on this bug?

psychonaut wrote:

I'm still experiencing the problem. If it's been established definitively that this is due to the user's browser blocking third-party cookies, could a message to this effect please be added to the error message?

hoo added a subscriber: adrianheine.
Lydia_Pintscher removed a subscriber: Unknown Object (MLST).

It still doesn't work for me.
To be clear about: It worked perfectly before (about 8 weeks ago), but since then it doesn't . What have you changed related to authentication since then?

It still doesn't work for me.
To be clear about: It worked perfectly before (about 8 weeks ago), but since then it doesn't . What have you changed related to authentication since then?

Nothing has changed on our side, the problem is that browsers keep changing and tend to get more restrictive regarding these things (third party cookies and things like that).

thanks hoo, but I'm using a rather old firefox and I did not update since months. But I use noscript, maybe that is the problem? It updates regularily. Any hint on noscript?

thanks hoo, but I'm using a rather old firefox and I did not update since months. But I use noscript, maybe that is the problem? It updates regularily. Any hint on noscript?

I don't have time to test this right now, but changing your noscript settings could help (quite likely, actually).

If it does, a reply about what you did would be nice, so that others can see what to do.

Disabled noscript, but this does not make a change. Even then, the ''Add link'' does not consider me to be logged in to WD.

I'm getting this problem, too. I'm also using Firefox (latest version) with third-party cookies disabled. It might be nice to have a help page about this somewhere on Wikidata.

@Lydia_Pintscher or anyone else who might know: Is this going to be fixed?

It can't be SUL problems, because SUL finalization is done. It can't be HTTP vs HTTPS, because everything is forced to HTTPS.

If the problem is not accepting third-party cookies, then the message needs to say that (or the software needs to be changed to not need cookies).

In the meantime, maybe someone would like to add [[w:ht:Lafyèv jòn]] to the list of articles about yellow fever.

thiemowmde renamed this task from login issue with add language links widget to [Bug] Login issue with add language links widget.Aug 13 2015, 3:26 PM
thiemowmde moved this task from incoming to needs discussion or investigation on the Wikidata board.
thiemowmde removed subscribers: Wikidata-bugs, Abraham.

AIUI, T66636: Upstream ForeignAPI code in MobileFrontend into core/CentralAuth will allow Wikibase to use centralauthtoken without depending upon CentralAuth explicitly (core takes care of the dependency internally) and centralauthtoken should bypass any cookie issues.

Yeah, this should be easy to fix now for someone who knows Wikibase's code. I tried, but I couldn't find where the Wikibase API code comes from.

I'm getting this problem, too - since a couple of days? I'm also using Firefox (latest version).
What can I do?
Greetings
hdamm

I'm getting this problem, too - since a couple of days? I'm also using Firefox (latest version).
What can I do?
Greetings
hdamm

BTW - when I get that error message, I click on the link to log in to WikiData, where I get the "Welcome to Wikidata" message. Then I go back within the same tab(!) in Firefox, and reload it. That's when I get the same error message, again.
Maybe that helps?
Greetimgs
hdamm

Change 238469 had a related patch set uploaded (by Hoo man):
Use mw.ForeignApi in getLocationAgnosticMwApi

https://gerrit.wikimedia.org/r/238469

Change 238469 merged by jenkins-bot:
Use mw.ForeignApi in getLocationAgnosticMwApi

https://gerrit.wikimedia.org/r/238469

hoo removed a project: Patch-For-Review.
hoo moved this task from Review to Done on the Wikidata-Sprint-2015-09-29 board.

Given this didn't make it into the branch this week, this is probably not going to be deployed to the Wikipedias before October 15.