This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # beginners (47)
- # boot (5)
- # bristol-clojurians (1)
- # cider (45)
- # clara (2)
- # cljs-dev (11)
- # cljsrn (47)
- # clojure (169)
- # clojure-brasil (2)
- # clojure-dusseldorf (22)
- # clojure-finland (1)
- # clojure-italy (9)
- # clojure-nl (3)
- # clojure-poland (2)
- # clojure-russia (4)
- # clojure-spec (79)
- # clojure-uk (105)
- # clojurescript (59)
- # core-async (39)
- # cursive (31)
- # datomic (10)
- # devcards (1)
- # duct (6)
- # editors (9)
- # emacs (12)
- # figwheel (1)
- # fulcro (50)
- # java (4)
- # mount (1)
- # off-topic (47)
- # onyx (33)
- # pedestal (1)
- # protorepl (1)
- # re-frame (32)
- # reagent (45)
- # ring-swagger (6)
- # shadow-cljs (100)
- # tools-deps (6)
- # uncomplicate (27)
- # vim (3)
🕺 slack is unfortunately not explicit about the exact manner of dancing the man is indulging in @yogidevbear , but were it up to me, i would choose disco
Just a very quick question, in case any of you have a solid answer... How would you kill a session in a tabbed browser when all the tabs for a site were closed, without an explicit logout action? (i.e. public computer close all windows, walk away and someone else cannot re-open the tabs and be logged in)
if you don’t want to nuke all the cookies, you can generally find cookies set by the specific url if you dig into it
…or do you mean as the owner of the site? then you’d use a session library with session invalidation after a certain time period
…You can also use incognito browsing mode when you start your browsing session, that’ll automatically clear everything up, including your history!
@lady3janepl - Yeah, I am talking about as the site owner / operator, how could one use code to kill that session.
@maleghast if your get your client to hold open a websocket, you can clear the session on the api-side when the websocket connection drops
which will also drop the session if there are network outages, which may be too inconvenient
I was just going to ask if there was any way to mitigate patchy network, but you answered that 🙂
yeah, depending on what your expected user is, I’d be worried about sessions dropping for mobile users
@lady3janepl - as in cookie lifespan? Unless it's < 60seconds there's a lot of scope for another user to re-open the tabs and be logged in.
not a cookie lifespan, because you can’t rely on those - when you store session data on server side, you check the time of last access
if it's an SPA then it's easy - you can just keep the auth token in volatile storage, so auth is required on every reload
and yes, it’s not immediate since it’s user-error-tolerant so it’s not really a substitution for users logging out on a public computer
you could do what banks, github, etc do and require a password confirmation for a logged-in user to execute extra sensitive actions
i haven't done anything that isn't an SPA for so long... i almost forget they exist
@lady3janepl - User closes browser / tabs and walks away, another person re-opens the tabs and is logged in. On a public / shared computer.
js on window-close is flakey anyway - if there are real security concerns then you need a threat model, and probably something like @lady3janepl’s suggestion of additional auth for sensitive ops
running a script on page close is dependent on noone setting up the browser in a malicious way for the user
My bank does that - to send money to a "new" payee there is a 2FA component that would negate the ability of a bad actor creating a new payee and draining my account, unless they had my token device / and or me with a gun to my head.
that’s why I asked what you’re trying to protect against - it’s who the “another person” is. for non-sensitive data it’s probably too much effort, and for sensitive data it’s not enough protection.
most bank sites manage to disable browser nav or page-reload though - how do they do that ?
@mccraigmccraig - HSBC doesn't, it just has notices everywhere saying don't use the browser buttons or the site will log you out.
it used to be much more popular that pages would disable copy-paste for example, or add extra text to the buffer, back when people were more concerned about having their content stolen
They have tokens on links / events and if you don't click on a link to navigate you get dumped.
yeah, single-use tokens basically 🙂 but that doesn’t protect you against someone reopening a cached tab
(not my job / business either, so not too upset about not being the arbiter of all choices)
SPA frontend is not so much different from backend @carr0t - non-SPA frontend is painful
I had a look at re-frame - because all the cool people are using it and saying it’s awesome for larger projects
but it quickly looked like a massive time-sink, for very little benefit over reagent
now, it may just be that none of my SPAs are big enough so far to be worth the extra complexity
or it may be that I was too tired and/or stupid when I was investigating it to quickly grok it’s pattern
ha, maybe... i've never found it to be a time-sink - mostly it just enforces a discipline and convention that you would want anyway, but most probably better thought out than a home-rolled solution would be
but it's got quite a bit more in it now than it used to have (with all the effects stuff) so maybe the cognitive load has increased
I don’t doubt that it’s well thought out - I just didn’t understand it, and without having internalised the ‘thought-out-ness’ it feels gratuitously complicated
I suspect that its patterns are a good solution to things that I mostly solve with developer discipline.
at its core there are 3 things  single global source of state  views (= reagent components) subscribe to parts of that state and  state evolves only by reducing events (with handler fns) on to the global state
that's basically it... but there are a bunch of conventions and detail on top of that to make it happen which can probably be confusing (subscription layers, interceptor chains, effects, all the talk of dominos)
i don't think it's perfect though - event handlers don't compose well, meaning that it doesn't help you abstract complex interactions between client and server in the way that you can by (say) composing promise-producing fns
I am pretty sure that I will need to adopt re-frame, but in order to hit productivity goals in the short-term I have kicked adopting it down the road a little and while I realise I may__ be storing up pain for myself, Reagent on its own is so productive and I don't have to grok the (well thought out) wrappers over the top that re-frame uses.