SockJs and session

[Mohammad Bhuyan]

One the browser has created a SockJs connection, in the server, during the message handling, can I access the "session variables" associated with the browser session?

What I am trying to achieve:

(1) User does a login in my web app. 

(2) On login success, server session is established. User is redirected to a portal.

(3) On load of the portal, a SockJs connection to server is created as a channel for server to push "notifications" relevant to the user.

This, on connection open, server needs to know "who" is connection, which is easy if I can get the session variables ( i save userid in session ). 

Thanks,

Mohammad   

[Ngoc Dao]

For security, you have to do it manually. See this:
https://github.com/sockjs/sockjs-node#authorisation

You can use this:
http://ngocdaothanh.github.com/xitrum/guide/howto.html#encrypt-data
to set the encrypted user info as a JS variable to the page that does
the SockJS connection.
Then you send the value of that variable through SockJS to the server.
The server decrypts the value to get back the user info.

You can also load a dynamic JS snippet that returns the encrypted user
info:
<script src="/path/to/dynamic.js"></script>

[Mohammad Bhuyan]

I don't want to use "user detail" ( encrypted or not) as my key to identify and serve the user. This scheme is open to:

(1) External connection posing in with a valid user detail gets qualified for service.
(2) User can get qualified for service without login.

Things get more complicated when you have "remember me" user login session, which I have.

I was thinking to send the Session Id that Xitrum has generated as a handover token to client so that when it presents the token back through SockJs, I can then interrogate xitrum for user (saved in session) against that session id. This way it is quite secured against (1) (2).

So, the question is is Xitrum API will support that - reading session id and recovering session variable for id? I think this API can give quite a bit of flexibility to developers.

Regards,

[Ngoc Dao]

> So, the question is is Xitrum API will support that - reading session id
> and recovering session variable for id?

About session, in Xitrum it does not have id. It is a mutable (so that
you can modify the session) Map[String, Any]. It only has data.

About SockJS handler, its interface:
def onOpen()
def onMessage(message: String)
def onClose()

Thus as mentioned in my last post, in a SockJS handler you don't have
session info. So currently you have to pass whatever info you want
from the browser to the handler through the "onMessage" method. You
can encrypt (sign) the info to prevent hacker to mess with it.

In the next version of Xitrum, I'm thinking of changing the SockJS
handler interface to:
def onOpen(session: immutable Map[String, Any])
def onMessage(message: String)
def onClose()

[Ngoc Dao]

>   def onOpen(session: immutable Map[String, Any])

To clarify:
You can think of SockJS handler vs normal controller as 2 different
worlds.
"onOpen" is the switching point from the normal controller world to
the SockJS handler world.
So I'm thinking of passing session to "onOpen" so that in the new
world you have info about the previous world.

[Mohammad Bhuyan]

So I'm thinking of passing session to "onOpen" so that in the new
world you have info about the previous world.

This is ideal solution. Can I have that NOW? :) And I mean right now. ;)

I have started implementing notification and having the session on open will be ideal, it will save me from implementing other means to relate my sockjs messages to a user session.

I will really appreciate if you could make this happen fast.

[Ngoc Dao]

> This is ideal solution. Can I have that NOW? :) And I mean right now. ;)

OK. I think I can release a new version this week.

[Charles Munat]

I like this idea. The fewer mutable items, the happier I am.

[Ngoc Dao]

> This is ideal solution. Can I have that NOW? :) And I mean right now. ;)

Please try Xitrum 1.15.

[Mohammad Bhuyan]

Thanks Ngoc,

I am a bit caught up at the moment - going through a "refactoring" phase. I will update to this soon.