Add session ID header in eventbusbridge messages about vertx-web HOT 23 CLOSED

👍 That would be very useful.

Two things to consider though:

1. Session ID should be optional/configurable
2. Session ID should be a requirement when securing the eventbusbridge with roles/permissions

from vertx-web.

A general mechanism to add headers to the message from the EventBusBridgeHook could also be useful then (you can already get the apexSession from handleSendOrPub(SockJSSocket sock, boolean send, JsonObject msg, String address) but no way to add headers to the message (you can modify the msg.body though, so it is possible to propagate the session information already somehow, but not in a nice way (using headers))

from vertx-web.

I am still wondering how the eventbusbridge can be secured at the moment. How can the eventbusbridge retrieve an apexSession from an incoming websocket frame when there is no session info within?

from vertx-web.

Ah ok, the session gets stored within the SockJSSocketBase after the upgrade:

router.get(wsRE).handler(rc -> {
      ServerWebSocket ws = rc.request().upgrade();
      SockJSSocket sock = new RawWSSockJSSocket(vertx, rc.session(), ws);
      sockHandler.handle(sock);
    });

and

ServerWebSocket ws = rc.request().upgrade();
        if (log.isTraceEnabled()) log.trace("WS, handler");
        SockJSSession session = new SockJSSession(vertx, sessions, rc, options.getHeartbeatPeriod(), sockHandler);

from vertx-web.

In order to prevent misunderstandings I would suggest to distinguish clearly between the client (vertxbus.js) and the server side (EventBusBridgeImpl) of the eventbusbridge.

In my understanding the client keeps the websocket connection open after the upgrade to the websocket protocol. Therefore I don't see any need to send a session ID within a websocket frame from a client to the server. Instead what we probably want is to access the already existing apex session (as mentioned by maschmid before) from within a usual vert.x handler on the server side. I assume that the session ID does also exist as a cookie on the client side which has been set by a SessionHandler before.

I think that apex sessions could be stored in three different places currently:

1. LocalSessionStoreImpl: vertx.sharedData().getLocalMap(sessionMapName);
2. ClusteredSessionStoreImpl: vertx.sharedData().<String, Session>getClusterWideMap(sessionMapName, res -> {...});
3. SockJSHandlerImpl: vertx.sharedData().getLocalMap("_vertx.sockjssessions");

This rises another question: Does the local map in place 3 store the same session as the internal session store in SessionHandlerImpl?

Maybe we need a way to lookup a session by session ID in a unified way? Even if the server side eventbusbridge would send a session ID to the server side message consumer (handler), the handler would still not be able to lookup the session by that ID without accessing one of the currently internal session stores directly.

from vertx-web.

Don't worry about how to get the session, it's already available easily in the bridge on the server, we just need to expose it on the SockJSSocket interface, then it's easy to just add the session id as a message header.

So, the question becomes "how does a user look up the session given the session id?".

from vertx-web.

We could augment the AuthService to allow the user to retrieve sessions (or create a new SessionService) over the event bus, but this means that the session would have to be a JsonObject or a DataObject and wouldn't allow arbitrary types in it as the current Apex session does.

from vertx-web.

Ok, I agree. It would be nice to indentify the steps that we actually have to go in order to be able to lookup a session by id. So let's try it:

1. Adding session id as a message header = "easy to add" :-)
2. Enhance the API of vertx to perform a lookup request. Maybe something like this: vertx.sessionHandler.looup(sessionId, sessionStoreType)
3. Implement the actual lookup (see steps below)
4. Derive the address of the session store from the lookup request. If no sessionStoreType has been given by the lookup request use LocalSessionStore as the default
5. When using a ClusteredSessionStore, remember that there is a TODO in SockJSHandlerImpl: use clustered map

What about this approach?

from vertx-web.

Can you elaborate on what you mean by "vertx.sessionHandler.looup(sessionId, sessionStoreType)" ?

from vertx-web.

I think that a vert.x application can have potentially more SessionHandlers registered on different routes and each SessionHandler could have its own session store. Then I would think that there is no chance from within a message consumer (handler) to derive the session store to be used for the lookup...

from vertx-web.

The following API proposal would be more close to what I was thinking:
vertx.lookupSession(sessionId, sessionStoreType)

from vertx-web.

Do you mean a change to the core API?

from vertx-web.

No. OK ^^

from vertx-web.

The Vert.x philosophy is not to push things into core so we can keep core simple. Any solution we come up should not require changes to the core API.

So.. I'm not really sure how you're intending to look up the session. remember: the consumers could be in completely different verticles to your apex code, or on completely different parts of the network. That's why I suggested a SessionService which could be used over the event bus from anywhere.

from vertx-web.

Sounds good. I will think about it.

from vertx-web.

A central SessionService could be accessed by a ProxyHandler for example. But in case of a LocalSessionStore the SessionService itself would have to query the whole cluster in order to find the correct node. This problem occured to me earlier this week which I was able to solve. But my solution is only useful in certain cases because the guarantee to get an answer from the cluster is not very high.

When using a ClusteredSessionStore the central SessionService solution could work.

from vertx-web.

A local SessionService would also be able to lookup the session from a clustered session store.
So the challenge I see is to lookup a session in a cluster where each node uses a local session store.

from vertx-web.

One could argue, that it must not make sense to use a local session store within a cluster. But that's not true. A local session store still makes sense when the clients are redirected by a load balancer to a certain node within the cluster, so the clients stay on the same node (sticky)

from vertx-web.

It doesn't matter if the session store is local or not, if it has an event bus proxy interface it can be accessed from anywhere.

from vertx-web.

I don't know how the proxy handler works internally. Would it be possible to have many nodes and many proxy handlers for the same service?

from vertx-web.

Sorry that I didn't get the idea of the event bus proxy yet. I don't understand how it solves the problem to find the correct node assuming that each node has its own session store.
Is the problem already solved conceptionally?

from vertx-web.

I'm going to close this as adding headers in bridge event hooks is now implemented

from vertx-web.

42d2a01
and the interface BridgeEvent

from vertx-web.