Hey Peter, Responses are inlined.
On Tue, Jul 29, 2014 at 12:51 AM, Peter Taoussanis <ptaoussa...@gmail.com> wrote: > Wrt the CSRF issue, I'll try running again without it. >> > > Out of curiosity, sure - but if you've already gone to the effort of > setting up the CSRF I'd leave it in (better to have it) :-) > Yep, I agree ;) > > >> Now, a port changed fixed the issue for me. But before I passed in a >> *chsk-url-fn*, I was still getting a 404, even when trying with a >> browser (ie, using the correct port). >> > > Not sure about that, may be that something in your setup is tripping up > the default `chsk-url-fn`. Would appreciate a GitHub issue on it and I'll > take a closer look - may be a bug. > Ok, new github issues is here <https://github.com/ptaoussanis/sente/issues/58>. > > That 404 went away when I included the CSRF middleware. I still had to >> pass in a custom *chsk-url-fn*, but I could use it through the browser, >> for example. >> > > My guess is that the 404 is going away because you're passing in a custom > `chsk-url-fn`, not because of the CSRF middleware. I.e. it's a broken chsk > url that's causing the 404, not anything to do with the CSRF. > Actually, that 404 did go away when I included the CSRF middleware. And that's weird, I'll admit, because the webserver was not running on *ws://172.28.128.5:58269/chsk <http://172.28.128.5:58269/chsk>*. However, I was still experiencing the broken chsk channel. That's when I included the custom *chsk-url-fn*. The tricky thing, I think, is that the browser-repl uses a different port (i default browser-repl is 9000, ii. austin's browser-repl port changes each session), than the running http-kit server (8090). So when *make-channel-socket!* calls chsk-url-fn <https://github.com/ptaoussanis/sente/blob/65fcf8d9be14bfc69a7798b5c159780d1d2a3804/src/taoensso/sente.cljx#L850> (which is the *default-chsk-url-fn*), (encore/get-window-location) <https://github.com/ptaoussanis/sente/blob/65fcf8d9be14bfc69a7798b5c159780d1d2a3804/src/taoensso/sente.cljx#L843> is returning the URL with the browser-repl's port. I'm not sure how you'd get around that if you're using a browser-repl, vs just running in a plain browser runtime. Seems to come down to the behaviour of (.-location js/window) <https://github.com/ptaoussanis/encore/blob/master/src/taoensso/encore.cljx#L1187> (in *encore/get-window-location*). Ie, in my browser-repl, invoking `*(.-location js/window)*` gives me "http://*172.28.128.5:33283/347 <http://172.28.128.5:33283/347>*/repl/start?...", (not http://*172.28.128.5:8090 <http://172.28.128.5:8090>*/...). cljs.user> (.-location js/window) #< http://172.28.128.5:33283/347/repl/start?xpc=%7B%22cn%22%3A%222qJDPo7hur%22%2C%22tp%22%3Anull%2C%22osh%22%3Anull%2C%22ppu%22%3A%22http%3A%2F%2F172.28.128.5%3A8090%2Frobots.txt%22%2C%22lpu%22%3A%22http%3A%2F%2F172.28.128.5%3A33 \ 283%2Frobots.txt%22%7D> > And I'm just grokking the false `*websocket?`* allowance now. Ie, an >> https ajax connection would give me a sente URL of >> "*wws://172.28.128.5:8090/chsk >> <http://172.28.128.5:8090/chsk>*". Is that right? What about plain http? >> > > The `chsk-url-fn` will be called with: > 1. The path as given to the client-side `make-channel-socket!` fn (usu. > "/chsk"). > 2. A window location map of the current page. > 3. A bool indicating whether Sente is requesting a WebSocket (true) or > Ajax (false) connection. > > From these, your fn will need to produce an URL that matches your > server-side channel socket route. > > For WebSocket connections you'll want the URL to start with "ws://" > (insecure) or "wss://" (secure). > For Ajax connections you'll want the URL to start with "http://"; > (insecure) or "https://"; (secure). > > I wouldn't stress too much about that though - let's start with a GitHub > issue since it's quite possible I can mod the default fn to cover your > use-case automatically. Ideally you shouldn't need to fiddle with any of > this :-) > > Cheers! > > Nice one - thanks Peter. Tim Washington Interruptsoftware.com <http://interruptsoftware.com/> -- 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.
