Login to Wikidata Fails

jdnicholas commented 3 years ago

Edit

Trying on a different computer allowed me to log in fine, so perhaps may be an issue with some setting on my computer rather than with the plugin. The issue was occuring on my Mac, but there was no issue when I tried on a different windows pc.

Previous

Attempting to login to Wikidata in the pop up window that appears when choosing to sync with Wikidata fails with the message:

"Error: Wrong username or password. Try again."

I have tried both my normal username and password, as well as a created Bot Password, but neither options work.

Leaving the fields blank does sync and update Wikidata as an anonymous edit.

jdnicholas commented 3 years ago

Restarted my Mac and tried again and all worked with no issues - presumably just an issue on my end, sorry

diegodlh commented 3 years ago

Hi, @jdnicholas! Thank you very much for taking the time in reporting this! I understand this is no longer happening, but let's keep an eye on it in case it happens again. In that case, I can show you how to get debug logs that may help me reproduce and fix the issue.

Thanks again!

diegodlh commented 3 years ago

Reopening as a user reports (by email) that they are having trouble to log in to Wikidata using Cita.

They say that they created a new Wikidata item for a cited item without QID, but when they tried to create a new Wikidata item for a second cited item without QID, it failed as if their credentials were rejected.

They say that the workaround they found was to restart Zotero between creation of new Wikidata items.

I haven't had the time to confirm this bug yet.

Possibly should be solved with #46.

diegodlh commented 3 years ago

This bug should not be confused with #107. There, the user might think there was an error logging in because the error would appear right after the login dialog has been closed.

In this bug, instead, the user should be caught in a login-error loop, where the login dialog keeps appearing.

diegodlh commented 3 years ago

This happened to me today. Couldn't debug in detail because I had to restart Zotero and the problem was gone, as reported above; and I don't know yet how to reproduce it.

Apparently, the API's login endpoint is responding with an error that login session has expired, but this error seems to be interpreted by wikibase-edit as "invalid username/password".

Again, this should be fixed when using OAuth for login instead (#46).

diegodlh commented 3 years ago

To log in, wikibase-edit calls the Wikidata API's with action=login twice:

First, with username and password only, to get login cookies and a login token (BTW, the API complains that fetching token via "action=login" is deprecated; this should be fixed in wikibase-edit);
Second, with username, password and the login token from the response above, to get session cookies.

The problem described in this issue seems to be in the second request:

In a working request, the second request includes the login cookies from the response to the first request;
In a non-working request, the second request includes no cookies.

These login cookies would presumably get into the second request by either of these:

via the cookies string, parsed by wikibase-edit parseLoginCookies function;
they would get added by the Firefox engine.

I can force this error by doing both of these in wikibase-edit's getSessionCookies function, right before the headersWithCookies object is created:

clear the cookies string (i.e., cookies = ''); and
reset the cookies for "www.wikidata.org", just like it is done by Cita's resetCookies function.

If only one of these two is done, the (forced) error does not occur.

Given that I still couldn't find a way to naturally reproduce this bug, there are some open questions:

Confirm that, when the bug occurs, no cookies are available within the getSessionCookies function, neither in the cookies string, nor in the "cookies" service (i.e., Services.cookies.getCookiesFromHost(new URL('https://www.wikidata.org').host, {}).hasMoreElements() is false)
If yes, why is this? Is it because the first request responds with no cookies (unlikely)? Or is it because the Firefox engine can't read the cookies in this response, for some reason?

diegodlh commented 3 years ago

Confirm that, when the bug occurs, no cookies are available within the getSessionCookies function, neither in the cookies string, nor in the "cookies" service (i.e., Services.cookies.getCookiesFromHost(new URL('https://www.wikidata.org').host, {}).hasMoreElements() is false)

cookies = null Services.cookies.getCookiesFromHost(new URL('https://www.wikidata.org').host, {}).hasMoreElements() = false

If yes, why is this? Is it because the first request responds with no cookies (unlikely)? Or is it because the Firefox engine can't read the cookies in this response, for some reason?

The first request does respond with cookies. res.headers.get('set-cookie') = null in parseLoginCookies

diegodlh commented 3 years ago

When the bug occurs, these lines are printed to the debug output:

CookieSandbox: Being paranoid about channel for www.wikidata.org
CookieSandbox: Cleared cookies to be sent to www.wikidata.org
Being paranoid about channel for www.wikidata.org
Not tracking received cookies for www.wikidata.org

Conversely, a CookieSandbox: Managing cookies for www.wikidata.org message does not appear on successful log-ins.

Hence, this issue seems to occur when the Zotero Cookie Sandbox gets involved (for some yet unknown reason) in wikibase-edit login HTTP requests.

sstraume97 commented 1 year ago

Looks like I'm having a similar problem with login.

I get the same error with the default username and password, as well as "app password".

Has restarted the PC, but it doesn't help.

diegodlh / zotero-cita

Login to Wikidata Fails #70