Wow, thank you! This makes a lot of sense, it sounds like I really do not
need CSRF protection.. I'm just adding complexity there..
I think my key mess up here was getting my client side / server side code
mixed up in my head. I am really enjoying using ClojureScript and Clojure
side by side, but yeah it makes sense that I can't use ring's libraries
inside a client side language. That's just something I'll have to keep in
mind.
I'm guessing if I was going to make use of CSRF in the future, I would drop
it into a meta tag on the server side, and then reference that meta tag
with javascript (that's how Laravel does it). ...but I'll cross that bridge
when I come to it.
Thanks!
Seth
On Friday, December 23, 2016 at 10:36:46 AM UTC-5, James Reeves wrote:
>
> The "use" function is a deprecated shortcut for "require" and "refer". I
> can see why it would be confusing, so I'll change the examples on the
> ring-anti-forgery site.
>
> Packages can contain many namespaces, so in general you won't find package
> names matching up precisely to the namespace or namespaces that they
> provide.
>
> Regarding CSRF protection, you firstly only need it if you have user
> authentication in your app. If that doesn't matter, you can turn it off.
>
> If you do have user authentication, then read on.
>
> It's difficult to produce a library that does everything automatically,
> because it requires cooperation between server-side and client-side code.
> Ring just handles the server-side, so it's up to you, or another library,
> to handle the client-side.
>
> I'm not sure how to explain the general functionality any better than the
> README of the project already does:
>
> Any request that isn't a HEAD or GET request will require an anti-forgery
>> token, or an "access denied" response will be returned. The token is bound
>> to the session, and accessible via the *anti-forgery-token* var.
>
>
>
> By default the middleware looks for the anti-forgery token in the
>> "__anti-forgery-token" form parameter, which can be added to your forms as
>> a hidden field.
>
>
>
> The middleware also looks for the token in the "X-CSRF-Token" and
>> "X-XSRF-Token" header fields, which are commonly used in AJAX requests.
>
>
> In terms of what that specifically means for you, you need to do two
> things:
>
> 1. Add the value of the *anti-forgery-token* somewhere your
> ClojureScript can find it.
>
> 2. Add the value to the "X-CSRF-Token" header each time you send an
> AJAX request.
>
> There may be libraries that handle the client-side for you. Maybe someone
> else can suggest one. The specifics really depend on how your app is put
> together.
>
> - James
>
>
> On 23 December 2016 at 14:39, Seth Archambault <seth...@gmail.com
> <javascript:>> wrote:
>
>> So when I use cljs-ajax to post to my APP I get an Invalid anti-forgery
>> token error.
>>
>> Despite there being dozens of posts about this issue, none of them have a
>> solution that seems to work if you started your project using this:
>>
>> lein new reagent myapp
>>
>> The first post that comes up as a "solution" actually recommends
>> disabling CSRF protection, which seems like just avoiding the problem
>> rather than solving it, but they don't actually tell you how to do that
>> either!
>>
>> After 4 hours of searching for any solution, I admit that the only fix
>> that I found was this:
>>
>> (ns reformdems.middleware
>> (:require [ring.middleware.defaults :refer [site-defaults
>> wrap-defaults]]
>> [ring.middleware.json :refer [wrap-json-params]]
>> [prone.middleware :refer [wrap-exceptions]]
>> [ring.middleware.reload :refer [wrap-reload]]))
>>
>> (defn wrap-middleware [handler]
>> (-> handler
>> (wrap-defaults (merge site-defaults {:security {:anti-forgery
>> false} :params {:keywordize true}}))
>> wrap-exceptions
>> wrap-reload
>> wrap-json-params))
>>
>>
>> By setting :security :anti-forgery to false, I no longer get the
>> Anti-Forgery issue. But yeah, this isn't a real solution.
>>
>> What I'm looking to do is get one of the solutions involving
>> "*anti-forgery-token*"
>> or (anti-forgery-field) working.
>>
>> Unfortunately, these instructions here, don't work, and only produce hard
>> to understand errors:
>> https://github.com/ring-clojure/ring-anti-forgery
>>
>> As a side note, it's really confusing when all the libraries use this
>> language:
>>
>> (use 'ring.util.anti-forgery)
>> (anti-forgery-field)
>>
>>
>> Meanwhile "use" is not in any of the code generated using lein. I would
>> expect this would be the proper way to use the libraries:
>>
>> (ns myapp.server
>> (:require
>> [ring.util.anti-forgery) :refer [anti-forgery-field]]))
>>
>> Of course, I'm just guessing at that refer command, but my point is this
>> inconsistency makes me feel like I'm looking at solutions designed for an
>> older version of Clojure or something?
>>
>> I'm also concerned that given a library [ring/ring-anti-forgery "1.0.1"]
>> there is no way to intuitively know how to "require" that library in your
>> code. In the above situation the word "util" gets added when requiring it..
>>
>>
>> *Anyways, my main question is this:*What is the modern way to do CSRF
>> protection?
>>
>> Secondly, I'm concerned I'm doing something wrong - ring.middleware feels
>> like a magical thing where you apply wrappers, and then stuff just
>> magically works. I'm not a big fan of magic, I want to be able to see a
>> pathway for finding a solution, not just google around and figure out a
>> wrapper needs to be added.. Any recommendations on that front?
>>
>> Thanks!
>> Seth
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com
>> <javascript:>
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com <javascript:>
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+u...@googlegroups.com <javascript:>.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
