Leser gjennom https://auth0.com/blog/secure-a-clojure-web-api-with-auth0/ og ser til min store glede at de refererer til https://gitlab.nsd.no/clojure/clj-jwt som @ivar.refsdal ser ut til å ha skrevet 🙂 Så hva er vel bedre tidsbruk enn å lese gjennom et clj lib til frokost. En observasjon som jeg har lyst til å komme med (og som egentlig kom da jeg igjen tittet på https://github.com/metabase/saml20-clj) er at et etter min mening er fornuftig å begrense antall eksterne biblioteker til et minimum, spesielt når man driver med sikkerhets ting. Spesielt innenfor sikkerhet er det min mening at koden må være så enkel som mulig (men ikke enklere 🙂 slik at man så lett som mulig kan skaffe seg en forståelse av hva koden gjør, hva slags avhengigheter den har etc. I eksemplet med saml20-clj, så depender den på potemkin. Ikke at potemkin i seg selv er et sikkerhetsproblem, men det er jo stort sett et convenience lib som man kunne tenke seg at man klarte seg uten i et slikt bibliotek. I clj-jwt, tror jeg at jeg ville valgt å skrive det uten algo.generic og tools.loggging fordi jeg 1) ikke “off the top of my head” vet hva fmap gjør og 2) er av den oppfatning at et lib som clj-jwt ikke burde bry seg om logging men heller delegere det til call site. Merk. Dette er ikke ment som en kritikk av clj-jwt, men heller som et utgangspunkt for en diskusjon. At jeg er en dust og tar helt feil er et helt fint sluttresultat av en sådan :)

God intro til diskusjon! Ang. logging: Enig at slike bibliotek ikke burde avhenge av en spesifikk log-implementasjon. Spesielt i Java-land, hvor det er så mange ulike implementasjoner og fasader. Det er så enkelt i Clojure å sende inn en funksjon som biblioteket kan kalle når det skjer noe interessant. Som konsument implementerer du denne funksjonen som du vil, ved å wrappe log-implementasjonen du bruker i applikasjonen. Jeg har brukt denne teknikken i Proletarian: https://github.com/msolli/proletarian/blob/main/src/proletarian/worker.clj#L28 Det er også mange bibliotek som velger å avhenge av en fasade. commons-logging og slf4j-apier mye brukt.

Jeg tror også jeg hadde foretrukket om https://gitlab.nsd.no/clojure/clj-jwt/-/blob/master/src/no/nsd/clj_jwt.clj#L115 ikke var en del av dette biblioteket, men at det var brukers ansvar å skaffe til hende jwt-tokenet. Det er dog mulig at biblioteket da hadde blitt litt tynt?Og for all del, jeg sier ikke at jeg hadde klart å gjøre dette bedre.

D.v.s. du ville dele den i to, en bare for validering og en for henting av nøkler? (siden det ser ut til ikke å være trivielt så det er fint at noen skrev koden som gjør det)

Jepp. Det er også et poeng at clj-jwt ser ut til å cache jwt slik at man ikke henter dem så ofte. Det er en policy greie som jeg kanskje kunne ønske å kunne gjøre anderledes.

Det er derfor resolve-key er såvidt komplisert.

Kanskje jeg ønsker å cache, kanskje jeg ikke ønsker det, kanskje jeg ønsker å påvirke hvor lenge ting lever i cache’n

Men jeg synes det er en interessant diskusjon om hvor små bibliotekene skal være, den andre ekstremen er jo å gå i retning av JS der hver funksjon blir et bibliotek.

Det er @snorremd som har skrive hovuddelen av clj-jwt, men takk for tilliten @slipset 😄 @schmandle har også eit par commits. Eg synest det er heilt greitt å depende på eit loggebibliotek som clojure.tools.logging. Den velger for deg, på runtime, ein konkret loggeimplementasjon: https://github.com/clojure/tools.logging#selecting-a-logging-implementation Einig i at ein truleg kunne klart seg utan algo.generic. Når det gjelder caching og levetid så er dette gitt av JWT-en, dvs. den har eit expiry felt, så det er naturleg å støtte dette "out of the box", tenker eg.

