Strange behavior with sessions and subscriptions

40 views
Skip to first unread message

Weber A.

unread,
Apr 15, 2015, 9:53:19 AM4/15/15
to socket...@googlegroups.com
Hello,

in our application we see a strange behavior with sessions and subscriptions. I'm not sure whether they are related or independent problems. I'll try to explain them.

Our application:
- two Node.js servers 0.12.x. One working as a data receiver, the other working as UI server
- socketStream 0.3.12 (but the problem was there with .11 too),
- redis Sessionstore

Channel subscription problems:
The data receiver gets data via a session less POST interface and forwards the data via ss.api.publish.channel(channel, message) interface. We use different channels for different data.
Now the UI in the browser registers via rpc calls on the UI server to this data using req.session.channel.subscribe(channel).
I can see the data arriving at the browser.

Now the user logs out or browses to another page which requires different data. In the first case I call req.session.channel.reset() in the second req.session.channel.unsubscribe(channel). I see debugging messages like this
unsubscribed sessionId s%3Avj6tqBY7Blk2Qir2NTxOcDp2lwlPYw6T.J88piwXne2sn8yQpzJmlAEQ3s70SuFjcD9cRpfc1O9k from channel 552cc90345adbaf82aba8a18:US,a\;a,b\:b,c\\c
for all subscribed channels.

However I still see the now unsubscribed channel arriving at the browser. If I reload the browser window, then a new web socket connection is opened and the arrival of data stops.

Why is SocketStream still sending the messages of an unsubscribed channel over the web socket connection?

Session problem:
Our application need the user to authenticate. We do a login via RPC and if it is successful we use req.session.setUserId to save the authenticated user in the session. From time to time we see our application to act weired, especially after a restart of the UI server. It looks like SocketStream is loosing the session id. I added a log statement at socketstream/lib/session/index.js line 52 (console.info('sessionStore.load', sessionId, err, session);) to see what happens with the session. I see many many calls to get a session but after some time or after a restart of the UI server I see the sessionId go to "undefined". Then I see a session called "undefined" appear in redis. The application works fine until I reload the page and it cannot find the session and therefore requires an relogin.
However I still see a valid connect.sid cookie in the browser with the previous sessionId and I still see this sessionId in Redis, but it looks like SocketStream is not able to find it anymore.

In redis I see all the sessions with their ID as part of the key. e.g.
sess:s%3ALRPSGog-wdfUQQ9U7NGkfxSYdohNUEQI.oeq%2BOB9HQVaezNHZZkF9grlroECIxExGVbx7Ga%2FHkXU

in addition I see for each session a second session with a subpart of this key. e.g.
sess:LRPSGog-wdfUQQ9U7NGkfxSYdohNUEQI

What is happening to my sessions, where do they go and how can I make SocketStream to correctly load the sessions again?

If you need more information in order to help me solve these problems, please don't hesitate to ask.

Thank you,
   Andreas

Henrik Vendelbo

unread,
Apr 18, 2015, 3:52:30 PM4/18/15
to socket...@googlegroups.com
I have yet to get into channels and users, but it sounds related to an existing issue. Do you think they are related ?

Weber A.

unread,
Apr 21, 2015, 1:53:36 AM4/21/15
to socket...@googlegroups.com
Hendrik,

do you think this is related? Is unsubscribing completely broken or should it work?

Paul Jensen

unread,
May 13, 2015, 7:04:43 PM5/13/15
to socket...@googlegroups.com
Hi,

I'd like to track all bugs in Github, would it be ok if I pull this into Github and we track it there?

Henrik Vendelbo

unread,
Jun 2, 2015, 8:01:56 PM6/2/15
to socket...@googlegroups.com
Thank you for the detailed information. As Paul said, we would want to track this in GitHub issues.

Could this have something to do with the default settings for connect session cookie? I recall it as being http-only by default, which means the client doesn't know the session ID. Perhaps we need a documentation improvement on this.
Reply all
Reply to author
Forward
0 new messages