incubator-wave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ali Lown <...@lown.me.uk>
Subject Re: Wave with HTTPS + client auth
Date Fri, 04 May 2012 09:10:18 GMT
The certificates I issued are valid for a year, it is not the case
that the certificate had expired. Rather it appears to be a set of
conditions leading to a session expiring.

On 4 May 2012 09:26, Thomas Leonard <tal@it-innovation.soton.ac.uk> wrote:
> Probably it would do that if the certificate had expired.
>
>
>
> On 2012-05-03 19:05, Ali Lown wrote:
>>
>> I can't get the problem to reproduce locally for debugging.
>>
>> I have now tidied and submitted for review.
>>
>> Ali
>>
>> On 2 May 2012 15:02, Ali Lown<a.lown0@gmail.com>  wrote:
>>>
>>> Thomas,
>>>
>>> No. I never finished tidying it up for submission.
>>> Also, I found a small issue where 'sometimes' the certificate isn't used,
>>> and the user gets dumped back to the login screen when both client-auth
>>> and
>>> password-based login is enabled.
>>>
>>> Thanks for the rebase, I might work on this this evening then.
>>>
>>> Ali
>>>
>>> On May 2, 2012 10:36 AM, "Thomas Leonard"<tal@it-innovation.soton.ac.uk>
>>> wrote:
>>>>
>>>>
>>>> Hi Ali,
>>>>
>>>> Did this get submitted? I merged the patches into one and rebased them
>>>> to
>>>> trunk if that helps:
>>>>
>>>>
>>>>
>>>> https://github.com/tal-itinnov/wave/commit/4e2c18ef95825b3fd92034d6544054f26c358b79
>>>>
>>>>
>>>> On 2012-02-13 10:26, Thomas Leonard wrote:
>>>>>
>>>>>
>>>>> It seems to work fine; please go ahead and submit...
>>>>>
>>>>>
>>>>> On 2012-02-11 22:07, Ali Lown wrote:
>>>>>>
>>>>>>
>>>>>> Thomas,
>>>>>>
>>>>>> I have tidied it a bit more, and added a new option
>>>>>> (disabled_loginpage).
>>>>>>
>>>>>> I thought you might want to take a look at it first, and depending
on
>>>>>> your thoughs would it be ok for me to submit my (heavily adjusted)
>>>>>> version for review here?
>>>>>>
>>>>>> Ali
>>>>>>
>>>>>> On 9 February 2012 17:01, Ali Lown<a.lown0@gmail.com>  wrote:
>>>>>>>
>>>>>>>
>>>>>>> The IsRegistrationDisabled patch was implemented to disable the
>>>>>>> registration
>>>>>>> page for private internet-facing servers.
>>>>>>>
>>>>>>> As such, to extend the same function to the client certificate,
would
>>>>>>> be to
>>>>>>> disable the automatic registration of users who authenticate
with a
>>>>>>> certificate for a user not already on the system.
>>>>>>>
>>>>>>> For your idea, I feel it would be better to do that sort of check
>>>>>>> during the
>>>>>>> actual registration step, and use a new setting:
>>>>>>> mustRegistrationUsernameMatchCert?
>>>>>>>
>>>>>>> On Feb 9, 2012 10:16 AM, "Thomas
>>>>>>> Leonard"<tal@it-innovation.soton.ac.uk>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks. BTW, I was hoping to use isRegistrationDisabled the
other
>>>>>>>> way:
>>>>>>>> to
>>>>>>>> prevent people from registering any account *except* the
one in
>>>>>>>> their
>>>>>>>> certificate.
>>>>>>>>
>>>>>>>>
>>>>>>>> On 2012-02-08 20:43, Ali Lown wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 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<tal@it-innovation.soton.ac.uk>
>>>>>>>>> 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<ali@lown.me.uk>
 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<tal@it-innovation.soton.ac.uk>
>>>>>>>>>>>> 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<tal@it-innovation.soton.ac.uk>
>>>>>>>>>>>>>> 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<ali@lown.me.uk>  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<ali@lown.me.uk>  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<ali@lown.me.uk>  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<vjrj@ourproject.org>
>>>>>>>>>>>>>>>>>>> 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:tal@it-innovation.soton.ac.uk
>>>>>>>>>>>>>>> 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:tal@it-innovation.soton.ac.uk
>>>>>>>>>>>>> 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:tal@it-innovation.soton.ac.uk
>>>>>>>>>> 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:tal@it-innovation.soton.ac.uk
>>>>>>>> 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:tal@it-innovation.soton.ac.uk
>>>> 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:tal@it-innovation.soton.ac.uk
> http://www.it-innovation.soton.ac.uk/

Mime
View raw message