Open Martii opened 8 years ago
connect-mongo has a MAJOR semver update... so holding off on this until later and after DB connection issues are resolved... which will take time since it happens every couple of days. UGGH!
Since OUJS predates even a stable version of connect-mongodb-session by over a year, it wasn't around when I was getting sessions to work with MongoDB. conect-mongo never worked very well so I'd be happy to have it replaced with something tailored to our choices of technology.
I did a quick test of trying to get it to work but it's above my capabilities at the moment... I tagged it as later since the sockets closed issue has been minimized by mongoose, our error traps, and MongoDB core along with whatever server changes MongoLab did.
conect-mongo never worked very well
Tried this in current dev:
diff --git a/app.js b/app.js
index 6bf89a3..859ab74 100755
--- a/app.js
+++ b/app.js
@@ -140,6 +140,27 @@ process.on('SIGINT', function () {
var sessionStore = new MongoStore({ mongooseConnection: db });
+sessionStore.on('create', function () {
+ console.log('created session');
+});
+
+sessionStore.on('touch', function () {
+ console.log('touched session');
+});
+
+sessionStore.on('update', function () {
+ console.log('updated session');
+});
+
+sessionStore.on('set', function () {
+ console.log('set session');
+});
+
+sessionStore.on('destroy', function () {
+ console.log('destroyed session');
+});
+
+
// See https://hacks.mozilla.org/2013/01/building-a-node-js-server-that-wont-melt-a-node-js-holiday-season-part-5/
var ensureIntegerOrNull = require('./libs/helpers').ensureIntegerOrNull;
@@ -318,7 +339,7 @@ app.use(session({
saveUninitialized: false,
unset: 'destroy',
cookie: {
- maxAge: 6 * 60 * 60 * 1000 // hours in ms
+ maxAge: 60 * 1000 // hours in ms
},
rolling: true,
secret: sessionSecret,
and the events fired before and after the 60 second period were:
$ node app.js
Starting application...
MongoDB connection is opened
Connected to MongoDB v3.4.7
GitHub client authenticated
GET /login 200 92.495 ms - -
HEAD /api/user/exist/M 404 64.302 ms - -
HEAD /api/user/exist/Ma 404 64.505 ms - -
HEAD /api/user/exist/Mar 404 63.245 ms - -
HEAD /api/user/exist/Mart 404 56.144 ms - -
HEAD /api/user/exist/Marti 200 59.647 ms - -
created session
set session
POST /auth/ 302 76.663 ms - 0
{}
Logged in
GET /auth/github/callback/?code=*snipped* 302 949.827 ms - 76
updated session
set session
updated session
set session
GET /group/Brainfuck 200 210.263 ms - -
touched session
GET /redist/npm/octicons/build/font/octicons.woff2?ef21c39f0ca9b1b5116e5eb7ac5eabe6 200 85.026 ms - 20248
GET / 200 471.934 ms - -
... seems to be missing the destroy
event.
Guess I'll try one tier up at mongoose to see what's happening... perhaps the event is exclusively swallowed there.
Ref:
destroy
event... manually triggered by express-session. e.g. /logout
route on our end.Specific to connect-mongodb-session I find zero events to trap like the ones found at /jdesboeufs/connect-mongo/blob/9684e5c
/README.md#events so my guess is that express-session events (which don't appear to exist reading the README.md) are the only ones unless they are hiding in mongoose (don't find any here readily) and/or mongodb itself (nothing found readily again).
Ref:
I'm reluctant to exchange this dep at this point since the alternative doesn't seem to be as fully developed for programmatic access.
While I've always considered connect-mongo
to be a unstable and inflexible piece 'o crap, there is so much code built around its limitations. If I was building an app from scratch, I'd probably use the mongoose associated middleware. But at this point we've worked around the limitations of the current middleware. Replacing it now just because it might be more compatible with mongoose is just asking for trouble.
Now if some future version of connect-mongo
gives us headaches, or requires us to make significant changes, then it might be worth trying to replace it with connect-mongodb-session
. And of course that module would need to support the operations performed in the modifySessions library.
It's nice to at least have a possible alternative now.
@sizzlemctwizzle Did you try this already?
I'll see if I can give it a shot in a little bit due to our trailing (resultant) error that comes from the mongoose err at Automattic/mongoose#3588
Refs: