Fork me on GitHub
#re-frame
<
2020-03-29
>
ray17:03:22

I just discovered that upgrading sente from 1.13.x to 1.15.x broke my reframe app and it seems that @danielcompton was one of the reporters. The fix is expressed in an https://github.com/ptaoussanis/sente/blob/548af55c5eb13a53e451b5214f58ecd45f20b0a5/example-project/src/example/server.clj#L69 that I don’t understand and especially I don’t know how to translate to reframe. I could spend a lot more time on it but wondering if anyone here has had to update sente recently and have some tips?? Thanks

p-himik18:03:05

You have to supply a CSRF token when calling sente/make-channel-socket-client!, and make sure that this token is validated with csrf-token-fn function that's passed to sente/make-channel-socket-server!. That's it.

ray19:03:17

oh so I can decide what both the parts are … sweet. That’s a really great explanation @U2FRKM4TW - thanks!!

👍 4
Pavel Klavík02:03:32

Maybe you already solved this, but let me add some details. I use the default csrf-token implementation in my ring application. On the server side, I don't really have to do anything since the csrf token for the session is read is added by the server to the request, so it can be checked by Sente. On the client side, I am passing this token as part of the html page, and it gets read by the client from there and passed to Sente when creating the connection. This is what the line 69 you quoted does.

Pavel Klavík02:03:10

The default csrf-token-fn looks like this and should be fine:

(fn [ring-req]
  (or (:anti-forgery-token ring-req)
      (get-in ring-req [:session :csrf-token])
      (get-in ring-req [:session :ring.middleware.anti-forgery/anti-forgery-token])
      (get-in ring-req [:session "__anti-forgery-token"])
      #_:sente/no-reference-csrf-token
      ))