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 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.
