(wrap-defaults app site-defaults)
(deftype SessionStrategy []
strategy/Strategy
(get-token [this request]
(or (session-token request)
(random/base64 60)))
(valid-token? [_ request token]
(when-let [stored-token (session-token request)]
(crypto/eq? token stored-token)))
(write-token [this request response token]
(let [old-token (session-token request)]
(if (= old-token token)
response
(-> response
(assoc :session (:session response (:session request)))
(assoc-in
[:session :ring.middleware.anti-forgery/anti-forgery-token]
token))))))
(deftype MemoryStore [session-map]
SessionStore
(read-session [_ key]
(@session-map key))
(write-session [_ key data]
(let [key (or key (str (UUID/randomUUID)))]
(swap! session-map assoc key data)
key))
(delete-session [_ key]
(swap! session-map dissoc key)
nil))
--
You received this message because you are subscribed to the Google Groups "Ring" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ring-clojure...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ring-clojure/2e700abc-0aec-4474-a853-ed8bebe3ffc5%40googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to ring-c...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ring-clojure/2e700abc-0aec-4474-a853-ed8bebe3ffc5%40googlegroups.com.
--James Reeves
To unsubscribe from this group and stop receiving emails from it, send an email to ring-clojure...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ring-clojure/2a12a8fd-31fe-4522-b5d3-b706ea4ab38f%40googlegroups.com.
(deftype SessionStrategy []
strategy/Strategy
(get-token [this request]
(or (session-token request)
(random/base64 60)))
(valid-token? [_ request token]
(when-let [stored-token (session-token request)]
(crypto/eq? token stored-token)))
(write-token [this request response token]
(let [old-token (session-token request)]
(if (= old-token token (session-token response))
response
(-> response
(assoc :session (:session response (:session request)))
(assoc-in
[:session :ring.middleware.anti-forgery/anti-forgery-token]
token))))))
(defn- zeng [handler prompt]
(fn [req]
(do (prn (format "\033[1;31m===== enter %s\033[m" prompt)) (pp/pprint req))
(let [result (handler req)]
(do (prn (format "\033[1;32m===== exit %s\033[m" prompt)) (pp/pprint result))
result)))
(defn wrap-defaults
[handler config]
(-> handler
(zeng "handler")
(wrap anti/wrap-anti-forgery (get-in config [:security :anti-forgery] false))
(zeng "anti-f") ...))
To view this discussion on the web visit https://groups.google.com/d/msgid/ring-clojure/2a12a8fd-31fe-4522-b5d3-b706ea4ab38f%40googlegroups.com.
--James Reeves
Thanks for the tip. I think I got it this time.Essentially every middleware and handler behind `session` middleware in the processing flow can save their info under :session key in response map which got saved/restored by `session` middleware.What I didn't realize was that anti-forgery's own stuff can be affected by middleware/handler behind it.How do you think about this code, is it correct to always attach the current token to response map?
Off topic: here is how I dump the req/resp maps left and right to troubleshoot. It's just nice that source code is available I just need to save it to my project and reference this. What's the better way?
On Fri, 22 Nov 2019 at 04:55, Xinhui ZENG <zen...@gmail.com> wrote:Thanks for the tip. I think I got it this time.Essentially every middleware and handler behind `session` middleware in the processing flow can save their info under :session key in response map which got saved/restored by `session` middleware.What I didn't realize was that anti-forgery's own stuff can be affected by middleware/handler behind it.How do you think about this code, is it correct to always attach the current token to response map?I don't understand what you're aiming to achieve with the code you posted.
Off topic: here is how I dump the req/resp maps left and right to troubleshoot. It's just nice that source code is available I just need to save it to my project and reference this. What's the better way?That's a reasonable way of checking the request and response. You could also use a debugger, if your editor/IDE supports one.
--
You received this message because you are subscribed to the Google Groups "Ring" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ring-clojure...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ring-clojure/CALg24jSJXKoJ8bqB%3D8MG9QbC5ZYccUkq1NXYxmcfFDu1en9WaA%40mail.gmail.com.
On Fri, Nov 22, 2019 at 9:04 AM James Reeves <ja...@booleanknot.com> wrote:I don't understand what you're aiming to achieve with the code you posted.Perhaps it's clearer to see them side by side. The extra test completes the idea that `anti-forgery` will take care of the it's own stuff: the injection of :ring.middleware.anti-forgery/anti-forgery-token into :session of a resp map.Three scenarios:a) When `anti-forgery-token` is not present in :session of a req map:
this part of test `(= old-token token ...)` fails and at that point middleware will proceed to inject `anti-forgery-token` into :session of a resp map.b) When `anti-forgery-token` is not present in :session of a resp map:this is what got me to start this conversation. Is it reasonable in your opinion to inject the token when the token is missing from resp map?
----James Reeves
You received this message because you are subscribed to the Google Groups "Ring" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ring-clojure...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ring-clojure/CALg24jQz92DMjbp0srvOWUP%3Dx0wmfLrg_Po5Mjaeps%3DTa_%3DNOQ%40mail.gmail.com.
On Fri, Nov 22, 2019 at 11:14 AM James Reeves <ja...@booleanknot.com> wrote:On Fri, 22 Nov 2019 at 15:49, Xinhui ZENG <zen...@gmail.com> wrote:On Fri, Nov 22, 2019 at 9:04 AM James Reeves <ja...@booleanknot.com> wrote:I don't understand what you're aiming to achieve with the code you posted.Perhaps it's clearer to see them side by side. The extra test completes the idea that `anti-forgery` will take care of the it's own stuff: the injection of :ring.middleware.anti-forgery/anti-forgery-token into :session of a resp map.Three scenarios:a) When `anti-forgery-token` is not present in :session of a req map:
this part of test `(= old-token token ...)` fails and at that point middleware will proceed to inject `anti-forgery-token` into :session of a resp map.b) When `anti-forgery-token` is not present in :session of a resp map:this is what got me to start this conversation. Is it reasonable in your opinion to inject the token when the token is missing from resp map?It's an interesting idea, but I don't think it's a route we should go down. It's a slippery slope to try and automatically correct or work around developer mistakes. In the best case, you're encouraging people to use sessions incorrectly; in the worst case, you're introducing behaviour that will break existing systems.However, I think it is worth considering how to make sessions easier to work with, or improving the documentation on sessions.I agree with everything you say except I feel the extra test should not break stuff because while the data under :session is shared but this particular one `anti-forgery-token` only belongs to anti-forgery middleware working like a reserved key. The test (= old-token token) of existing code does the same work updating `anti-forgery-token` regardless of what :session in a resp map says. This is due to in principle we have layered middleware/handler approach in ring and different than the misuse of how :session should be updated.
On Fri, Nov 22, 2019 at 11:14 AM James Reeves <ja...@booleanknot.com> wrote:On Fri, 22 Nov 2019 at 15:49, Xinhui ZENG <zen...@gmail.com> wrote:b) When `anti-forgery-token` is not present in :session of a resp map:this is what got me to start this conversation. Is it reasonable in your opinion to inject the token when the token is missing from resp map?It's an interesting idea, but I don't think it's a route we should go down. It's a slippery slope to try and automatically correct or work around developer mistakes. In the best case, you're encouraging people to use sessions incorrectly; in the worst case, you're introducing behaviour that will break existing systems.However, I think it is worth considering how to make sessions easier to work with, or improving the documentation on sessions.
I agree with everything you say except I feel the extra test should not break stuff because while the data under :session is shared but this particular one `anti-forgery-token` only belongs to anti-forgery middleware working like a reserved key. The test (= old-token token) of existing code does the same work updating `anti-forgery-token` regardless of what :session in a resp map says. This is due to in principle we have layered middleware/handler approach in ring and different than the misuse of how :session should be updated.