tobykurien
Cookies for Tweakers.net
I'm trying to create a WebApps entry for https://tweakers.net
Whatever I do, no cookies are saved. I've toggled every setting. After I accept the cookies on the website, the next time I run the WebApps entry, I get the same cookies consent dialog. The same thing happens after I've logged in on the site.
Any way I can get and provide more info on what's going on?
Latest WebApps via F-Droid Android 9 (recent LineageOS 16) on Galaxy S5 Using Bromite WebView
Logcat entries that may be of concern:
07-02 09:18:50.198 I/chatty ( 1581): uid=10164(com.tobykurien.webapps) identical 24 lines
07-02 09:18:50.200 D/aBatis ( 1581): Attempt to invoke virtual method 'boolean java.lang.String.equalsIgnoreCase(java.lang.String)' on a null object reference
07-02 09:18:50.655 W/SurfaceFlinger( 498): Attempting to destroy on removed layer: AppWindowToken{e08a2cc token=Token{bd24ff ActivityRecord{654541e u0 com.tobykurien.webapps/.activity.WebAppActivity t13985}}}#0
07-02 09:18:53.552 I/ActivityManager( 840): START u0 {act=android.intent.action.VIEW dat=https://tweakers.net/... cmp=com.tobykurien.webapps/.activity.WebAppActivity (has extras)} from uid 10164
07-02 09:18:53.582 W/ActivityThread( 1581): handleWindowVisibility: no activity for token android.os.BinderProxy@bd9e194
07-02 09:18:53.662 D/aBatis ( 1581): Attempt to invoke virtual method 'boolean java.lang.String.equalsIgnoreCase(java.lang.String)' on a null object reference
07-02 09:18:53.665 D/aBatis ( 1581): Attempt to invoke virtual method 'boolean java.lang.String.equalsIgnoreCase(java.lang.String)' on a null object reference
Already running 3.50 via F-Droid and the issue persists: the cookies wall always shows up, even though I chose to accept the cookies. Also, when I return to the website after having been in some other app, whatever I click next on the website will result in the cookie wall popping up again. This also results in me being unable to post comments after looking up some info in another app, because when I press "Reply", the website states it's lost the session. Similarly, search results are often lost due to a "session invalid" messages.
v4.0 just became available on F-Droid. Unfortunately, I'm getting the exact same results with this version.
It's really easy to reproduce:
- Open the site https://tweakers.net,
- Agree to cookies
- Open the Settings and then return
- Click any link and the cookie wall will show again
Tweakers.net is really finnicky, yes it doesn't work but if you keep trying, at some point it sticks and works thereafter. It has been a nightmare to test because of this. It seems the session cookie changes on each page load and eventually WebApps will be in sync with the server.
What a b*tchy way to use cookies. I've been trying all day, but the cookie has never "stuck".
I got it to work like this: save the webapp, open it, accept cookie, close app and reopen it, accept cookies again if it asks and close, and reopen until it doesn't ask anymore. Took me about 5 tries.
Have you blocked any 3rd party requests/3rd party domains? (I'm trying without doing that, too.) I have tried over 40 times by now, the exact way you're describing.
I just tried again now after deleting the webapp, and again after the 5th time it stopped asking for cookie acceptance.
There are two factors I can think of that may influence the fact that I can't get it working:
- I'm using a rather old phone (Samsung Galaxy S5, but with Android 10)
- I'm using Bromite WebView instead of Android's default WebView.
I'm probably gonna see that cookie wall dialog in my sleep now...
I just tried on another phone, not rooted, Android 9, with a clean installation of WebApps via F-Droid. After trying what you described (open - accept -exit) 50 times there still is a cookie wall every time. In case you meant "close the app via the back button at the top left" instead of choosing Exit, I also tried that (for what it's worth).
I am testing on a non-rooted Android 9 device, also with F-droid version. Will look into this further when I get a chance.
Any news on this? Anything I can do to get you more info about the issue?
No news. It's too tempremental an issue and takes too much effort to debug, so I have given up. Similar to #215 which I am still trying to figure out, and affects me, I was hoping to solve them both in one go, but so far no luck.
Understood. I could inquire about what the hell they're doing with their cookies over there (I'd need some more specific terminology to pose a useful question though 😅), although I don't know if that would also help with the GitHub issue.
I'm getting the same kind of issues with Gitlab now (half-assed logins that show error 422 upon login, but then show myself as logged in, unless I try to reply in an issue), and Gitea instances like Codeberg (I can log in and browse as if logged in properly, but when I post any form I get a session error).
These cookies issues keep happening for all kinds of websites:
- Codeberg.org may remain logged in, but as soon as I want to do any kind op POST operation, like replying to an issue, I get
Bad Request: Invalid CSRF token. - A simple old phpBB v2 forum (which uses simple PHP sessions and purely cookies, no local storage) sometimes spontaneously logs out while browsing.
All this is somehow related to session tokens, but I'm not sure what I can do to further investigate. Are cookies sometimes prevented from "updating", or are old cookies restored, e.g. onResume() or something?
Yes cookies are saved in onPause() and restored in onResume(). If you click from one webapp to another, all cookies are deleted and then the one for the new webapp restored. Again if you navigate back to previous webapp, all cookies are deleted and saved ones restored. This may have unintended consequences, but is the only way I know to make a good sandbox.
So it would always restore the cookies in onResume()?
But with rolling session tokens or something, that could go wrong quite simply, right? If there's already a cookie, it might have changed since onPause() (or perhaps even right before onResume()), and onResume() will then restore an old cookie without reason.
If, instead, onResume() just checks which app is active and for which app the cookies have last been restored, then it could just not restore anything if the right cookies are already present.
I don't know if this would be the actual issue as described here, but I'd say if I understand the current procedure correctly from you reply, then I think it could unnecessarily introduce problems just like it.
It only restores cookies if the webapp has changed.
Aah ok, didn't get that from your previous reply, thx 🙂
I guess that whatever's going wrong is totally beyond my comprehension then 😅