Clojurians Log v2

How do folks generally auth and set cookies with om.next? Somewhat difficult for me to reason about since setting a cookie would be an effect that isn't captured in the state of the application.

@devo re: auth do you mean JSON web tokens? if so, i just store those access tokens in my app state, then assoc those into the AST to be sent to the remote

As for cookies: you could do it on app run, before om starts. Check the cookies. If the auth exists in your cookies, then store it in your app state e.g. (om/merge! reconciler {:app/session session})

where session is whatever information you get from your cookie

and if that info doesn’t exist, then route to your login page

https://github.com/compassus/compassus

alternatively, if you want to give some functionality to the user even if she isn’t logged in, you have a few options:

can be used together or separately 1. have your components ask for your app session (which should be in your app state) to decide what to show 2. watch for 401 errors in your remote responses and then reroute to login

you can also do some auth checks in your mutates, but checking for 401 is the most elegant for me.

and since I do enterprise apps, i’ve not really done much of having my components for app session since my clients always want the user to be logged in anyway. But yeah, that’s something that’s open to you if you want to conditionally show things other than a log in screen

further, if you have a complex web app, your server auth would probably give you back additional information like role or access permissions. those you can store also in your app state, and then accordingly use those in your components

Is it best practice for login pages to be mostly static? Was making a login page w/ om just to get an idea of how to get SSR / remotes working as well as learn a bit about query params, i.e. serving a login / account creation page on 401's and using om to provide feedback on email / password validation.

In the use case where I have om on this page, successful logins would yield a jwt from the server and I would then merge that into cookies and redirect to the originally requested url.

and failures would be represented in the app state and provide user feedback

@devo I make my login pages dynamic. they’re another om component.

nothing against them being static, of course. you just lose out on inline validation

Do you do full redirects between the login page and other pieces of the application, or is the login piece just a component that is routed to w/ compassus based on current state?

the latter

i also use pushy for pushstate so it looks like it’s a full redirect

ok. That makes sense, cause then tokens could entirely be represented in the app state instead of needing to be stored for a full redirect.

yes

but i’d say as best enterprise practice, that you make it work even without javascript

that would include the effort for full redirect

i.e. your login page would work even before the javascript loads (in the case of a slow connection)

but for most MVPs, you don’t need that

Gave me a couple of things to think about for this. Thanks!

np!