Login issue (Unknown error) Code=403

[Lineflyer]

Recently I started asking users on support to do this procedure when they report "Login failed: Unknown error" and confirmed to have checked all other things mentioned in the FAQ:

• Go to c:geo Menu - Settings - Service - geocaching.com
• Disable the service completely (disabling the tick box)
• Reboot device
• Go to c:geo Menu - Settings - Service - geocaching.com
• Enable the service again

In all cases users reported back, that it was now working normal (Login OK).

Can someone imagine any root cause in the c:geo code causing this.
I personally suspect problems in upgrade cases or data restore after reinstallation (Google backup)...IMHO this is somehow enabled in c:geo to store this data in Google.

[Lineflyer]

Link to #5693

[samueltardieu]

Cookies are stored in the preferences, and thus included in the automatic backup. Maybe we should store them in another file instead, that would not be backed up.

[samueltardieu]

A fix to do that is proposed in #6269 (against release). Merge if you think this is a good idea.

[Lineflyer]

Can you help me understand how storing the cookie locally can help in solving this issue?
As explained above the disable/enable of the connector solves the problem...so does this reset the cookie and therefore you imply, that it might get broken during google backup?

[Lineflyer]

In any case:
I am a little sceptic with all login related changes.
Therefore I suggest to put this to master only to allow more time for testing.

[Lineflyer]

Today while testing on a lot of devices I experienced the issue again:

• Basic member
• Login information was stored and valid
• Login failed on startup
• Went to Settings - Services and selected "Check Authentication"
• Result: Login failed "Unkown Error"

Log:

21:41:56.789 Debug cgeo 10479  [OkHttp] GET https://www.geocaching.com/account/login
21:41:58.099 Debug cgeo 10479  [OkHttp] 200 (1327 ms) GET https://www.geocaching.com/account/login (http/1.1)
21:41:58.539 Debug cgeo 10479  [OkHttp] POST https://www.geocaching.com/account/login
21:42:00.719 Debug cgeo 10479  [OkHttp] 403 [Forbidden] (2188 ms) POST https://www.geocaching.com/account/login (http/1.1)

• Reeintering username and/or password did not help.
• Deleting the information by long press on authentication menu and afterwards reentering username/password helped and login was OK.

21:46:32.743 Debug cgeo 10479  [OkHttp] GET https://www.geocaching.com/account/login
21:46:33.613 Debug cgeo 10479  [OkHttp] 200 (812 ms) GET https://www.geocaching.com/account/login (http/1.1)
21:46:33.833 Debug cgeo 10479  [OkHttp] POST https://www.geocaching.com/account/login
21:46:36.893 Debug cgeo 10479  [OkHttp] 200 (3026 ms) POST https://www.geocaching.com/account/login (http/1.1) (=> https://www.geocaching.com/play/search)
21:46:39.953 Info cgeo 10479  [network--1] Geocaching.com language already set to English
21:46:40.493 Info cgeo 10479  [network--1] Successfully logged in Geocaching.com as Zubu (BASIC)
21:46:40.493 Debug cgeo 10479  [OkHttp] GET https://www.geocaching.com/account/settings/homelocation
21:46:40.493 Debug cgeo 10479  [OkHttp] GET https://www.geocaching.com/account/settings/membership
21:46:40.493 Debug cgeo 10479  [OkHttp] GET https://www.geocaching.com/account/settings/preferences
21:46:40.933 Debug cgeo 10479  [OkHttp] 200 (454 ms) GET https://www.geocaching.com/account/settings/homelocation (http/1.1)
21:46:42.913 Debug cgeo 10479  [OkHttp] 200 (2356 ms) GET https://www.geocaching.com/account/settings/preferences (http/1.1)
21:46:43.463 Debug cgeo 10479  [OkHttp] 200 (2916 ms) GET https://www.geocaching.com/account/settings/membership (http/1.1)
21:46:44.113 Debug cgeo 10479  [network--1] Setting GC custom date to MM/dd/yyyy
21:46:44.113 Debug cgeo 10479  [OkHttp] GET https://www.geocaching.com/my/
21:46:44.553 Debug cgeo 10479  [OkHttp] 200 (416 ms) GET https://www.geocaching.com/my/ (http/1.1)
21:46:45.093 Debug cgeo 10479  [OkHttp] Setting member status to BASIC
21:46:45.533 Debug cgeo 10479  [OkHttp] GET https://img.geocaching.com/user/large/544b6ea3-302a-4341-8758-e396450bebd1.jpg
21:46:48.593 Debug cgeo 10479  [OkHttp] 304 [Not Modified] (3018 ms) GET https://img.geocaching.com/user/large/544b6ea3-302a-4341-8758-e396450bebd1.jpg (http/1.1)

