I had a go at setting it up and yes this method of adjusting jetty seems to work fine.
Over the next couple of days I will have a go at writing a patch so that we can choose between ssl (and normal) listeners, keystore location and password all from the configuration file. On 17 January 2012 17:17, Ali Lown <[email protected]> wrote: > Ok I will try that later (I have been terminating externally up to now). > > The best 'patch' for socket.io is to force socket.io.js to have > 'this.base.options.secure = true' in the transport initialization code > (Line 185-ish). The actual socket.io code is setup to handle both > cases, but I can't find a way to pass the secure option from inside > the WIAB code, rather than editing this file inside the jar. > > On 17 January 2012 17:10, Thomas Leonard <[email protected]> > wrote: >> OK, so to summarise: >> >> On the server side, getting Jetty to serve SSL is simple enough. In >> ServerRpcProvider.java, use: >> >> SslContextFactory sslContextFactory = new SslContextFactory(); >> sslContextFactory.setKeyStore("/home/.../keystore.ks"); >> sslContextFactory.setKeyStorePassword("secret"); >> >> SelectChannelConnector connector = new >> SslSelectChannelConnector(sslContextFactory); >> >> The most difficult part is passing the configuration settings around >> (instead of hard-coding it like I did). I changed the syntax of >> http_frontend_public_address to include a scheme, e.g. >> >> http_frontend_public_address = https://localhost:9898 >> http_frontend_addresses = ${http_frontend_public_address} >> >> That required changing the type from InetSocketAddress to a pair of an >> InetSocketAddress and an SSL flag. >> >> >> On the client side, getting it to work with Chromium just means changing >> wss: to ws: in WebClient.java, but socket.io ignores the scheme and uses >> http in all cases. It sounds like you have a patch for this? >> >> >> >> On 2012-01-17 16:57, Ali Lown wrote: >>> >>> Yes. Because you have only changed it to support secure web sockets. >>> >>> In Firefox (even v9) it still reverts to XHR-Multipart (or simpler) >>> which if you check (use Firebug) will still be attempting to connect >>> to a http:// url. >>> To fix this you need to manually edit (inside the jar file >>> third_party/runtime/socketio/socketio-core-0.1-SNAPSHOT.jar) the >>> socketio.js file to use https URLs. >>> >>> Because this is a bit of a mess/hack, I am looking into editing the >>> code such that the jetty server serves SSL pages directly (should be >>> possible). >>> >>> On 17 January 2012 16:53, Thomas Leonard<[email protected]> >>> wrote: >>>> >>>> OK, so after editing WebClient.java to change "ws:" to "wss:", it works >>>> from >>>> Chromium but not from Firefox. So I guess it works for raw web-sockets >>>> but >>>> not for socket.io? >>>> >>>> Any chance of getting socket.io updated to fix this? >>>> >>>> >>>> >>>> On 2012-01-16 09:31, Ali Lown wrote: >>>>> >>>>> >>>>> I have also been playing around with this. >>>>> >>>>> I went for using stunnel to handle the actual termination, and then >>>>> editing the socket.io code to force the websockets to be initialised >>>>> using wss:// instead. >>>>> >>>>> On 16 January 2012 09:27, Thomas Leonard<[email protected]> >>>>> wrote: >>>>>> >>>>>> >>>>>> Are there any instructions on configuring WiaB to use SSL? >>>>>> >>>>>> I tried changing ServerRpcProvider to use SslSelectChannelConnector >>>>>> instead >>>>>> of SelectChannelConnector and that allowed me to view the login page >>>>>> using >>>>>> https://localhost:9898, but then it gives lots of errors like this: >>>>>> >>>>>> javax.net.ssl.SSLException: Unrecognized SSL message, plaintext >>>>>> connection? >>>>>> >>>>>> so I assume some change is needed at the client end too. >>>>>> >>>>>> The reasons I want to do this are: >>>>>> >>>>>> 1. The usual encryption/confidentiality reasons. >>>>>> >>>>>> 2. I can allow access only for our organisation by only trusting our >>>>>> CA, >>>>>> meaning I don't have to rely so much on the correctness of the WiaB >>>>>> auth >>>>>> code. >>>>>> >>>>>> 3. Hopefully I can use client authentication so that users don't need >>>>>> to >>>>>> log >>>>>> in or remember passwords, etc. This also means that everyone will get >>>>>> the >>>>>> correct user name (rather than letting them choose their own), which is >>>>>> important for the imported waves (otherwise, someone can register a new >>>>>> account with someone else's name and get access to that person's >>>>>> imported >>>>>> waves). >>>>>> >>>>>> Thanks, >>>>>> >>>>>> >>>>>> -- >>>>>> Dr Thomas Leonard >>>>>> IT Innovation Centre >>>>>> Gamma House, Enterprise Road, >>>>>> Southampton SO16 7NS, UK >>>>>> >>>>>> >>>>>> tel: +44 23 8059 8866 >>>>>> >>>>>> mailto:[email protected] >>>>>> http://www.it-innovation.soton.ac.uk/ >>>> >>>> >>>> >>>> -- >>>> Dr Thomas Leonard >>>> IT Innovation Centre >>>> Gamma House, Enterprise Road, >>>> Southampton SO16 7NS, UK >>>> >>>> >>>> tel: +44 23 8059 8866 >>>> >>>> mailto:[email protected] >>>> http://www.it-innovation.soton.ac.uk/ >> >> >> -- >> Dr Thomas Leonard >> IT Innovation Centre >> Gamma House, Enterprise Road, >> Southampton SO16 7NS, UK >> >> >> tel: +44 23 8059 8866 >> >> mailto:[email protected] >> http://www.it-innovation.soton.ac.uk/
