This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-09-22
Channels
- # alda (1)
- # aws-lambda (23)
- # beginners (27)
- # boot (156)
- # business (2)
- # carry (4)
- # cider (1)
- # cljsjs (2)
- # cljsrn (29)
- # clojure (170)
- # clojure-austin (35)
- # clojure-czech (8)
- # clojure-dusseldorf (5)
- # clojure-italy (4)
- # clojure-nl (1)
- # clojure-quebec (2)
- # clojure-russia (45)
- # clojure-spec (49)
- # clojure-uk (12)
- # clojurescript (81)
- # component (5)
- # datomic (24)
- # devcards (26)
- # emacs (4)
- # hoplon (4)
- # jobs (1)
- # juxt (5)
- # leiningen (6)
- # luminus (14)
- # mount (26)
- # om (27)
- # om-next (2)
- # onyx (22)
- # pedestal (2)
- # planck (3)
- # proton (5)
- # re-frame (19)
- # reagent (2)
- # ring-swagger (60)
- # spacemacs (12)
- # specter (8)
- # untangled (119)
- # vim (61)
- # yada (36)
I just introduced compojure-api to a project where I already used compojure, it's super awesome! I'm wondering about one thing though: as wrap-routes is not included in compojure-api (and compojure's one doesn't produce docs), what's the suggested way of wrapping a set of routes with authentication middleware so it can still match routes defined after it?
I know about :middleware attr in GET/POST/...
macros, but that would be a lot of repetition, and context
doesn't help me here too
I made it working by wrapping them in context "" [] :middleware [...]
and placing this context at the end of route definitions
which is okay-ish, but if I really wanted to add another non-wrapped route after it then it wouldn't be reachable because middleware would handle the req and return 401
to be clear I don't have foo
, bar
literally 🙂 but I just don't have common subpath
I would use the endpoint :middleware
. Bit more to type but works. We usually have had separate contexts for routes with different auth-requirements. wrap-routes
could be wrapped too, but is not currentky.
@sickill context ""
doesn't work as you assume
(routes (context "" [] :middleware [foo] ...) (GET "/bar" req ...))
foo middleware would be run for /bar request
because all requests will match that context and middleware will be run for any request that matches the context
yep, that should work, it just is quite error prone
hmm wrap-routes works?
should be fixable, we already do similar hack to enable :middleware for single routes
(check the route match before running middleware)
(btw, excellent work guys, thanks for compojure-api, swagger and other great stuff you released /cc ikitommi deraen )
Thanks
Hmm, I'm trying to remember how single route :middleware works currently
Ah: https://github.com/metosin/compojure-api/blob/master/src/compojure/api/meta.clj#L328
we use wrap-routes 😄
is there a way to enable basic auth for API requests in swagger-ui? I'm talking about securityDefinitions
key in compojure-api's {:swagger ...}
metadata
I saw people adding some js/jquery code to index.html, but I'm just using it via compojure-api so don't have direct access to html file
http://swagger.io/specification/#securityDefinitionsObject yes, set :type "basic"
hmm, we are probably missing example about setting securityDefitions
..
but you can set it under :swagger :data
beside :info
and tags
https://github.com/metosin/compojure-api/wiki/Swagger-integration#authentication--authorization has an example. Feel free to contribute to docs if something is missing.
there: https://github.com/metosin/compojure-api/wiki/Swagger-integration#authentication--authorization
ouch, is there a way to tell UI to not require username for :type "basic"
? I use basic auth to send API token in password field, leaving username empty... 😉
nevermind, I can actually type anything as the username in my API and it gets ignored, so this works fine
I wonder if we should use similar middleware parameter format like our middleware
macro
also... why is our middleware
macro instead of just function
list of middleware (as in your middleware
) is more convenient/easier to use/understand than how wrap-routes
does it (where you need to explicitly compose middleware by yourself)
but then, if it accepted different args than compojure's wrap-routes
it would be confusing for people
we could also use wrap-routes
for our middleware
but that would be a breaking change
or we could provide wrap-middleware
instead of wrap-routes
which uses same kind of parameters as middleware