Thomas, Yes that does fix it under Socket.IO (tested in Chrome, but means it will work with all).
I started work on generalising your patch a bit, you can see the results in my ssl_client branch (https://github.com/alown/wave/tree/ssl_client). You will probably want to cherry-pick from that branch though, because I haven't kept it completely clean... Ali On 3 February 2012 09:50, Thomas Leonard <[email protected]> wrote: > Well, we only need client auth for the AuthenticationServlet, so it should > be easy to fix this by changing "Need" to "Want". Here's a patch to do that: > > https://github.com/tal-itinnov/wave/commit/07a604e6d5ab050f6991498afc0b267939e15d6d > > Does that fix it for you under Chrome? > > > > On 2012-02-02 19:38, Ali Lown wrote: >> >> Also, I gave your patch a shot here, and it mostly works: >> - In Chrome (17-Dev Build 0/Linux 64) websockets then fail to connect >> (despite the websocket URL being a wss://) -> perhaps Chrome doesn't >> support authenticating websockets? >> >> After hard-disabling websockets (or using Firefox etc.) it works properly. >> (Cherry-pick 67d73f61b77eb89315219f715d97f38f386fe09e and >> 8626aa5d0b10eb8627ae1a38ff3c944390c73b22 from my github repo) >> >> And you may want to add the removal of the "Sign out" button to your >> patch -> since it doesn't exactly server much purpose when using >> client auth. >> >> On 2 February 2012 15:18, Ali Lown<[email protected]> wrote: >>> >>> Looks interesting. >>> >>> It would be nice to generalise and get this patch submitted upstream >>> (certainly beats typing in a username + password each time). >>> >>> Since the AuthenticationServlet already has CoreSettings injected in >>> the constructor, it would be quite easy for you to move the hard-coded >>> OID and the addresses out into the config file which would be nice. >>> >>> You will probably also want to add a useClientAuth flag into the >>> settings, and update ServerRpcProvider to enable based on this. It >>> would then let you decide in the AuthenticationServlet whether to >>> serve the login page or not (rather than commenting it out). >>> >>> PS. Disabling tests in build.xml is all very well (as long as you >>> remember not to commit it to a review patch (I did this once)), but I >>> find it easier simply to map 'ant compile-gwt-dev&& ant dist-server' >>> >>> to an alias in my shell instead. >>> >>> On 2 February 2012 14:41, Thomas Leonard<[email protected]> >>> wrote: >>>> >>>> I've now got X.509 client authentication working working too. Now, when >>>> one >>>> of our users goes to our server it: >>>> >>>> - checks that their browser has a certificate issued by us (from our >>>> Microsoft Active Directory Certificate Services) >>>> >>>> - generates a wave ID for them automatically, based on the email address >>>> in >>>> their certificate >>>> >>>> - creates an account for them if they don't already have one >>>> >>>> - logs them in automatically >>>> >>>> The patch is quite hacky (just enough to get it working), but in case >>>> anyone >>>> wants to see how it works: >>>> >>>> >>>> https://github.com/tal-itinnov/wave/commit/ae8d59c5725a74bcf0fc2ae08ae5694abca02a7f >>>> >>>> This means that everyone gets access to their old imported waves (i.e. >>>> they >>>> can't register an account with the wrong ID, or with someone else's ID). >>>> >>>> >>>> On 2012-02-01 22:43, Ali Lown wrote: >>>>> >>>>> >>>>> Updated the patch for review to the one I am using. >>>>> >>>>> I haven't yet been able to solve the ICS/OpenSSL issue much to my >>>>> irritation. >>>>> Ideas on this are welcome since I am not a security expert (or have >>>>> ever used JSSE before...) >>>>> >>>>> On 31 January 2012 10:56, Thomas Leonard<[email protected]> >>>>> wrote: >>>>>> >>>>>> >>>>>> Would it be worth applying the patch anyway, with a note in the config >>>>>> that >>>>>> this doesn't work with all clients (and is disabled by default)? That >>>>>> would >>>>>> allow wider testing. >>>>>> >>>>>> >>>>>> >>>>>> On 2012-01-29 23:01, Ali Lown wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> OpenSSL's s_client is also unable to connect when asked to use the >>>>>>> TLS >>>>>>> cipher suites (but can do SSL3 ones fine). >>>>>>> This is despite the web browsers (Chrome, Firefox etc.) all >>>>>>> connecting >>>>>>> via TLS 1.0 >>>>>>> >>>>>>> It is looking like a bug/limitation in Jetty's SSL engine to me now, >>>>>>> rather than an issue with ICS's browser. >>>>>>> >>>>>>> Still looking into this issue before sending any further >>>>>>> patches/updates. >>>>>>> >>>>>>> On 29 January 2012 15:08, Ali Lown<[email protected]> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Found another issue with the implementation: >>>>>>>> For some reason Android ICS's Browser has a 'time out' when loading >>>>>>>> the page, yet Gingerbread, Froyo etc. are fine. >>>>>>>> >>>>>>>> They must have changed something to do with the SSL handshake the >>>>>>>> device performs when running ICS. >>>>>>>> >>>>>>>> Other devices, eg. iPhone have no issue with the handshake... >>>>>>>> >>>>>>>> Looking into this now. >>>>>>>> >>>>>>>> On 26 January 2012 20:33, Ali Lown<[email protected]> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Oops, just discovered that my patch broke the bots (due to them all >>>>>>>>> having hard-coded 'http' URLs in the code). The fact it took me a >>>>>>>>> week >>>>>>>>> despite running it on my server, suggests this code isn't ready >>>>>>>>> yet. >>>>>>>>> >>>>>>>>> I will submit a new patch to fix this in a few days time, once I >>>>>>>>> have >>>>>>>>> had a chance to check for any other bugs it may have introduced. >>>>>>>>> >>>>>>>>> On 22 January 2012 22:59, Ali Lown<[email protected]> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Sent a review request for most of the code. >>>>>>>>>> To get socket.io to work correctly though I had to edit >>>>>>>>>> socket.io.js >>>>>>>>>> in the third_party/runtime/socketio/socketio-core-0.1-SNAPSHOT.jar >>>>>>>>>> (attached here for your reference). >>>>>>>>>> >>>>>>>>>> As for the issue of privileged ports, I have chosen to run WIAB on >>>>>>>>>> a >>>>>>>>>> non-privileged, and with the help of an iptables REDIRECT, can >>>>>>>>>> make >>>>>>>>>> it >>>>>>>>>> appear to be running on 443. >>>>>>>>>> >>>>>>>>>> Works for me. :) >>>>>>>>>> >>>>>>>>>> On 18 January 2012 15:12, Vicente J. Ruiz >>>>>>>>>> Jurado<[email protected]> >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> El 18/01/12 00:20, Ali Lown escribió: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 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. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Just to say: Great job guys! >>>>>>>>>>> >>>>>> >>>>>> -- >>>>>> 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/