Der har du meg, jeg visste ikke at jwt har expiry 🙂

Fort gjort. Off topic-ish, men her er eit cache bibliotek med dynamisk lengde på cachen: https://github.com/ivarref/memoize-ttl (utan avhengigheiter)

Sistevalget til clojure.tools.logging er java.util.logging, som er bundla med JVM-en (sidan 1.4)

Vi bruker timbre hos oss.

Timbre är fint när du vill ha clj+cljs combo

Me brukar også timbre (dvs. eit in-house bibliotek som bundler/wrapper timbre)

Ja, det går i Timbre her også. Har slitt i hele dag med at Figwheel sin bruk av java.util.logging ikke går så greit overens med CIDER.

Dere har et selskap som jobber med Clojure i Bergen, @ivar.refsdal? Hvem er det?

Det er (var frå 1.1.2022) NSD, som vert til Sikt. @ornulf.risnes er også på NSD

Akkurat, ja. Bra greier 🙂 👍

🙂 Eg brukte com.fzakaria/slf4j-timbre +

(do
    (SLF4JBridgeHandler/removeHandlersForRootLogger)
    (SLF4JBridgeHandler/install) ; (org.slf4j.bridge SLF4JBridgeHandler)
    (.setLevel (Logger/getLogger "") Level/FINEST) ; (java.util.logging Logger Level)
    ... timbre setup ...

Kommentar i koden over er imports

Problemet med CIDER + Figwheel Main er at Figwheel lager seg en ConsoleHandler som lukker over System/out før CIDER har rukket å endre out . Jeg har klart å overstyre det slik:

(require '[figwheel.main.logging :as fml]) ;; pun intended
  (doto fml/*logger*
    (.removeHandler (first (.getHandlers fml/*logger*)))
    (.addHandler (doto (ConsoleHandler.)
                   (.setFormatter fml/fig-formatter)
                   (.setLevel Level/ALL))))

men timingen er fortsatt såpass off at mange av loggmeldningene blir spyttet ut av figwheel før CIDER er klar for å ta dem imot. Så tror jeg må dykke ned i nrepl for å få løst det skikkelig.

(det som skjer i koden her er altså at jeg lager meg en ny ConsoleHandler etter at CIDER har klart å binde out)

La det være sagt: Jeg ønsker ikke all denne smerten på dere også, altså. Gå heller og finn på noe koselig. 😅

Hehe. Hm OK. Vriene saker.

Eg oppretta følgande issue på nrepl for lenge sidan: https://github.com/nrepl/nrepl/issues/119

Jøss, var det du som lagde den issuen. Jeg har studert den i dag nettopp i denne forbindelse. 😄

Hehe. Tidig. Den gisten som løyste problemet (for meg) er lenka der

Jeg skal gi gist-en en sjanse til. Takk! 👍

Janei. Mitt oppsett var boot "repl" (terminal aka nrepl server) + cursive remote nrepl (nrepl client)

og så var det vel logback for logging, meiner eg

For de som vil ha noe hyggeligere lesestoff enn timing-issues og dynamisk binding i nrepl, så kan jeg anbefale @anders sin nye bloggpost om Property Based Testing med Clojure 😄 https://www.kodemaker.no/blogg/2021-12-15-property-based-testing/

Artig å se clj-jwt-biblioteket poppe opp i kanalen her. Ble til mens jeg jobbet på NSD og plutselig hadde behov for noe jwt-validering. Ville helst ikke hente inn noe Java-beans. 😉 Enig i mye av tilbakemeldingen forøvrig. Edit: Skulle det vært skikkelig distribuert som bibliotek er nok logging og key-fetching noe som potensielt kunne vært flyttet ut. Med en mulig default key-fetching-funksjon.

Nå jobber jeg dessverre i en bedrift som ikke bruker Clojure. Så det begrenser seg til hobbyprosjekter og advent of code.