WAMP authentication implementation about jawampa

[Matthias247]

Hello Nabil,
I currently don't have plans to implement any of the advanced mode features.
If anyone else wants to do it I would of course accept pull requests.

If you don't need fine grained authentication you could probably set up SSL with client side authentification to restrict the allowed clients.

[Tetha]

Hey,

I'd plan to work on this over the next week, at the very least client-side.

I'm basically thinking of implementing something like this:

WampClientBuilder()
    .withUri('ws://acme.org:8080/ws')
    .withAuthentication(WampCra.fromUserAndSecret('fooUser', 'barSecret')
    .build();

The WampCra would be a ClientSideAuthentication, i.E. a class which can hold some authentication specific code (e.g. the user and the secret for the WampCra authentication, or the access token for the gitlab oauth authentication I have implemented at our GGS-fork for crossbar) with an abstract method "onChallenge". This should make it easy to implement all the authentications client-side.

I'll see how I add the router-side of the authentications. Probably similar, with a ServerSideAuthentication, so we can add some integration tests (i.E. if the FooAuthServerSide.onHello sends a certain challenge, FooAuthClientSide.onChallenge and FooAuchServerSide.onAuthenticate must work out well enough. It'll be somewhat tricky to get working, but it shouldn't be too hard).

Feel free to stop me, otherwise I'll throw pull requests around.

[Matthias247]

Hi @Tetha, thanks for offering your contribution. You are welcome to implement features of the advanced mode like authentication. However what I want to see is that all implemented features are correctly working and are implemented in a clean and understandable fashion. Otherwise I would rather have only basic features instead of half-broken advanced features. If you feel you are up to the task - please continue.

What you should look out for is that ordering and the new states are correct. E.g. that the connected event is only dispatched after authentication is finished (if authentication is required by the user), that afaik the GOODBYE/ABORT message have slightly different semantics for the authentication case and that all messages and state transitions are handled in the correct thread.

I would propose that we finish the client side first and then discuss about server side?
I'm also not really sure if and how authentication and other advanced mode features should be handled with regards to the feature announcement stuff in the WAMP specification. Currently feature announcement and negotiation are not really used by the library. But it might be necessary to support it (and also probably to make it configurable) if more advanced mode features get implemented.

Just took a really short look about what you(?) are doing in https://github.com/GoodgameStudios/jawampa/commits/master. The first commits seem to be only partly about the authentication feature but do also change a bigger part of the structure of the library. That might of course make sense (haven't looked at it in detail) - but I feel that this should have been seperatly.
As this has however now already happened I think it makes most sense that you just continue incorporating your changes and after you have finished you can send some more explanations and I can take a look.

[Tetha]

Just took a really short look about what you(?) are doing in https://github.com/GoodgameStudios/jawampa/commits/master.

More me and my team. We're mostly working on splitting up the WampClient and WampRouter classes, since they are huge and very hard to understand. You can see the final iteration of this on the MessageHandler-Branch, where I'm working on introducing individual message handlers for the various roles in the WAMP protocol. These should end up small and focussed and allows us to easily extend the library for further messages and roles in the wamp protocol.

[rashedir]

@Tetha, any update on the WampCRA implementation?

[Tetha]

@rashedir: Please take a look at the goodgame studios fork. We're running two applications on that code base and so far, it's looking stable.

As a whole, we got a bit carried away with the refactoring, since we need a number of the advanced features and will probably add a few router-specific features as well. I'm currently considering my options there - @Matthias247 if you want to chime in, let me now. I'm open for discussion or decision from your side here.

[rashedir]

@Tetha: Yes the GoodGameStudio fork works pretty well as I have been using it for the past couple of weeks or so. Today I hit a snag when wanting to use some features currently supported by Matthias247 Jawampa. Currently the GoodGameStudio fork is about 10 commits behind its parent. So just wondering if there is a plan merging the CRA feature in to the main branch.