This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-07-04
Channels
- # announcements (10)
- # asami (6)
- # babashka (22)
- # beginners (44)
- # biff (1)
- # calva (8)
- # clj-kondo (13)
- # clojure (62)
- # clojure-art (1)
- # clojure-europe (27)
- # clojure-nl (1)
- # clojure-norway (19)
- # clojure-spec (19)
- # clojure-uk (2)
- # component (29)
- # datascript (1)
- # fulcro (9)
- # gratitude (2)
- # kaocha (6)
- # klipse (1)
- # luminus (16)
- # malli (9)
- # nbb (5)
- # off-topic (4)
- # reagent (5)
- # shadow-cljs (85)
- # spacemacs (1)
- # tools-deps (10)
- # vim (9)
- # xtdb (2)
Hello! I’m diving into Luminus to build a little web application that we and our guests/pet sitters will be able to use to control our automated blinds in a more flexible and granular way than the manufacturer supports, and I have the basic proof of concept up and running. I have run into a few snags that I hope people can help me sort out. I set up a Postgres-backed session store, and configured my sessions to not expire, the hope being that people would be able to log in once and not be bothered again. However, whenever I restart the application, my session seems to disappear, even though I can still see the row in Postgres, and the matching cookie in my browser. Any idea why this might be happening? My source, as it stands so far, is here: https://github.com/brunchboy/shade
Another problem I have run into is that when I try to have CSRF protection enabled, by commenting out the line in middleware.clj
that disables anti-forgery protection, my login form (onto which I have added the CSRF hidden field) works once, but after logging out, it gives me an Invalid CSRF Token when I try to log back in, even though the token in the form field seems to match what I see in the session and database. Quite frustrating, although to be honest I don’t really need CSRF protection… I just like to follow best practices by default.
I feel the problem here is that session should be regenerated when user log in or out, hence the CSRF token cannot survive across session change or user change
I'm not entirely sure but feel this is related: https://github.com/ring-clojure/ring/wiki/Sessions
If you simply want to recreate the session, due to a privilege escalation for example, add the :recreate key to the session metadata. This will cause the session identifier that is sent to the browser to change.
If you dont use new session id upon user id change then csrf should not fail. i think...
I am not logging out, though, and I don’t want the session ID to change. I simply want the session to work reliably, even if the server reboots.
I opened an issue on the jdbc-ring-session
repository and yogthos was kind enough to identify the problem. Somehow in following the sample code I had ended up with two session wrappers that were battling each other. Getting rid of the extra one made things work the way I had intended. Here are the details if anyone is struggling with something similar: https://github.com/luminus-framework/jdbc-ring-session/issues/19
I thought I figured this out before… but I’m stuck. I have a POST endpoint in an Undertow/Luminus app, and when I hit the endpoint from a REST client, it works fine. However, when it is called as a webhook from Stripe, the :body
of the request is not text or json as expected, but rather #object[io.undertow.io.UndertowInputStream 0x4beea469 "
Could this be a hint https://github.com/ring-clojure/ring/wiki/File-Uploads
Hmm, except this is just a json payload
normally json payload results in a string :body not an object :body. Either Stripe or Ring did something wrong I guess
I can access the parameters and the data but when I try to access the body itself so that I can calculate the encryption signature that’s when I had the issue. Otherwise I can access the parts of the payload that I need
I’m using the wrap-formats
middleware for this endpoint
I thought slurp
was the solution, but I’m getting the Stream is closed
exception.