This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-09-27
Channels
- # beginners (34)
- # boot (15)
- # cider (7)
- # cljs-dev (7)
- # cljsjs (2)
- # cljsrn (46)
- # clojure (130)
- # clojure-argentina (1)
- # clojure-colombia (2)
- # clojure-greece (1)
- # clojure-italy (53)
- # clojure-losangeles (1)
- # clojure-russia (15)
- # clojure-spec (8)
- # clojure-uk (100)
- # clojurescript (117)
- # core-matrix (1)
- # cursive (24)
- # datomic (41)
- # duct (1)
- # emacs (11)
- # fulcro (22)
- # graphql (4)
- # hoplon (3)
- # jobs (1)
- # lein-figwheel (3)
- # luminus (18)
- # lumo (52)
- # off-topic (57)
- # pedestal (2)
- # planck (12)
- # re-frame (22)
- # remote-jobs (1)
- # ring-swagger (6)
- # rum (7)
- # shadow-cljs (13)
- # yada (19)
There don't seem to be any docs, either on the website, or in the book, on how to use the ajax file that comes with the luminus template.
Is it as simple as calling load-interceptors at some point in your application prior to making ajax calls?
It also seems to me that js/csrfToken wouldn't even work in advanced compilation mode.
So is the ajax file from the template even useful, if using advanced compilation mode?
the ajax namespace is just there to setup the interceptors, you don’t really need to do anything with it unless you wish to add more inteceptors
Thanks. What are the rules about which js/* forms get mangled by advanced and which don't? I thought almost nothing was safe from advanced.
I'm working with a company who will be including my luminus site inside of an iframe. Currently, they are getting an error that x-frame-options is set to same origin. I'm researching how to address this, and it looks like there is some ring middleware to allow specific origins, but there are all sorts of warnings that allow-from isn't supported by certain browsers. I'm not sure what that means that it is not supported -- does it mean browsers like Chrome won't be able to load the iframe or they will. Next, I see some talk about Chrome supporting something called CSP instead. Is there some unified way of dealing with all of this?
setting (header "Access-Control-Allow-Origin" "origin")
where origin is the host should address that
if you’re using ring-defaults, you also have to create your own defaults with different :frame-options
:security {:anti-forgery false
:xss-protection {:enable? true, :mode :block}
:frame-options :sameorigin
:content-type-options :nosniff}
What you listed above, is that the existing default, or what you are recommending I change to?
Looks like the luminus template sets :anti-forgery to false, handling the anti-forgery in a separate piece of middleware instead. :xss-protection, :frame-options, and :content-type-options stay the same as the default, which is what you listed above.
Do you happen to know whether the X-Frame-Options: ALLOW-FROM http://mycompany.com header would prevent the frame from including it if the user had used https?
Since several browsers do not respect ALLOW-FROM, have you tried using frame-ancestors instead, with ring/luminus? https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/frame-ancestors