Discourse shows user logged in after clearing cache/cookies
-
[b]Issue:[/b] When I clear cache/cookies, I remain showing as 'logged in' while I navigate various categories.
[b]Expected Behavior:[/b] On page change, indicate I'm actually logged out instead of having to ctrl+f5
Filed Under: Looking at you, @sam, @codinghorror
-
That would be the fact that you're logged in staying in the Javascript app.
I think that clicking on Log Out in all open tabs would achieve what you want.
-
I think that clicking on Log Out in all open tabs would achieve what you want.
In all the tabs? I would hope that logging out once would be sufficient.
-
Correct. But why should I have to? Clearing cache/cookies is sort of the 'nuclear option' - and a simple check on whether or not i actually have a valid login token seems like a useful tool. If I clear all cache/cookies, I expect to be logged out of EVERY site. If your site remains logged in, I get concerned.
You could do something as simple as
if(!cookie.exists){user.isloggedout}
-
Well, the page doesn't actually reload on navigation most of the time. That only happens when you hit F5 and after an update.
-
I think that clicking on Log Out in all open tabs would achieve what you want.
@Matches You can also just refresh the page assuming you already cleared the cookie.
-
On the main topics page, it goes from /category/meta to /category/general, if you're telling me there's no refresh between /category/meta and /category/general, then discourse is a bit of a bigger wtf than I realized.
That said, there should still be a [client side] check [for 'pretty'] when navigating the site to see if you're still logged in. It's not a performance hit in any way, and it is part of sane operating procedures because it changes how you can interact with a site (IE: creating a new topic)
Refreshing the page manually is the exact behavior I'm arguing is not the correct or expected behavior.
-
On the main topics page, it goes from /category/meta to /category/general, if you're telling me there's no refresh between /category/meta and /category/general, then discourse is a bit of a bigger wtf than I realized.
Welcome to the future, baby!
Filed under: browsers don't update the list of cookies clientside unless an actual refresh happens
-
-
Everything you see on the page is put there by JavaScript. The only HTTP calls we ever make are to pull down whatever JSON data is necessary to render in your browser.. with JavaScript.
Filed under: Atwood's Law
-
I'll just leave this here for you, so that you can check if the cookie exists... using javascript.
How do I check if a cookie exists?
What's a good way to check if a cookie exist? Conditions: Cookie exists if cookie1=;cookie1=345534; //or cookie1=345534;cookie1=; //or cookie1=345534; Cookie doesn't exist if cookie=; //or <...
-
Clearing cache / cookies is not exactly a daily or even weekly operation for most people. This is kind of the "I open my car door while the car is driving and that seems risky, can you prevent that" of bug reports, isn't it?
-
Actually, it has a reek of something more nefarious behind it.
It suggests that sessions may not be cleaned up properly and could potentially be abused by actual miscreants (rather than misanthropes like us)
-
Sure, I'd typically agree, except discourse happens to
SPAM THE SHIT OUT OF MY HISTORY
and if I want to find anything useful in there, I typically 'Sweep the shit out the door' then go about my normal business.
Also, I generally agree with Arantor - retaining the login view after clearing cache/cookies is generally a security flag.
-
Discourse's new tag line, of course, is "There's a user preference for that", you can actually turn it off but I gather it has some side effects not that I've seen any yet.
-
There's a user preference here on TDWTF to fix that:
Also, I would say that this is just the fact that it's impossible for the JS to know when you clear your cookies without doing some kind of server round-trip check, which is both wasteful and a little creepy.
The server is capable of sending a "please refresh now" message to the browser, which is done from here:
https://forum.riking.org/admin/users/riking
-
Eh? Considering the amount of roundtrips already going on anyway to mostly-live update things, I'd have thought doing a cookie check alongside that was near enough free to be doing.
-
I was able to successfully request a password reset after clearing cache + cookies from my user profile page. Intentional?
-
"There's a user preference for that", you can actually turn it off but I gather it has some side effects not that I've seen any yet.
It breaks Back, but that's "not supposed to work" for web apps, anyway.
-
Does it? I hadn't noticed, probably because I open things in new tabs.
-
You know, I do have to half-blame the browsers for that. The function is called
replaceState()and the spec says it shouldreplacea history entry.How the hell do you confuse
replacewithpush, but don't update the stack counter, I do not know.
-
Browsers are TRWTF.
-
No, being able to send a password reset after clearing browser history+cache is TRWTF - it uses the session data to send the password reset.
-
Actually, yes, you win, that actually is TRWTF. Though browsers are really a WTF anyway.
-
It only "breaks" Back if you expect to go where you were (roughly) when you click a link regardless of any anchor you'd have started from.
I put quotes around break because I don't feel that it's broken, given how browsers behave in effectively the same circumstances.
-
And that's why I am thankful for His Noodly Appendages reaching down and granting mere mortals like me the power to open links in new tabs whether the app's preference says so or not.
-
