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/
