@mgrbyte The problem is that you’re adding the middleware from scratch each time a request is being received.

@mgrbyte And because session storage is in-memory by default, you’re clearing the session store each time a request is received.

Instead of:

(defn my-handler [request]
  (let [handler (-> app-routes
                    (wrap-defaults site-defaults))]
    (handler request)))

You want something like:

(def my-handler
  (-> app-routes
      (wrap-defaults site-defaults)))

@weavejester how could I not see that! thank you! 🙂

In my "real" app, the reason for this is the design of my handlers

No problem. Sorry it took me so long to reply.

they all take a datomic db object that's got on each request, so using 'def' isn't an option with my current scheme

Have you considered using a closure instead?

need to find a way to inject the db val into each handler, or simply have each handler use (d/db conn) rather than passing it in

So something like:

(defn app-routes [conn]
  (routes
   (GET …)))

(defn make-handler [conn]
  (-> (app-routes conn)
      (wrap-defaults site-defaults)))

I tend to use the term “endpoint” to denote a function that returns a handler.

:thumbsup:

thanks again @weavejester , sometimes can't see wood from 🌳

np 🙂

hey I have a question regarding sessions, it seems like if I'm not specifically setting a session key the session/cookie (I'm using a cookie store) is cleared but if I do set it, the expiration of the cookie is reset every time, is both of these expected behavior?

I think I got confused thinking the wrap-session middleware with a cookie-store supports the same options as wrap-cookie (ie. max-age) but I think I still see behavior where if I don't set a key on a session it is nil even if it was set before, is that correct? also then do we have to manually expire sessions?

@owen the cookie sessions should expire when the cookies expire, or when the encryption key is changed.