Hi Timothy, I just wanted to note that you can control the port Austin uses through environment variables. I do this so I can port forward, for example.
This probably won't help you though, as httpkit and the browser repl can't run on the same port. On 30 Jul 2014 16:24, "Timothy Washington" <twash...@gmail.com> wrote: > 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. > -- 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.