If we solve this riddle, we will get rid of most support mails

[Lineflyer]

Has this anything to do with cookies/keys and validity time of these cookies/keys?

[Lineflyer]

FYI:
This still is a regular issue on support mail:
Login fails with reason "Unknown Error". Reentering login data does not help, but deleting the account information (long press on Authenticate menu) solves the problem in 100% of cases.

[ffflorian]

@Lineflyer
I have the same problem on a Motorola Moto G4 Play with LineageOS.

but deleting the account information (long press on Authenticate menu) solves the problem in 100% of cases.

Where can I find the Authenticate menu?

[rsudev]

It is not exactly a menu :)
It is in c:geo - settings - services - geocaching.com and than the 'Authorize c:geo' (kind of) button.
When you long press, a confirmation dialog will pop up.

[ffflorian]

@rsudev
Thanks, I didn't get the confirmation dialog though (how long do I have to press that button?!), but my problem was that geocaching.com apparently doesn't like connections over VPN. After creating an exception for c:geo the login was working. 🙂

[Lineflyer]

Question to all devs:
What exactly is resetted here besides username and password, if a user long presses this item?
As username and passwort are not the culprits (IMHO) it should be whatever else is resetted here.

Maybe we could reset this value anyway if the login fails?!

[Lineflyer]

From IRC:

[22:13] <pstorch> It deletes the Cookies and withit also the loging to EC when I read the code correctly. I don't know what else is kept in the Cookies.
[22:15] <Lineflyer> mmh...this cookie hold the session information (that you are logged in) or similar...isn't it?
[22:15] <pstorch> yes, I think some session key or something similar
[22:16] <Lineflyer> My simple thinking: Couldn't we just delete the cookie anyway once the login fails. If we keep the username/password we can still try to login and store a new cookie/session key (in case the fail is caused by a network/server problem)
[22:17] <Lineflyer> ^temporary
[22:21] <pstorch> could be worth a try
[22:27] <Lineflyer> indeed IMHO
[22:32] <pstorch> For all errors and all connectors?
[22:37] == pstorch [~peter@2a02:908:1b13:fca0:895e:d682:8adb:8906] has quit [Quit: pstorch]
[22:37] <Lineflyer> Do we have this long press reset for all connectors?
[22:38] <Lineflyer> ups..gone
[22:54] <Lineflyer> For the log @pstorch: I think we have this problem only for GC.

[pstorch]

Sorry, was really tired yesterday ;)
Yes, I think it would be better to restrict the clearing of the Cookies to log in errors of GC.

[Lineflyer]

Today a user contacted us on support mail having the above mentioned problem to login.
I asked the user for the favor to join the beta program and upgrade to 2018.01.20-RC and check whether login is possible again. Waiting for feedback.

What should happen in this case?:
I assume the login will still fail after upgrading, then the new code will reset the cookie.
But now the user needs to retrigger a login manually or force close and restart c:geo. Correct?

[pstorch]

If it doesn't resolve automatically, a restart of c:geo should do it. Anything which triggers a new login attempt.

[Lineflyer]

Sadly the user did not report back whether it worked (which is a good sign as I assume he would have done in case the problem still exists).
We should wait and see if the issue still occurs after we released the current RC.

[chris-brueske]

Thanks @Lineflyer! This worked for me as of today.