added ticket to eventbus bridge messages

[sibay]

For identifying or authorization of clients using the javascript eventbus bridge i added a ticket to the json message. The ticket is set via the options map in the eventbus constructor and send to the server with every send/publish/register or unregister message. The ticket can used as session id, auth token, ....
To see it in action i setup a small project: https://github.com/sibay/ebb-ticket-showcase

Are there any tests for vertxbus.js?

[pmlopes]

Hi @sibay, I think you should use the message headers and not just a top level property. Another question is why did you decide to do this instead of the Auth API?

[sibay]

Hi pmlopes,

i didn’t use the headers because i want the sessionId/token/ticket in every BridgeEvent i receive in my handler. The headers are only sent when you use eventbus.send() or publish().

I feel unsafe using the Auth API in this case. I want to authorize in a standard HTTP way and then open the event bus bridge. Do i always have the correct web session in my BridgeEvent handler? Regardless of the transport SockJS uses for the socket( XHR,EventSource, jsonp, html_file, web socket)? How is the session information transmitted in the transports and is this implemented by all browsers?
Furthermore there is a section on Authorization with Cookies and SockJS (https://github.com/sockjs/sockjs-node) and they say it is not secure. This section is mentioned in the method BaseTransport.removeCookieHeaders(), too.

And i asked in the vert-x google forum about session handling in the bridge, Tims proposal was to send a token over the socket (https://groups.google.com/d/msg/vertx/Kj-ORdWDzWA/X4wNr-k7FgAJ)

So, in case i understood everything aright, the most reliable and secure method seems to be the ticket token over the socket.

When you look at the code in the example project you can see how i want to use it (https://github.com/sibay/ebb-ticket-showcase).

[pmlopes]

My only concern with this PR is that you just add a extra field to the envelope on the js client but nothing is added to use that field on the server side, in a way it does not feel correct since there is no use for the extra field on the server code, if you understand what i mean...

I think some pieces of code from your demo should also be part of the PR to make it complete. In your examples the TicketEventbusBridge should be part of the PR as a TicketBridgeEventHandler or something similar since that is the backend side or this PR.

In the same code you do:

event.rawMessage().getString("ticket")

If you would do:

event.rawMessage().getJsonObject("headers").getString("authorization")

Then you could be using the headers instead of having the need to modify the client js code. WDYT?

[sibay]

My only concern with this PR is that you just add a extra field to the envelope on the js client but nothing is added to use that field on the server side, in a way it does not feel correct since there is no use for the extra field on the server code, if you understand what i mean…

Yes, understand. Adding a new feature without announcing it, makes no sense.

I think some pieces of code from your demo should also be part of the PR to make it complete. In your examples the TicketEventbusBridge should be part of the PR as aTicketBridgeEventHandler or something similar since that is the backend side or this PR.

I added some code to the showcase (TokenizedBridgeEventHandler/Impl), this could be used as example code. But perhaps this is a little bit oversized, as one class and one interface encapsulate only one line of code (event...getString("authorization“)) and not good enough for the vertx-web code. As alternative the BridgeEvent could be extended with an extra field authToken.

In the same code you do:

event.rawMessage().getString("ticket")

If you would do:

event.rawMessage().getJsonObject("headers").getString("authorization“)

Then you could be using the headers instead of having the need to modify the client js code. WDYT?

Using the headers would be ok, but i want to avoid to set always the authorization token explicit in a send() or publish(), register() call. Setting it once in the constructor should be enough. And register() and unregister() doesn’t offer to set the headers at all. Thats why i chose the above way to implement it. To set the token in the options map has the advantage that the API is not changed at all.

When i add some documentation (where?) with example server side and client code to show the usage to the pull request, would this be ok?

Or we can restart the discussion:-)

What i need is the possibility to identify the client (respectively the socket) for send/publish and register event bus messages. I have no problems with send and publish, because i have full control over the message. The only problem is with register, there i can’t add an extra portion of information. Do you see any possibility? E.g. exposing the socketId?

Or does the SockJSSocket.webSession() always and reliable return the same webSession? Then i can use a send() method with authorize token after socket creation, store the token in the webSession and use this in subsequent events. For this i wouldn’t need a PR.

[pmlopes]

just a few pointers:

Documentation should be added here:
https://github.com/vert-x3/vertx-web/blob/master/src/main/java/io/vertx/ext/web/package-info.java

And examples here:
https://github.com/vert-x3/vertx-web/blob/master/src/main/java/examples/Examples.java

They can then be referred from the documentation so you do not need to format the code on the docs.

[purplefox]

I don't really understand why this is necessary.

1. it should be possible to just use the auth capabilities of vertx-auth as I suggested in the forum thread
2. if that is really not wanted (and I don't realy understand why not) then doing your own auth by sending messages and implementing bridge event handlers should work. But that doesn't require changing vertxbus.,js

[sibay]

I want to control the registering of consumers on eventbus addresses on a per user basis. So i need to identify the user in the BridgeEvent handler.

When sending message (eventbus.send()) from the user i can add a token to the message(e.g. the session token obtained from a previous authorization request), thats not a problem. But i cannot add this token to the register „message“.
To solve this i add a SessionHandler to the eventbus route and store the token from a first BridgeEvent of type SEND or PUBLISH in the SessionHandler and use this in subsequent messages/registrations. That would be ok, no changes are necessary.

But can i rely on the session i have in the BridgeEvent handler?

(BridgeEvent event,String authToken) -> {
   SockJSSocket socket = event.socket();
   Session session = socket.webSession();
   ….
}

The SessionHandler in vertx-web uses cookies. And when the SockJS server is not the web server i need cross domain cookies. Can i rely on cross domain cookies for all transports used in SOCKJS? I am not sure.
Furthermore SockJS doesn’t support cookies in their node server because of security concerns, so perhaps it is a bad idea to use cookies.

That’s why i wanted to add the ticket to every packet which is send from the eventbus javascript client to the server. Which has some advantages:

• it does not rely on cross domain cookie handling of the different transports
• it does not rely on cross domain cookie handling in different browsers
• it is secure regarding to https://github.com/sockjs/sockjs-node#authorisation

When i could identify the socket, that would be fine too, but the socket id is not exposed and sometimes not set.

Or when you see another possibility to solve my problem with less coding i would appreciate it.

[sibay]

I solved it with another approach. I will add the session id to the register address and remove the session id from the address in the BridgeEvent handler. This way i can identify the user when he sends a register message.