This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-12-16
Channels
- # adventofcode (43)
- # announcements (31)
- # aws (2)
- # babashka (58)
- # babashka-sci-dev (4)
- # beginners (107)
- # calva (11)
- # cider (25)
- # clj-commons (8)
- # clj-kondo (24)
- # clojure (35)
- # clojure-argentina (1)
- # clojure-europe (25)
- # clojure-italy (5)
- # clojure-nl (11)
- # clojure-norway (39)
- # clojure-spec (11)
- # clojure-uk (3)
- # conjure (2)
- # core-async (19)
- # cursive (33)
- # data-science (2)
- # datomic (50)
- # deps-new (1)
- # emacs (3)
- # events (4)
- # figwheel-main (10)
- # fulcro (63)
- # graalvm (7)
- # holy-lambda (17)
- # introduce-yourself (1)
- # java (15)
- # jobs (1)
- # jobs-discuss (7)
- # malli (24)
- # meander (16)
- # nextjournal (19)
- # off-topic (2)
- # polylith (4)
- # portal (10)
- # re-frame (3)
- # reagent (19)
- # reitit (14)
- # releases (2)
- # remote-jobs (1)
- # reveal (19)
- # shadow-cljs (1)
- # sql (21)
- # testing (4)
- # xtdb (22)
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-api
er 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.
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.
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)
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
🙂
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 ...
for å få tak i java.util.logging (frå postgres-driveren) til timbre. Er det til hjelp kanskje?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))))
I am not getting the pun 😢
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
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/
Kan også anbefale @UDRBUPQGL sitt foredrag på ClojuTRE 2019 om PBT: https://youtu.be/xw8ZFU8CGdA
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.