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

@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.

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

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.

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

ah yeah that’s what I was looking for.

that reader is part of the core duct stuff ?

Yep

https://github.com/duct-framework/core/blob/0.6.2/src/duct/core.clj#L65

sweet thanks

np

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

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

No, please do

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

You can see an example of #duct/env being used here: https://github.com/walkable-server/realworld-fulcro/blob/master/resources/conduit/config.edn

ah perfect

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"}

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

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

which lets me login OK

but http :3000 /entries returns 200 without any login

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

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

:duct.module/ataraxy

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]

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

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

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.

ok.. i’ll open the issue with details

how do i add a middleware for debugging?

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

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

The Buddy middleware itself is pretty small:

https://github.com/duct-framework/middleware.buddy/blob/master/src/duct/middleware/buddy.clj

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

ok.. will give that a shot then

which result?

Ataraxy maps routes to results

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

oh ok

thanks

will report back later after some lunch 🙂

I’ll probably be asleep by then! 🙂

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?

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