You are probably hit by CORS, try to open webpage at the same host
http://localhost:6100/, see http://enable-cors.org/index.html
Check Network tab in Chrome dev tools.

Best regards,
Eduard


On Sun, Mar 2, 2014 at 7:16 PM, Mark <markaddle...@gmail.com> wrote:

> Hi Peter -
>
> I'm trying to learn Sente using the LightTable browser connected repl.  I
> try to evaluate the following code:
> (let [{:keys [chsk ch-recv send-fn]}
>       (sente/make-channel-socket! "http://localhost:6100/chsk"; ; Note the
> same URL as before
>          {})]
>   (def chsk       chsk)
>   (def ch-chsk    ch-recv)
>   (def chsk-send! send-fn))
>
> (put! ch-chsk "From client!")
>
> From the JS console, I see repeated, failed attempts to connect the
> server.  The server is running and responding to other http requests.
>
> Taking a very quick look at the source for the CLJS make-channel-socket!,
> it seems that it tries to resolve the url using the CLJS chsk-url function
> which, in turn, uses encore/get-window-location.  Since my browser window
> location is file://..., I think this is going to generate a bad url.  Am I
> reading the source correctly? Is there some way to make a channel socket by
> providing an absolute url?
>
> On Thursday, February 27, 2014 10:53:08 PM UTC-8, Peter Taoussanis wrote:
>>
>> Quick addendum: I've had a few folks ask about various security
>> implementations.
>>
>> So first up - as I mention in the REAME, I have had to make some changes
>> to the codebase for the public release so I wouldn't quite trust anything
>> pre-1.0 in production just yet (there's likely at least minor bugs). Having
>> said that, the general model has played out well in practice elsewhere.
>>
>> A few specifics that have come up:
>>
>>  * Tools.reader's read-string is used server-side, so arbitrary code
>> evaluation isn't an issue.
>>  * It _is_ possible for the server to receive malformed or hostile
>> requests (as it would be via any other protocol). The implementation itself
>> doesn't depend on the accuracy of any information provided by the client,
>> but the usual security measures will apply server-side for code you write:
>> only respond to well-formed requests, ensure users are
>> authenticated+authorised where appropriate, etc. Auth stuff is beyond the
>> scope of Sente, but it won't do anything to get in your way.
>>  * Ring session information _is_ made available server-side for all
>> requests (including WebSocket requests), so the commonest session-based
>> auth methods basically work out-the-box.
>>  * The client-side user-id *can* be forged, but it isn't used for
>> anything that's security sensitive. It's there only as an optimisation to
>> disable Ajax long-polling when a user clearly isn't logged in. If someone
>> were to fudge the id, the only negative effect would be an the creation of
>> an unnecessary long-polling connection that is never used (the server will
>> never acknowledge it).
>>  * HTTPS works seamlessly, even for WebSockets. When the page is served
>> over HTTPS, Sente will work over HTTPS.
>>  * CSRF protection is baked in, but you need to do a few things on your
>> end to enable it. A client-side warning will be printed when no CSRF code
>> is provided. Recommend checking out the example project for details (it
>> includes CSRF protection).
>>
>> So tl;dr - there's a bit going on, but nothing that's fundamentally
>> different from the usual Ring security model. Auth and CSRF are the
>> responsibility of the app as usual, but Sente provides hooks in the
>> appropriate places to plug in whatever you're using.
>>
>> Will try update the README later today with the info above.
>>
>> Hope that helps, happy Friday! :-)
>>
>> - Peter
>>
>  --
> 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 a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/5J4L8pbGwGU/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
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/groups/opt_out.

Reply via email to