Auto Reconnect about wamp-proto HOT 6 CLOSED

Slight adjustment: sessionId may not be isolated to the connection it belongs to. Perhaps the Welcome message could deliver another ID token that the client should keep private. That token could be used to identify a reconnect.

Thoughts?

from wamp-proto.

Not sure: what does a server do with the info that a session is reconnecting? What would be a user case?

The technical problem is: currently the server decides about the session ID, and thus can make sure that every connected client has a different one. This is important i.e. for exclude/eligible lists when client publishes events. When the client can decide it's session ID, the client can fake up the session ID to anything. The server could still check for session ID clashes, but it cannot determine if the session ID given by the client was really the one from the last connect.

Are you thinking of having an ID that persistently identifies a specific client (or even user) instead of just the session/connection?

from wamp-proto.

I was thinking along the lines of keeping server side state on the connection. For example, in the context of presence in WAMPv2, if a connection did not cleanly end the "unknown" presence of that connection could be broadcast to other clients. If the user re-connects within a given time frame, using the secret session id, the state would resume and presence updated. From the server, if there is no reconnect in x# of seconds it would fully remove the session.

As for session hijacking, it would be up to the server to create the original ID with enough entropy that guessing a sessionID in the 10 second resume window would be near impossible.

from wamp-proto.

I also agree here. My particular use case is for authentication:

• Client connects
• Client provides auth
• Client subscribes to a bunch of events
• Network glitch, client booted temporarily (order of seconds)
• Client reconnects, hopefully to the same session

Providing reconnection at the protocol layer would allow apps to transparently reconnect without re-requesting authentication details. This is more secure than the naive approach, which requires caching the password locally (even if hashed, this is still vulnerable to replay attacks).

This could be implemented by connecting the session id provided by the welcome message with the previous, hopefully still-valid, session. This would eliminate the need for a messy RPC layer on top, but could potentially require new message types to be defined.

Putting authentication in the protocol is another potential solution, but this seems like it could overcomplicate the protocol. Attaching to an existing session, however, solves the same problem without requiring a plugin for how to authenticate a client.

from wamp-proto.

Putting authentication mechanisms into the wire level protocol instead of reusing the RPC features and standardizing authentication on top of that: I don't see any advantage. violates DRY. It isn't "messy" - to the contrary, imlementing auth at protocol level would be.

The password does not need to be stored plain text, since WAMP-CRA provides ability to use password hashes based on salts.

Regarding replay attacks: WAMP-CRA isnt vulnarable to that, since the challenge sent by the peer (and needs to get signed by the authenticating peer) contains a random nonce.

Extending the lifetime of session IDs across the lifetime of the underlying transport: in the light of above, what would be the advantage?

from wamp-proto.

Authentication is a complex area: some apps might want to leverage authentication information coming from the transport underlying WAMP (e.g. cookies or TLS client cert auth), other apps might want to do their own authentication on top of WAMP. So I still don't think it's a good idea to put that into WAMP wire level protocol.

from wamp-proto.