This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-03-11
Channels
- # admin-announcements (20)
- # beginners (48)
- # boot (90)
- # cider (33)
- # cljs-dev (5)
- # cljsjs (10)
- # cljsrn (7)
- # clojure (68)
- # clojure-austin (5)
- # clojure-bangladesh (4)
- # clojure-finland (10)
- # clojure-gamedev (1)
- # clojure-madison (7)
- # clojure-poland (15)
- # clojure-russia (75)
- # clojurescript (25)
- # core-async (23)
- # cursive (5)
- # data-science (43)
- # datomic (15)
- # dirac (26)
- # editors (10)
- # emacs (2)
- # euroclojure (12)
- # funcool (23)
- # hoplon (7)
- # immutant (68)
- # jobs (24)
- # jobs-discuss (1)
- # juxt (1)
- # keechma (9)
- # ldnclj (7)
- # luminus (66)
- # off-topic (54)
- # om (170)
- # proton (7)
- # re-frame (1)
- # reagent (15)
- # ring-swagger (11)
- # spacemacs (6)
- # testing (1)
- # vim (1)
- # yada (19)
I tried to hook up SSL with Immutant web but Chrome complains with “ERR_SSL_VERSION_OR_CIPHER_MISMATCH “. I can’t find a way to define suites. Am I overlooking something? (not done anything with ssl before …)
hey everyone, I am trying to use the immutant/web component 2.1.3. When I start up a repl and require the immutant.web
ns, i get this error --
Exception namespace 'potemkin.utils' not found clojure.core/load-lib (core.clj:5380)
anyone seen this? I've added org.immutant/web "2.1.3"
in my project deps. also tried adding all of immutant to the deps but same error.
i know potemkin is a dep for immutant, but I shouldnt be needing to add it manually right? I ran lein deps dint help
found the reason - potemkin.utils compile was failing as it needed the vector
symbol from the clj-tuple lib, and for some reason my project was pulling in a lower version of clj-tuple that dint have it. Fixed it by explictly adding the latest clj-tuple as a dep
does someone how i could check for a subprotocol before accepting a client websocket connection? (with immutant)
@moizsj: we don't expose the subprotocol currently, but I think we could make it part of the request map for upgrades - would you mind filing an issue for that? https://jira.jboss.org/jira/secure/CreateIssue.jspa?issuetype=2&pid=12311821
@tcrawley: thanks for the answer. as a workaround, I plan to write a custom version of the as-channel
method that will inspect the headers from the request map to check the subprotocol. it'll pretty much be a copy except the header check. do you have any better ideas for a workaround?
do you need a custom as-channel if you are inspecting headers? can't you just look at the headers in the request map, and decide to call as-channel or not based on those?
@tcrawley: what I need is a way to get in the middle of the handshake between the server and client. I need to check the header for subprotocol, then add the Sec-WebSocket-Protocol
header to the response (and some other custom headers). And if it goes through, only then would i want the :on-open
to be called
we are using http-kit at the moment and we had to write a similar custom with-subproto-channel
macro (similar but not same) as the with-channel
macro of http-kit. And now trying to port to immutant/web
ah, that's tougher - in http-kit, you have more access to the upgrade process. In Immutant, that's hidden - we had to do that to be able to support WildFly. If you plan to just use Immutant outside of the container, you could probably do it with a custom Undertow HttpHandler
(defmacro with-channel
[request ch-name & body]
`(let [~ch-name (:async-channel ~request)]
(if (:websocket? ~request)
(if-let [key# (get-in ~request [:headers "sec-websocket-key"])]
(do (.sendHandshake ~(with-meta ch-name {:tag `AsyncChannel})
{"Upgrade" "websocket"
"Connection" "Upgrade"
"Sec-WebSocket-Accept" (accept key#)})
~@body
{:body ~ch-name})
{:status 400 :body "Bad Sec-WebSocket-Key header"})
(do ~@body
{:body ~ch-name}))))
the custom part (which I cant post here) is checking headers for subprot, then augmenting the headers map handed out to the sendHandShake
@tcrawley: would you kindly elaborate a bit on your suggestion? what do you mean by Immutant without a container? And when you say using an Undertow Handler, is that something that'll need to written in Java? And i assume wont be Ring compatible?
Immutant supports two modes of deployment: an uberjar (just like you do with http-kit), and as a special war file to a WildFly or EAP application server
in the first case, we interact directly with the Undertow web server. in the container case, we have to interact with the servlet api, so have different implementations for websockets
because of that, your ring handler isn't called during the ws handshake, but after it is completed (undertow would allow us to do it during the handshake, but the servlet api does not)
so you would have to write a custom HttpHandler that handled the upgrade process. you could write it in clojure using proxy or reify
the servlet websocket api is terrible, and I hate that it puts this limitation on us
so suppose I wrote the HttpHandler and the aync api dint work , could i still build some Compojure routes, pass the handler (of the routes) to the run
, and one of those routes explicitly dealt with upgrades ("/xyz/websock")? would that work?
in that ws-handler, I'd need to callback into equivalents of :on-open, :on-message, :on-close
you couldn't nest the HttpHandler route under compojure, but could do (run compojure-app :path "/") (run http-handler :path "/websock")
let me take a look at the code to see if it would be possible to insert a handler in the chain that would allow you to use one run call and still use async
@moizsj: actually, hmm. outside of the container, we do call your ring handler before calling the upgrade handler, and only call the upgrade handler if your ring-handler returns the result of as-channel
in your above code, are you ensuring the sec-websocket-key is set before letting the upgrade continue?
or is there some back and forth between the client and server during the handshake there?
adds an extra Sec-WebSocket-Protocol
header to the above map passed to sendHandShake, and a bunch of extra headers
and .sendHandshake then sends those headers back to the client as part of the upgrade negotiation?
and of course there's an extra if
before calling the sendHandShake to check for the subprotocol in the request map
the request map should have a :server-exchange
in it. That is an HttpServerExchange object (http://undertow.io/javadoc/1.3.x/io/undertow/server/HttpServerExchange.html). From it, you can get the request headers (`.getRequestHeaders`). You can then mutate the headers, then call as-channel
and return. That exchange is then passed to the upgrade handler, with the headers set. If the upgrade succeeds, your :on-open
will get called
the relevant java is here: https://github.com/projectodd/wunderboss/blob/master/web-undertow/src/main/java/org/projectodd/wunderboss/web/undertow/async/websocket/UndertowWebsocket.java#L99
checker
is what calls your ring handler, and looks at the response to see if it has a channel body, and then calls the upgrade handler (`wsHandler` there) if it does
we build the checker here: https://github.com/immutant/immutant/blob/master/web/src/immutant/web/internal/undertow.clj#L221
ok..so I simply inspect the exchange (after pulling it out from the request map), look for the subprot header, add my custom headers, and then return as-channel
from the ring handler?
@moizsj: something like (untested):
(import 'io.undertow.util.HttpString)
(defn handler [req]
(let [exchange-headers (-> :server-exchange .getRequestHeaders)]
(when (check-subprotocol (:headers req))
(.put exchange-headers (HttpString. "header-name") "header-value"))
(as-channel req
:on-open (fn [ch])
;; etc
)))
and you can use immutant.web.internal.headers/set-header
instead of calling .put directly on exchange-headers to avoid that HttpString nonsense
got it. and you reckon this coupling to the exchange object is not risky? could it be removed/renamed since its part of the public contract?
it's part of the undertow public api, so would only break if immutant moved away from undertow, which won't happen
and if it doesn't work, I think I can make it work with minor changes to immutant itself