2:32 p.m.
Juca,
I think I have the hawkular websocket code ready to start calling the accounts API.
Looking at:
https://github.com/jpkrohling/hawkular-accounts/blob/HAWKULAR-505-WebSock...
I would need "authenticateWithUsernamePassword" to be implemented (right now it
is private and throws UnsupportedOperationException) as well as
"authenticateWithToken" be exposed (right now this is private). I don't care
about the return values - so if you want to provide versions of these methods that return
void rather than return your cached session, that's fine. I am assuming if
authentication fails, a WebsocketAuthenticationException will be thrown; if authentication
succeeds, the methods just return normally.
I plan on being able to pass you an optional "persona" (I saw in your PoC that
your methods accepts a persona in addition to credentials or tokens). If that is not your
plan in the future, let me know and I will remove the code I have for passing around
persona.
I think I have the server-side stuff coded up (with a couple of TODOs where calls to your
new authenticate methods will go) in a branch in hawkular-bus. Here's a place where I
will be calling the accounts API, as an example:
https://github.com/hawkular/hawkular-bus/blob/mazz/hawkular-581-websocket...
--John Mazz
----- Original Message -----
Mazz,
I just finished a draft that is close to become the final code for this.
It has no documentation apart from a sample application that I'm using
to test it.
I'd appreciate if you could give some feedback and check whether it
provides what's needed for your component.
I'll be working on writing some documentation tomorrow, but feel free to
ping me on IRC should you have any questions.
The working branch is here:
https://github.com/jpkrohling/hawkular-accounts/tree/HAWKULAR-505-WebSock...
Basically, the approach is:
- Websocket client sends JSON messages to server, with an
"authentication" node on the message (at least on the first message)
- Server uses CDI to inject the Accounts WebSocket API's
- Server calls "authenticate()" method, passing the message and the Session
- Authenticate will automatically close the Session if the auth data is
missing, invalid or expired
What could be implemented, in case you need:
- support for binary messages (you'd have to tell the API what's the
token, though)
- support for username/password instead of token
- Juca.
On 08/06/2015 03:21 PM, Juraci Paixão Kröhling wrote:
> On 08/06/2015 03:05 PM, John Mazzitelli wrote:
>>> Is there something you'd require that I might be missing?
>>
>> If we have something like this:
>>
>>> So, we are likely going to follow the route of implementing a
"check"
>>> on each
>>> onMessage. Not clean, certainly invasive, but works. I'll try to
>>> alleviate the pain as much as I can by providing simple APIs.
>>
>> then that would be very helpful and possibly most of what we need (I
>> say "most" because this wouldn't cover the use-case Heiko just
>> mentioned - what if a user has been removed from the system - we would
>> need to know that and forcibly disconnect the WebSocket connection -
>> but that's an edge case. For now, just care about the general use-case
>> of a user making a connection - how do we authenticate that user?)
>
> I'd say that it even fulfills this case, as the check would be done on
> Accounts, having access to the session. Accounts would then close the
> session if needed.
>
> - Juca.