0

I am trying to use session middleware to the socket io server, but cannot understand what the (socket.request) and (socket.request.res) are.

var sessionMiddleWare = session({
    secret: 'fastcampus',
    resave: false,
    saveUninitialized: true,
    cookie: {
      maxAge: 2000 * 60 * 60 
    },
    store: new SequelizeStore({
        db: db.sequelize
    }),
});
app.use(sessionMiddleWare);


...

var server = app.listen(port, function(){
    console.log('Express listening on port', port);
});

var listen = require('socket.io');
var io = listen(server);

io.use(function(socket, next){
  sessionMiddleWare(socket.request, socket.request.res, next);
});
require('./libs/socketConnection')(io);

I`m confusing with the 

io.use(function(socket, next){
  sessionMiddleWare(socket.request, socket.request.res, next);
});

because when I use the sessionMiddelWare in the local app,

just using

app.use(sessionMiddleWare)

Need some help.. thanks

jwkoo
  • 1,518
  • 2
  • 13
  • 24
  • Does the session middleware support socketio? That looks like express session which is for `app` only. What session information do you need for the socket clients? – Matt Nov 08 '17 at 05:43
  • yes, session middleware supports the socketio. that code operates normally – jwkoo Nov 08 '17 at 06:09

1 Answers1

1

Here's a breakdown of what's happening in the code that got you puzzled:

You have cookie session middleware running in your express app, just doing what it usually does (adding session data to each HTTP request which is received in your express app). BUT - you are also integrating socket.io into your express app. Websocket data transmission is initiated via the HTTP protocol (where your cookie session middleware is trustfully adding the session info each time), but it then switches to the websocket protocol - where you don't have your session info anymore. You want your session info to carry on from the HTTP request which initiated socket data transmission into the socket data transmission itself. And so you get:

io.use(function(socket, next){
  sessionMiddleWare(socket.request, socket.request.res, next);
});

The first line tells socket.io to use a middleware ("io.use"), a function which will be called each time you have data transmission via socket.io. You pass to this function two argument - socket and next. Next is simply a function which tells express.js to move on to the next piece of middleware once the present middleware has done it's thing. It's the "socket" argument which causes the confusion about this code, but here's what it does:

In the second line you are calling the function sessionMiddlWare (remember - it will be called each time an HTTP requests results in initiation of Websocket data transmission) and pass it three arguments: The third and last argument is "next", simply go to the next middleware once this middleware which initializes sessionMiddleWare has done its job.

The first argument (socket.request) is simply a reference to the HTTP request which initiated the socket data transmission (reference: https://socket.io/docs/server-api/#socket-request). This is where you accomplish what you set out to do, because this reference to the HTTP includes the session data - which is now included in your websocket transmission!

The second argument (socket.request.res) is the really puzzling one. It's task is to tell sessionMiddleWare if it should or should not save the session data for the transmission that just happened (reference). Notice that you don't necessarily want sessionMiddleWare to save the session data - you are most probably satisfied if the server and client have the right record of the data and so you can forget about the middle man (the sessionMiddleWare, that is). Furthermore - This doesn't seem to work! developers trying to save the session data within the sessionMiddleWare report that it doesn't happen anyway (see the reference to the github thread in this paragraph). So you can pretty much just use:

sessionMiddleware(socket.request, {}, next);

and get the same results without the mysterious socket.request.res argument ;) proof for this in the comment thread to the Answer in this stack overflow discussion.

Hope it's clearer now!

DevelopmenTom
  • 11
  • 2