This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-04-05
Channels
- # beginners (23)
- # boot (84)
- # braid-chat (2)
- # bristol-clojurians (1)
- # cider (53)
- # cljs-dev (34)
- # cljsrn (13)
- # clojure (138)
- # clojure-dusseldorf (5)
- # clojure-italy (1)
- # clojure-russia (164)
- # clojure-uk (41)
- # clojurescript (80)
- # clr (2)
- # core-async (6)
- # core-logic (25)
- # core-matrix (14)
- # cursive (10)
- # data-science (4)
- # datomic (4)
- # emacs (3)
- # funcool (6)
- # hoplon (127)
- # jobs-discuss (4)
- # keechma (36)
- # ldnclj (5)
- # lein-figwheel (5)
- # off-topic (5)
- # om (155)
- # onyx (72)
- # overtone (16)
- # parinfer (39)
- # planck (3)
- # protorepl (1)
- # re-frame (11)
- # reagent (5)
- # untangled (22)
Started building server exercises. Got the first one working…it is kinda neat seeing the app state update with markers as load happens
I went ahead and added some datomic testing to the tutorial…including the above discussion points about with-db-fixture
OK,almost done….anyone working on the tutorial should probably re-clone (or at least hard reset develop/master to origin after a fetch). I wanted to rewrite the repo because I had a bum email address in a lot of commits. Didn’t realize I had an old work email configured.
nice!
Is there a good example on how to setup authorization using the untangled-server? I am trying to setup authorization policies, and would like each api read and mutate function to call a policy before doing any work. If you are unauthorized to read an entity, say, the policy would throw an exception and the api would return a 401. From what I've read so far, it seems the only way to pass through the status code is to throw an ex-info with the status, headers, and body. Does this seem correct? https://github.com/untangled-web/untangled-server/blob/master/src/untangled/server/impl/components/handler.clj#L69
@kenbier: yes, that is correct
your mutation does the authorization check
if it finds that the action isn’t authorized, then you write something like (throw (ex-info “message” {:status 401})
. you can include more information in the body and custom headers of the response if you want to, but you aren’t required to provide those keys. if you don’t return any of :status, :body, or :header, then the server will throw a 400 by default
@ethangracer: so do you guys do anything untangle-y in your devcards? Or just use devcards the same way a vanilla om.next app would?
haven’t played a ton with devcards more recently, but when i’ve written them I’ve used it the same way as om.next
cool, thanks