Fork me on GitHub
#duct
<
2018-05-17
>
eoliphant00:05:50

Hi, I’m reading through the duct docs on configuration. It’s not clear to me, how you setup/handle production configuration, say setting db info in env vars, etc

weavejester00:05:50

@eoliphant Production settings that vary from machine to machine are typically passed in through environment variables, like DATABASE_URL for instance. However, you can use other mechanisms, since the configuration is just a map.

eoliphant00:05:25

ah ok, but what does DATABASE_URL map to/look like in my config file?

weavejester00:05:10

The duct.module/sql module uses it by default, similar to how the :duct.server.http/jetty key uses the PORT environment variable. You can use any environment variable you want, though, or any source of configuration you want.

weavejester00:05:31

#duct/env gives you an easy way of pulling in environment variables into the configuration

eoliphant00:05:15

ah yeah that’s what I was looking for.

eoliphant00:05:14

that reader is part of the core duct stuff ?

eoliphant00:05:34

sweet thanks

weavejester00:05:47

I plan on revisiting the docs, but I’m currently finding myself a little too busy with non-open-source work.

eoliphant00:05:49

You mind if I add a sentence or 2 to the wiki page about it?

weavejester00:05:56

No, please do

eoliphant01:05:26

ok will do, everything else was pretty clear, was just stuck on how to 12-factor this thing lol

willier01:05:16

hi, i’m trying to using the duct-buddy middleware as follows:

:duct.router/ataraxy {:middleware {:jws-auth #ig/ref :duct.middleware.buddy/authentication}}

 :duct.middleware.buddy/authentication
 {:backend :jws
  :secret  #duct/env "JWT_SECRET"}
and
[:post "/entries" {{:keys [description]} :body-params}]
  ^:jws-auth [:entries/create description]

  [:post "/users/login" {{:keys [email password]} :body-params}]
  [:users/login email password]

willier01:05:31

which lets me login OK

willier01:05:31

but http :3000 /entries returns 200 without any login

willier01:05:16

is this the correct way to apply the auth middleware to my /entries route?

weavejester01:05:56

Are you putting your routes in :duct.module/ataraxy or :duct.router/ataraxy?

willier01:05:39

:duct.module/ataraxy

willier01:05:09

full routes as follows:

;## === routes ===
 :duct.module/ataraxy
 {[:get "/"] [:index]

  [:get "/entries"]
  ^:jws [:entries/list]

  [:get "/entries/" id]
  ^:jws-auth [:entries/find ^int id]

  [:delete "/entries/" id]
  ^:jws-auth [:entries/destroy ^int id]

  [:post "/entries" {{:keys [description]} :body-params}]
  ^:jws-auth [:entries/create description]

  [:post "/users" {{:keys [email password]} :body-params}]
  [:users/create email password]

  [:post "/users/login" {{:keys [email password]} :body-params}]
  [:users/login email password]

weavejester01:05:38

I think I’ll need to look into this in more detail. Can you open a issue on the Duct Ataraxy module?

weavejester01:05:04

Other than that, you could try replacing the middleware with one that has debug information.

weavejester01:05:04

It might be an issue with Buddy, the Duct Buddy middleware, or Ataraxy, or the Ataraxy module. I’d need to run a few tests.

willier01:05:41

ok.. i’ll open the issue with details

willier01:05:11

how do i add a middleware for debugging?

weavejester01:05:49

You can add in your own middleware multimethod that wraps the Buddy middleware.

willier01:05:09

is the ^:jws-auth simply a tag on the route to identify what middleware to apply?

weavejester01:05:20

The Buddy middleware itself is pretty small:

weavejester01:05:45

Yes, the metadata tells Ataraxy which result to apply the middleware to.

willier01:05:04

ok.. will give that a shot then

willier01:05:40

which result?

weavejester01:05:13

Ataraxy maps routes to results

weavejester01:05:31

So in the context of Ataraxy, the result handler is the function the route maps to.

willier01:05:23

will report back later after some lunch 🙂

weavejester01:05:52

I’ll probably be asleep by then! 🙂

💤 4
👍 4
lambder09:05:48

I have the following problem: In my duct config I have jetty component which initialises ok, but there is another one which fails resulting in the whole system not initialised. Now, I can't fix the issue and do (reset) in repl as the jetty address is in use. How can we automatically shut down all the components when the system as a whole is not initialised?

weavejester12:05:04

What version of Duct/Integrant/Integrant-REPL are you using @lambder? I seem to remember that the latest versions had better recovery on errors.