[Hawkular-dev] hawkular-accounts integration with websocket stuff in kettle

[Juraci Paixão Kröhling]

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-WebSocketsExample

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.