Best practices when further customisation is needed

[danielsz]

It's nice to have the config map to tweak the defaults. But some middleware have further customisations. For example, suppose I want to provide a function to wrap-anti-forgery function. According to the docs:

This behavior can be customized further by supplying a function to the :read-token option. This function is passed the request map, and should return the anti-forgery token found in the request.

What is the best way to deal with this?

Should I set :security {:anti-forgery false}?

(def site
  (-> handler
  (wrap-anti-forgery {:read-token (fn [req] (-> req :params :csrf-token))})
  (wrap-defaults site-defaults-with-anti-forgery-set-to-false)))

Is there no risk of middleware getting out of order with this method?

[weavejester]

The README needs a bit of updating. The anti-forgery options can be customised the same as every other piece of middleware in Ring-Defaults, e.g.

:security {:anti-forgery {:read-token ...}}

[danielsz]

I had a look at the source, and my understanding is that customisation maps are just passed along to their relevant middleware, which makes it very flexible. Very cool.

What would be an idiomatic way to merge a customisation with the default config map, say site-defaults? assoc-in perhaps?

[weavejester]

assoc-in or merge or merge-with or whatever you want, really.

[danielsz]

Cool, thanks.