Forum login failures
Alan Adams (2486) 1131 posts |
Not disputed. The issue is that these cookies are session cookies, but they are still there when there are no windows or tabs open on the risc os open site. OK, some more testing. So the issue isn’t firefox, it is with the web site, which is mishandling its own cookies. The ones created on first opening the site prevent logins from working. They have to be recreated by logging in when none exist. The part that concerns Firefox is that closing windows or tabs doesn’t selete session cookies. It only happens when closing the application. This has implications for banking sites etc, as logins can persist even after the site has been closed. I have now closed the risc os open page and gone to a different site. Then opened a new tab, came back here, and I’m still logged in and able to post. (We are talking here about the latest Firefox on Windows 7. Other versions may behave differently.) |
Rick Murray (539) 13434 posts |
Yay! You’ve caught up with the rest of us. ;-)
They behave as variously described above. And Chrome. And stock browser. And Safari (which won’t let me log in at all on iOS). And Opera…
I agree. In this day and age, one should consider “no tabs open” to mean “session terminated”. |
Rick Murray (539) 13434 posts |
True, but… Would it be an interesting potential target for RISC OS? My personal thought is… No. I’m not whoo over infra red. This isn’t the ’90s. |
Steve Pampling (1551) 7963 posts |
Actually, it will work quite happily (on my Firefox install) with cookies present from several days before as well as just a few hours. Anyway a Saturday ISP glitch one week was followed by a failed login the next Saturday and I’m waiting to see whether the total shutdowns this week result in fresh cookies or whether I get a repeat of the problem this Saturday. 1 If I’m rushing in a morning I just hit sleep, and bedtime feeding the cats is far more important than a proper shutdown. Ask any cat. |
Alan Adams (2486) 1131 posts |
OK, so i think I’ve established what sequence of things works, and what doesn’t. Clear cookies and log in. This stays logged in. It also stays logged in if you leave firefox running but not on the risc os open web site, and even if you now hibernate then resume the machine. All because Firefox doesn’t clear session cookies until the application is closed. Close firefox and go back to the risciosopen site. Log in. This fails to stay logged in. In this case the 2 cookies were not present when first visiting the site, and the ones created at that point cause the login to fail. The third cookie is created, but this set of 3 doesn’t work. After clearing cookies and logging in, the 2 initial cookies plus one more are created, and this set of 3 allows the login to be recognised by the web site. Logging out before leaving the site doesn’t alter this behaviour. So in Firefox, log out, leave the site, by going to a different site, e.g. bbc.co.uk. Then go back to the site and log in. At this point you still have the cookies created during the previous login process, rather than new ones created by arriving at the site. The login is successful, and persistent as you navigate the forum. My prediction here is that using a browser which clears cookies when leaving the site will require cookies to be cleared every time before successfully logging in. |
Steve Pampling (1551) 7963 posts |
Any change in behaviour if you set Firefox to allow www.riscosopen.org cookies for “session only” ? about:preferences#privacy > “Cookies and Site Data” > “Manage Permissions” enter www.riscosopen.org and select “Session Only” Theoretically that should force the browser to treat the cookies as session only irrespective of the attribute setting of the cookie supplied by the server. |
Chris Mahoney (1684) 2117 posts |
It’s been almost a week since this suggestion was posted, and I haven’t experienced the issue since updating my bookmark accordingly. It looks like John was onto something! |
John Sandgrounder (1650) 574 posts |
:) Still works for me. |
Andrew Hodgkinson (6) 465 posts |
Unfortunately, I can’t replicate this. On OS X with the most recent Firefox, closing (as in, completely quitting) and restarting the browser leaves me logged in. That’s kind of horrifying given they’re session cookies. I’m certainly keen to find a way to replicate this, but every single one of the approaches listed in the forum doesn’t work for me. Since restarting under the new Hub back-end process a week or two ago, I initially had the expected issues for the first 12 hours and then browsers on all devices – including e.g. Safari iOS, which I know one poster says simply never works for them – have functioned correctly. This is my main problem. If I can’t replicate something, there’s simply no way I can diagnose it – and on the rare times it’s happened to me, it’s just “gone away” during the process of trying to establish a sufficiently deep top-to-bottom debugging environment. Quite frustrating all-in. |
Rick Murray (539) 13434 posts |
iOS 7.1.1. I think I’ve worked out why it won’t work. Settings → Safari → Advanced → Website data → Show all ROOL is not listed as having any site data, even after I’ve visited and logged in, so clearing cookies probably won’t remove a cookie it doesn’t think I have. It’s not a big deal for me. Mom is the primary user of the iPad these days. I’d rather use Firefox on my freebie tablet (really slow!) and know that the lethergy is the browser sanitising my browsing experience. It’s always a bit of a shock on iOS, all the adverts, discussion extensions, and popups that appear. ;-) Suffice to say neither “Remove all website data” nor “Clear cookies and data” has any useful effect on the login process. I can’t say I’m surprised to be honest, iOS 7 had quite a number of annoying bugs… like IMAP support in the email client, right? It’s a tablet so it only needs to sync a week or so, right? Not if you’re Apple – the email client currently consumes ~1.1GB as it has synced everything in the mailbox, and there’s no “only sync X days” option that I can see, it was there in iOS6… the only sync I have is for calendars. |
David Pitt (3386) 1248 posts |
Using Safari on iOS 12.3.1 then deleting website data does not do a lot of good. I thought this might be because having deleted the data Safari, somehow, manages not to be on a ROOL page anymore. What does work, here at least, is to quit Safari by swiping up from the ‘double tap on the home button’ screen, then using the ’login from the welcome page without having seen a forum page’ ruse that works elsewhere. Sent from an iPad. |
Frederick Bambrough (1372) 826 posts |
For K-9, Account settings-Sending mail-Reply quoting style-Prefix (Like Gmail). That gives bottom posting. For interleaved I just type in the quoted part. K-9 Mail doesn’t care. Typing this on Android Chrome is fun :-( |
Rick Murray (539) 13434 posts |
Thanks. That works. Sent from my iPad too. ;-) |
Rick Murray (539) 13434 posts |
Does it throw away the entire message if you save your message as draft? I found the stock mail client would save the message body and the quoted content, but not the edited quoted content… It’d be better if there was just a mail client that worked like everything used to until Outlook Express dumbed it down to bunging a copy at one end of the message. Grrr…
If your device is up to it, install Firefox. I found Chrome messed with the text in horrible ways. |
Frederick Bambrough (1372) 826 posts |
Haven’t tried that.
Exactly. It’s putting the formatting help bit over the text entry box ar the mo’. I’d usually use Ghostery but that has the logout problem |
Andrew Hodgkinson (6) 465 posts |
Assuming those statements are connected, any iPad that can run iOS 7 can run at least iOS 9 as well. 8 was OK, 9 is slow, but at least 9 has generally fewer bugs – 7 was, as you rightly say, a mess. Things never really recovered to iOS 6 reliability even to this day, but at least they did improve :-) Bumping up a major version or two would be helpful from a security standpoint, though I doubt there are many in-the-wild attacks for iPads around the iPad 2/3 era age. |
Andrew Hodgkinson (6) 465 posts |
That and other similar comments, along with observations about which cookies seem relevant, have been really helpful so many thanks to everyone who’s contributed various forms of diagnosis so far. The good news is I think I can at long last replicate the bug reliably on Safari:
So as some have surmised this does seem to be something to do with one or more of the web site applications establishing session data before going to Hub, then something in that existing session data conflicting with Hub sign-in information and leading to a sign-out condition. In the reworked crypto and security layer code from the recent updates to Hub’s SSO daemon on the server, I did tighten up some code and it looks like this has actually worsened the issue by being “more jumpy” about what constitutes a violation from Hub’s perspective. If you get stuck in such a state, the most likely-to-work solution I think for all browsers and platforms will be:
This should mean there are no session cookies from any of the component applications that make up the ROOL site present, other than that from the Hub application itself. Thereafter, applications establish session cookies but do so in the context of a signed-in user. Now that I have a replication path that seems reliable, I stand a chance of actually fixing this. Doing it properly is one thing, but an intermediate hack suggested already by another poster might be to just kick out (as best you can, with cookies) any cookie that Hub would “hard-code” to know come from any of the ROOL component applications whenever you sign in (or out, belt & braces after all!) which ought to be basically the automated equivalent of the manual cookie cleanout described above. |
Andrew Hodgkinson (6) 465 posts |
…OK so that first pass, which just clears the old session cookies, is done. This in fact may be sufficient and trying to do anything more clever at this point on the old software base may not be useful. As things stand on the live site right now, I can follow the above process to do what used to fail to log me in, and now successfully end up logged in and at the “new topic” page. For those applications on new enough (for relative values of “new”, obviously) to support it, I’ve also taken care to set the Please let me know how you all get on. I’m afraid I can’t vouch for Safari on iOS 7, as I don’t have anything running software that old unfortunately; not even under simulation. Will be interesting to see if it works now, avoiding the need to try anything as drastic as a major version iOS update on the device. |
John Sandgrounder (1650) 574 posts |
Sorry, I still need to have my bookmark set to the welcome page. I can not successfully log in with the bookmark set to the forum. I am using the final version of Firefox on Windows XP. |
Chris Mahoney (1684) 2117 posts |
I also just ran into the problem again in Safari on iOS 12 :( |
Rick Murray (539) 13434 posts |
Fairly recent Firefox on Android – nothing appears to have changed. Sorry. :-( |
Steve Pampling (1551) 7963 posts |
I’ve not had difficulties since Saturday, which was a) before Andrews most recent work, b) Exactly when I expected an issue because I’d had an issue 7 days earlier. On a positive note the security/pen test sites while disagreeing about the level of security do agree that the former B- and B+ results are now UP to B and A- with the shortcomings limited to support for stuff like TLS 1.0, TLS 1.1 and some weak ciphers on the keys. I say “Sterling job that man”. |
Rick Murray (539) 13434 posts |
Ooh, can’t push too far into modernisation or we might experience difficulties reading about RISC OS on, err, RISC OS. ;-) Had the can’t login issue on Firefox (just now) but decided to try force closing the app. That worked (so it’s properly treating session cookies as session) and, yeah, that was possibly faster than getting rid of them in Cookie Manager!
Indeed. Updating a live site written in a less common language where you’re the only maintainer… That’s a hard task. Unfortunately it’s not done yet as there are still cookie issues, however the bright side (as has already been pointed out) is the diminished volume of spam. |
Rick Murray (539) 13434 posts |
I never updated because iOS 7 was about 2GB, and iOS 8 was over 5. That would be an eternity to download on my ADSL, and that’s assuming the updater is capable of resuming upon a problem, and not just throw in the towel and begin again (hello Google Play Services, I’m looking at you). I probably cannot update at all now, it is offering me an iOS 9.something update that’s about 64K in size. I wonder if it’d be stupid enough to try installing that and brick itself? I don’t plan to find out, though I find it disturbing that it’s offering a patch to iOS 9 on an iOS 7 device! |
Steve Pampling (1551) 7963 posts |
As I recall the truth at the heart of it all is that to match the Apple claims of battery hours maintained over the life of the handset being longer than android they put in code to detect the state of the battery and reduce the cpu performance to reduce load. |