This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-02-04
Channels
- # announcements (1)
- # architecture (18)
- # aws (7)
- # babashka (63)
- # beginners (38)
- # bristol-clojurians (1)
- # circleci (1)
- # clj-kondo (10)
- # clojars (4)
- # clojure (159)
- # clojure-berlin (3)
- # clojure-europe (4)
- # clojure-italy (7)
- # clojure-losangeles (6)
- # clojure-nl (7)
- # clojure-spec (3)
- # clojure-uk (109)
- # clojurescript (54)
- # css (1)
- # cursive (38)
- # data-science (2)
- # datascript (3)
- # datomic (14)
- # docker (2)
- # duct (11)
- # fulcro (47)
- # jobs (8)
- # jobs-discuss (3)
- # kaocha (4)
- # malli (3)
- # nyc (2)
- # off-topic (30)
- # overtone (3)
- # re-frame (17)
- # reagent (33)
- # shadow-cljs (29)
- # spacemacs (3)
- # specter (4)
- # tools-deps (13)
- # xtdb (13)
I'm talking to my company's app's api. First I need to get a session token and authenticate, then I can mess around in the repl.
I'd like to know, what is a sane way to run a function that does these things and verifies that I'm authenticated, and then stop worrying about it
(ns api.auth-and-verify
(:require [clj-http.client :as client]
[clj-http.cookies :as cookie]
[cheshire.core :as json]
[slingshot.slingshot :refer [try+]]))
(def cookies (cookie/cookie-store))
(client/get "" {:cookie-store cookies})
(def token-value
(get-in (cookie/get-cookies cookies) ["XSRF-TOKEN" :value]))
(client/post "" {:cookie-store cookies
:headers {"X-XSRF-TOKEN" token-value}
:form-params {"username" ""
"password" "s3cr3t!
(client/get "" {:cookie-store cookies})
;; => a correct-looking response
does anyone have recommendations on how to organize this so I can call a function once and then have future calls be more about the body of requests and less about the cookie-and-header auth plumbing?
The cookie is state, so you are wanting some kind of state management - is this in the context of a larger app, or just fiddling around in the repl?
I would probably start with writing a small wrapper (defn call-my-api [cookie-store & args]...
which you would call passing a stateful cookie store (probably just an atom if you are just doing repl work, but in the context of an app, a component or some such thing managed by component
, mount
, integrant
etc). that function can check the state of the cookie store to see if you are authed, authenticate if not, and then pass args through to the post
could take it in a few different directions frm there depending on the variety of calls you need to make
We have somewhat similar code in one of the parts of the system which has to refresh API tokens every now and then, we do this by centralizing the token rotation and make all clients aware of the token and pulling it from a shared resource (a Component actually). This way performing requests doesn't involve refreshing the token and obtaining a new one.
> is this in the context of a larger app, or just fiddling around in the repl? Currently fiddling, but with an interest in using a programming language to do some API work and API tests in something other than Postman
Postman is familiar to the rest of my team but, from working with it this week it seems like it would be much better to just use a programming language. I developed the code above in parallel, while I was learning how auth worked at all
The cookie does expire. In my workflow, I restart our app much more often than the cookie expires. Some of the developers may have the same instance of the app running long enough for expiration to be a concern
It does sound like it's time for me to learn one of those component-style frameworks, finally
Try without it for a while, just making the http client call wrapper fn. There is always time to add complexity later :)
yup, and you can handle the time out refreshing within that as well. when the cookie is authed for the first time, you could kick off a little core.async.go-loop
that parks until you hit your timeout threshold, refreshes the token, then loops. for a little more resiliancy you may need to add a little bit of mechanism to hold off on making a call if you are currently refreshing the auth token, so you don't try to send a request at the same time