Clojurians Log v2

For reference here is my setup, (working with an electric app):

(defn wrap-oauth-landing [next-handler]
  (fn [{:keys [uri request-method] :as request}]
    (let [signature [uri request-method]]
      ;(println request)
      ;(println "session" (:session request))
      ;(println (:oauth2/access-tokens request))
      (cond
        (= signature ["/oauth2-landing" :get]) (handle-sign-in request)
        :default (next-handler request)))))

(defn http-middleware [config]
  ;; these compose as functions, so are applied bottom up
  (-> not-found-handler
      (wrap-index-page config)                              ; 3. otherwise fallback to default page file
      wrap-oauth-landing
      (wrap-oauth2 {:cognito
                    {:authorize-uri    ""
                     :access-token-uri ""
                     :client-id        "13dbhvme9fpl6nf31vuaea36rm"
                     :client-secret    "3suph700u9sb5hgnqm8kdmu6a5q81ejc6t1nbn0m91q7ejl1ur6"
                     :scopes           ["openid", "email"]
                     :launch-uri       "/oauth2"
                     :redirect-uri     "/oauth2-return"
                     :landing-uri      "/oauth2-landing"
                     }})

      (wrap-defaults (-> site-defaults (assoc-in [:session :cookie-attrs :same-site] :lax)))
      (wrap-params)

      ;(wrap-defaults (-> site-defaults (assoc-in [:session :cookie-attrs :same-site] :lax)))
      (wrap-resource (:resources-path config))              ; 2. serve static file from classpath
      (wrap-content-type)                                   ; 1. detect content (e.g. for index.html)
      ))

Are sessions working?

:session
{:ring.middleware.oauth2/state "_185OoSSPpg9",
:ring.middleware.anti-forgery/anti-forgery-token
"VBBVX4ELanEb2gRTW3+qUboEaMWh7pDSqQ9giyTgsIKl/Vm46rdRbAcXpt1LDkOD9N08XRMeAEck1iWz"}}

Yep the session looks something like the above

Like if you store a uuid in the session if one is not already there, an print it out every request, do you always see the same one

That tells you you have a session, which is good, but the real question is if the session is properly persistenting state between requests

I'll do a quick check

The default session store is just an in memory map, so for example if you are load balancing between servers and don't have any kinds of session affinity at the load balancer you'll get balanced between nodes that aren't aware of your session

This all running locally so it shouldn't be impacted by that. But I think site-defaults sets sessions to be cookie based

Session seems to be working fine using that test you suggested

Hmmm, actually just saw an issue that the cookie isn't being set because it's too long. Wonder why that is

using a cookie for the session store can result in an unbounded cookie size 😕

Hmm weird that it defaults to that

you can try and insert a custom middleware to log the session before it gets serialized as a cookie, but annoying to get in the right place when using wrap-defaults

the size of the cookie depends entirely on the size of the :session map when serialized

That was the problem, switching to in memory store fixed the issue. Frustrating that this silently failed but that's on the browser not on anyone's code here

This is a test app, so for now I'll just stick to an in-memory session store

Thanks for helping me debug that @hiredman!

👍