cgeo: Relogin triggered on many ocassions

While testing the current state of release for a potential short term release, I stumbled upon a general slowness, e.g. when opening a cache, doing a nearby search, adding a cache to watchlist, and many others.

Looking at the debug log I can clearly see, that all of the above mentioned actions trigger a rerun of the login process in the background. Example scenario:

  • Turn debug logging on
  • Start c:geo, wait until logged in
  • Perform nearby search

Result:

  • The debug log shows the GET command for the search and the corresponding reply
  • Triggered by this reply (?) the login process is started by c:geo
  • The nearby search is done again (Luckily there is no endless loop created)

It seems our “still logged in check” is broken and assumes not being logged in and therefore applying a login.

Log of above mentioned example:

2021-04-22 19:57:19.561 20094-20491/cgeo.geocaching D/cgeo: [OkHttp] 200 (519 ms) GET https://www.geocaching.com/seek/nearest.aspx?lat=51.00205&lng=7.00535&tx=9a79e6ce-3344-409c-bbe9-496530baf758 (http/1.1)
2021-04-22 19:57:19.592 20094-20491/cgeo.geocaching D/cgeo: [OkHttp] GET https://www.geocaching.com/account/signin
2021-04-22 19:57:20.092 20094-20491/cgeo.geocaching D/cgeo: [OkHttp] 200 (500 ms) GET https://www.geocaching.com/account/signin (http/1.1) (=> https://www.geocaching.com/play/search)
2021-04-22 19:57:20.132 20094-20158/cgeo.geocaching I/cgeo: [network--4] Already logged in Geocaching.com as Zubu (BASIC)
2021-04-22 19:57:20.148 20094-20491/cgeo.geocaching D/cgeo: [OkHttp] GET https://www.geocaching.com/play/culture/set?model.SelectedCultureCode=en-US
2021-04-22 19:57:21.047 20094-20491/cgeo.geocaching D/cgeo: [OkHttp] 200 (899 ms) GET https://www.geocaching.com/play/culture/set?model.SelectedCultureCode=en-US (http/1.1) (=> https://www.geocaching.com/play/search)
2021-04-22 19:57:21.071 20094-20158/cgeo.geocaching I/cgeo: [network--4] changed language on geocaching.com to English
2021-04-22 19:57:21.099 20094-20491/cgeo.geocaching D/cgeo: [OkHttp] GET https://www.geocaching.com/account/signin
2021-04-22 19:57:21.601 20094-20491/cgeo.geocaching D/cgeo: [OkHttp] 200 (502 ms) GET https://www.geocaching.com/account/signin (http/1.1) (=> https://www.geocaching.com/play/search)
2021-04-22 19:57:21.638 20094-20126/cgeo.geocaching I/cgeo.geocachin: Explicit concurrent copying GC freed 90407(3283KB) AllocSpace objects, 20(4524KB) LOS objects, 70% free, 10057KB/33MB, paused 87us total 66.370ms
2021-04-22 19:57:21.642 20094-20158/cgeo.geocaching I/cgeo: [network--4] Already logged in Geocaching.com as Zubu (BASIC)
2021-04-22 19:57:21.658 20094-20491/cgeo.geocaching D/cgeo: [OkHttp] GET https://www.geocaching.com/play/culture/set?model.SelectedCultureCode=en-US
2021-04-22 19:57:22.549 20094-20491/cgeo.geocaching D/cgeo: [OkHttp] 200 (891 ms) GET https://www.geocaching.com/play/culture/set?model.SelectedCultureCode=en-US (http/1.1) (=> https://www.geocaching.com/play/search)
2021-04-22 19:57:22.573 20094-20158/cgeo.geocaching I/cgeo: [network--4] changed language on geocaching.com to English
2021-04-22 19:57:22.600 20094-20491/cgeo.geocaching D/cgeo: [OkHttp] GET https://www.geocaching.com/account/settings/homelocation
2021-04-22 19:57:22.603 20094-20620/cgeo.geocaching D/cgeo: [OkHttp] GET https://www.geocaching.com/seek/nearest.aspx?lat=51.00205&lng=7.00535&tx=9a79e6ce-3344-409c-bbe9-496530baf758
2021-04-22 19:57:22.840 20094-20491/cgeo.geocaching D/cgeo: [OkHttp] 200 (239 ms) GET https://www.geocaching.com/account/settings/homelocation (http/1.1)
2021-04-22 19:57:23.697 20094-20620/cgeo.geocaching D/cgeo: [OkHttp] 200 (1094 ms) GET https://www.geocaching.com/seek/nearest.aspx?lat=51.00205&lng=7.00535&tx=9a79e6ce-3344-409c-bbe9-496530baf758 (http/1.1)

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Comments: 19 (19 by maintainers)

Commits related to this issue

Most upvoted comments

SInce I had approx 30min left I scanned some code, specifically GCLogin.java and I haven’t seen any code that deals with cookies. The only variable that seems of interest is “requestVerificationToken”. I certainly don’t know the history of the code, nor do I know if and how cookies are handled by the http(s) library being used. I can only tell, from my own experiments, gspkauth is the one and only cookie needed to make authenticated requests. Of course this cookie can’t be parsed ot of the web page itsself, it comes down in the response headers. The http library should provide a way to manage what is sometimes called a “cookie jar” and it should allow to put these cookies back into the request header of subsequent calls. Can’t investigate any deeper at this time. Perhaps later in the afternoon.