GithubHelp home page GithubHelp logo

connect-mongostore's Introduction

connect-mongostore

MongoDB session store for Connect/Express

Build Status Coverage Status Dependency Status NPM version Stories in Ready

Why?

Existing stores work fine but we needed a store that supports replica sets configuration passed to it.

Installation

connect-mongostore supports connect >= 1.0.3, express 3.x and express 4.x with express-session.

via npm:

$ npm install connect-mongostore

Options

Pass a fully-qualified URI as the only option (e.g., mongodb://127.0.0.1:27017/myDatabase), or an object (also see examples folder for configuration examples):

  • db Can be three different things:
    • database name (string)

    • mongo-native database instance

    • object with replica set options. These options requires:

      • name Database name

      • servers Array of replica set server configurations similar to:

          {
            "host" : "127.0.0.1", // required
            "port" : 27017, // required
            "options" : { // all optional
              "autoReconnect" : false,
              "poolSize" : 200,
              "socketOptions" : {
                "timeout" : 0,
                "noDelay" : true,
                "keepAlive" : 1,
                "encoding" : "utf8"
              }
            }
          }

        Configuration options explained here

      • replicaSetOptions An object with a single rs_name property specifying your replica set name

  • collection Collection (optional, default: sessions)
  • host MongoDB server hostname (optional, default: 127.0.0.1). Not needed for Replica Sets.
  • port MongoDB server port (optional, default: 27017) Not needed for Replica Sets.
  • username Username (optional)
  • password Password (optional)
  • authSource Options for Db#authenticate method (optional)
  • expireAfter Duration of session cookies in milliseconds (e.g., ones with maxAge not defined). Defaults to 2 weeks. May be useful if you see a lot of orphaned sessions in the database and want them removed sooner than 2 weeks.
  • autoReconnect This is passed directly to the MongoDB Server constructor as the auto_reconnect option (optional, default: false).
  • ssl Use SSL to connect to MongoDB (optional, default: false).
  • mongooseConnection in the form: mongooseDatabase.connections[0] to use an existing mongoose connection. (optional)
  • stringify If false, connect-mongostore will serialize sessions using JSON.stringify before setting them, and deserialize them with JSON.parse when getting them. (optional, default: false). Note that deserialization will not revive Dates, Object IDs and other non-plain objects.

Example

With express 3.x:

var express = require('express');
var MongoStore = require('connect-mongostore')(express);
var app = express();

app.use(express.session({
    secret: 'my secret',
    store: new MongoStore({'db': 'sessions'})
  }));

With express 4.x:

var express = require('express');
var session = require('express-session');
var MongoStore = require('connect-mongostore')(session);
var app = express();

app.use(session({
    secret: 'my secret',
    store: new MongoStore({'db': 'sessions'})
  }));

With connect:

var connect = require('connect');
var MongoStore = require('connect-mongostore')(connect);

Removing expired sessions

connect-mongostore uses MongoDB's TTL collection feature (2.2+) to have mongod automatically remove expired sessions. (mongod runs this check every minute.)

Note: By connect/express's default, session cookies are set to expire when the user closes their browser (maxAge: null). In accordance with standard industry practices, connect-mongostore will set these sessions to expire two weeks from their last 'set'. You can override this behavior by manually setting the maxAge for your cookies - just keep in mind that any value less than 60 seconds is pointless, as mongod will only delete expired documents in a TTL collection every minute.

For more information, consult connect's session documentation.

Tests

You need mocha.

make test

The tests use a database called connect-mongostore-test. make test does not run replica set tests.

To run all tests including replica set tests:

make test-rs

Note that replica set tests will fail unless you 1) have a replica set, and 2) set the address of that replica set either in CM_REPL_SET_HOST environment variable or directly in connect-mongostore.test.js file.

You can check code coverage report by running

make coverage

or

make coverage-rs

for coverage with replica set tests.

Coverage report will be in reports/lcov-report/index.html file.

Stuff

Big thanks to @kcbanner and his connect-mongo, which was a starting point for connect-mongostore.

License

(The MIT License)

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the 'Software'), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED 'AS IS', WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

connect-mongostore's People

Contributors

diversario avatar kyleross avatar surr-name avatar waffle-iron avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar

connect-mongostore's Issues

There is a small chance for a concurrency dirty read problem

While working on a local machine (very low latency) between frontend and backend, I had the following rare case:

When the ".set" gets called, there is some time between submitting the save (upsert) request to the database and between getting the callback that the data is actually updated. Between this short period of time, there is a chance to get a dirty read from a new concurrent request.

I think this should solve it: When .set is called, the session object for the specific sid should be left in memory temporarily, if a get request is triggered then, that get request should return this temporary session in memory and not read from db. When the callback of the .set is called and the actual data is updated to the database at that point you can get rid of the temporary session object that you left in memory, so subsequent .get calls will fetch again from database now...

Of course there are cases where you get subsequent saves (.set) some sort of reference counting on the temp session object in memory should resolve this. The problem doesn't stop here but this solves part of it. Two concurrent calls will start with two .get, each receiving a different copy in memory, at this point one of the two will finish first and will save the new updated session object, when the next calls is also done and wants to save it's copy, the first ones save is lost...

Furthermore you should add some defense mechanism to the .save. The session object read should have the last timestamp when the data in Mongo was updated. Upon saving, that timestamp to be saved should be the same with the timestamp that is already there, (add to filter, if they don't match, update count = 0) otherwise, in between a newer session state was saved from a different source. Not sure how to react in this situation, but at least we shouldn't overwrite the session data in this case as a probably newer version already is there in the database. In RDB environments, ideally, the database takes care of this concurrency problem.

Thank you.

Question on expiring sessions from a particular API call

We are running on Amazon. The load balancer sends a test to the servers every 15 seconds to make sure the app is alive. We have coded an API call for it to check, which tests if both node and mongo are working. However, this creates a session, with each call, as it's not a web browser, so a new session gets built. We have 80,000 records in our session database, that expire every four weeks. Wondering if there is any way to prevent this happening.

Mongostore .set update fails with RangeError: Maximum call stack size exceeded for replica set

I have configured MongoStore to connect to a replica set, the connection is successful and I can see session being added in the sessions collection. But when I try to modify the session object, the update fails and the session does not modify. The collection.update in the set gives RangeError: Maximum call stack size exceeded error.

Am I configuring it wrong?

PS: It is express 3.x and mongoose environment.

URL parser doesn't work with replica sets

Right it's using the node.js url module to parse it, with works for single hosts but doesn't work with replica sets.

Some Examples:

I'd suggest either using mongodb's url_parser or muri

What do you think?

Existing mongoose replica set connection

I'm using a MongoHQ(Compose) replica set and am having issues using that existing mongoose connection with the mongostore, is there additional configuration I'm missing?

Fix for Express 4.0

When upgrading to Express 4.0, connect-mongostore experiences the issue identical issue as connect-mongo detailed here and here.

However, I notice this issue has been fixed on Github, in version 0.1. However the most recent version published to NPM is 0.0.13. What's the status?

How to configure db connection with autoReconnect option ?

new MongoStore(
{db:'dev', host:'127.0.0.1'},
function(err){
console.log(err || 'connect-mongodb setup ok');
})
I'm not using replica server. Just plain mongo on a single server.
How do I give the auto reconnect option here ?
new MongoStore(
{
db:'dev',
host:'127.0.0.1',
options:{
autoReconnect: true
}},
function(err){
console.log(err || 'connect-mongodb setup ok');
})

Should suffice ??

Server Timeouts when connecting to replica set

I have configured MongoStore to connect to a replica set. It seems to connect just fine, but whenever I try to access my site, the requests simply time out. There must be an issue with replica set configuration or handling, because simply connecting to a single localhost DB works fine.

I am trying to connect to a MongoHQ replica set. I have provided the username, password, db.name, db.servers, db.replicaSetOptions (with rs_name and w:1).

Am I missing something, perhaps?

SSL doesn't seem to work with replica sets

The ssl:true option does not appear to work with replica sets. Is this a bug or is there a special/different configuration option that should be used when a replica set configuration is required?

Error setting TTL index on collection / Cannot determine state of server

I came here from this thread

I do have a replica set in production, so I decided it would be better to use this module, and I thought maybe this issue would disappear if I pass it the mongoose connection, instead of trying to spawn a new connection to the database, but alas, I am still seeing this get thrown on livereload trigger of app restart:

Error: Error getting collection: sessions <Error: Error setting TTL index on collection : sessions <Error: Error setting TTL index on collection : sessions <Error: Cannot determine state of server>>>
   at /Users/davis/git/warehouse-web/node_modules/connect-mongostore/lib/connect-mongostore.js:110:22
   at Db.collection (/Users/davis/git/warehouse-web/node_modules/connect-mongostore/node_modules/mongodb/lib/mongodb/db.js:534:27)
   at MongoStore.getCollection (/Users/davis/git/warehouse-web/node_modules/connect-mongostore/lib/connect-mongostore.js:109:13)
   at MongoStore.get (/Users/davis/git/warehouse-web/node_modules/connect-mongostore/lib/connect-mongostore.js:133:10)
   at session (/Users/davis/git/warehouse-web/node_modules/express-session/index.js:355:11)
   at Layer.handle [as handle_request] (/Users/davis/git/warehouse-web/node_modules/express/lib/router/layer.js:82:5)
   at trim_prefix (/Users/davis/git/warehouse-web/node_modules/express/lib/router/index.js:270:13)
   at /Users/davis/git/warehouse-web/node_modules/express/lib/router/index.js:237:9
   at Function.proto.process_params (/Users/davis/git/warehouse-web/node_modules/express/lib/router/index.js:312:12)
   at /Users/davis/git/warehouse-web/node_modules/express/lib/router/index.js:228:12

Here's what I'm doing -- please tell me if there is a recommended way to resolve this:

in app.js

mongoose.connect(config.mongo.uri, config.mongo.options);

var app = express();

mongoos.connection.on('connected', function () {
  debug('mongoose connected to %s, mongoose.connection.readyState %d', config.mongo.uri, mongoose.connection.readyState);

  // other modules are required here like mongoose models 

  // this require is now delayed until supposedly mongoose is in ready state
  require('./routes/express')(app);
});

mongoose.connection.on('error', function (err) { console.error('mongoose connection error ', err); });

in ./routes/express.js (required from above)

var session = require('express-session'),
  MongoStore = require('connect-mongostore')(session)

module.exports = function (app) {

   // other code setup up cookie parser, body parser, etc.
  app.use(session({
    secret: secret,
    saveUninitialized: true,
    resave: true,
    store: new MongoStore({
      mongooseConnection: mongoose.connections[0],
      collection: 'session',
      auto_reconnect: true
  }, function () {
      debug('express connect-mongostore session store connected.');
  }));

My localhost dev machine does not have a replica set -- not that it matters much for this issue. The problem happens when livereload triggers a server reload. I'm using gulp-livereload, and when it detects a file has been saved in the server source, it will respawn the app.

// have nodemon start the express server; nodemon only restarts on change in src/server
gulp.task('nodemon', function () {
  plugins.nodemon({
    script: './src/server/bin/www',
    verbose: true,
    env: {
      'NODE_ENV': 'development',
      'DEBUG': '* -express:* -send -session -mquery -express-session'
    },
    watch: './src/server',
    ext: 'js jade html css styl json',
    nodeArgs: ['--debug']
  }).on('restart', function () {
    // initiate livereload -- sometimes happens too fast; 500 ms was too short for me
    setTimeout(function () {
      log('Trying to refresh livereload after server has restarted...');
      reload.changed('/');
    }, 1000);
  });
});

not useful in connect 3.0+

hi,this is my error and will console the error 'can't set the headers after the res has sent',

image

i guess it maybe that the req.session.user set sync call the res.send

and i decide use the connect-mongo,and it works well.

Issue with multiple concurrent reads

When an express instance using connect-mongostore is accessed for the first time, and there are multiple concurrent requests to that server, connect-mongostore will fail with an error. If I wait a while after the initial error, the server seems to run fine. Also, no problems will occur if the first request is allowed to be processed fully before new requests come in.

I suspect that while connect-mongostore is creating the MongoDB connection, the state of the mongostore code is such that requests coming in while the connection is being made will fail.

The error is:
Error: Error setting TTL index on collection : sessions2 <Error: Error setting TTL index on collection : sessions2 <Error: No replica set primary available for query with ReadPreference PRIMARY>>
at /home/v2/git/spatineo-monitor/node_modules/connect-mongostore/lib/connect-mongostore.js:115:24
at /home/v2/git/spatineo-monitor/node_modules/connect-mongostore/node_modules/mongodb/lib/mongodb/db.js:1436:28
at /home/v2/git/spatineo-monitor/node_modules/connect-mongostore/node_modules/mongodb/lib/mongodb/db.js:1558:28
at /home/v2/git/spatineo-monitor/node_modules/connect-mongostore/node_modules/mongodb/lib/mongodb/cursor.js:160:22
at Cursor.nextObject (/home/v2/git/spatineo-monitor/node_modules/connect-mongostore/node_modules/mongodb/lib/mongodb/cursor.js:733:16)
at Cursor.toArray (/home/v2/git/spatineo-monitor/node_modules/connect-mongostore/node_modules/mongodb/lib/mongodb/cursor.js:159:10)
at Cursor.toArray (/home/v2/git/spatineo-monitor/node_modules/connect-mongostore/node_modules/mongodb/lib/mongodb/scope.js:10:20)
at Db.indexInformation (/home/v2/git/spatineo-monitor/node_modules/connect-mongostore/node_modules/mongodb/lib/mongodb/db.js:1557:63)
at Db.ensureIndex (/home/v2/git/spatineo-monitor/node_modules/connect-mongostore/node_modules/mongodb/lib/mongodb/db.js:1435:8)
at Collection.ensureIndex (/home/v2/git/spatineo-monitor/node_modules/connect-mongostore/node_modules/mongodb/lib/mongodb/collection/index.js:65:11)
at /home/v2/git/spatineo-monitor/node_modules/connect-mongostore/lib/connect-mongostore.js:114:23
at Db.collection (/home/v2/git/spatineo-monitor/node_modules/connect-mongostore/node_modules/mongodb/lib/mongodb/db.js:502:44)
at MongoStore.getCollection (/home/v2/git/spatineo-monitor/node_modules/connect-mongostore/lib/connect-mongostore.js:109:13)
at MongoStore.get (/home/v2/git/spatineo-monitor/node_modules/connect-mongostore/lib/connect-mongostore.js:133:10)
at Object.session as handle
...

I'm using a three member replica set and express (3.x).

request hangs somehow

Starting this trivial static file sever:

var express = require('express'),
    app = express(),
    http = require('http'),
    server = http.createServer(app)
    ;
var morgan = require('morgan');
app.use(morgan('dev')); //this is the express logger...
app.use(require('errorhandler')({dumpExceptions: true, showStack: true}));
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
// HERE comes the problem:
var session = require('express-session');
var MongoHttpSessionStore = require('connect-mongostore')(session);

var cookieParser = require('cookie-parser');
app.use(cookieParser());

app.use(session({
        secret: "x",
        store: new MongoHttpSessionStore(
            {
                collection: "_sTEST_delete",
                db: "test"
            }
        ),
        cookie: {
            maxAge: 60000 * 30
        }, // in minute(s) from milliseconds-> *60000
        // the following are both default true
        resave: true,
        saveUninitialized: true
    }
));
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
app.use('/', express.static(__dirname + '/public')); //at last try to find if this is a static file...
server.listen(3005);
console.log("started on port 3005");

and testing it with apache bench

ab -c 1 -n 2 -k http://localhost:3005/test.html

leads to the Problem that the second request is never being answered.
If issuing manual several test with

ab -c 1 -n 1 -k http://localhost:3005/test.html

every thing is ok.
Using a memory store session by commenting out the "store" property works also OK even with:

ab -c 10 -n 10000 -k  http://localhost:3005/test.html

I came to this striped down example from a much bigger one, where I have the problem that "sometimes" request do not get answered and time out...

Any ideas?
Thanks
Ognian

Cannot access ._id using mongoose

Hi,

I am building an admin GUI to load all sessions by querying to MongoDB directly using mongoose.

Model

'use strict';

var mongoose = require('mongoose');
var Schema = mongoose.Schema;

var SessionModelConfiguration = new Schema({
    session: {
        cookie: {
            path: String,
            _expires: String,
            originalMaxAge: String,
            httpOnly: String,
            secure: String,
            expires: String,
            maxAge: String,
            data: {
                originalMaxAge: String,
                expires: String,
                secure: String,
                httpOnly: String,
                domain: String,
                path: String
            }
        },
        passwordless: String
    },
    expires: String
});

var Sessions_db = require('../configuration/database').Sessions_Access;
module.exports = Sessions_db.model('sessions', SessionModelConfiguration);

Controller

    var tempList_Session = [];
                Sessions_db.find(function(err, models_Sessions) {
                    for (var i = 0; i < models_Sessions.length; i++) {
                        tempList_Session.push({
                            id: models_Sessions[i]._id,
                            cookie: models_Sessions[i].session.cookie,
                            User: models_Sessions[i].session.passwordless,
                            expires: models_Sessions[i].expires
                        });
                    }

                res.render('User/index', {
                    tempList_Session: tempList_Session
                });
                })

Query : I cannot load ._id but yes i can load all other attributes. Please help

Is the list of servers just the seed or do you have to list every replica set member?

In a typical mongo connection string one only needs to list a couple servers as seed, and the full replica set configuration is discovered.

Specifically mongohq gives you a recommended connection string with 2 servers, but the replication set that's configured has 1 master, 2 primary and an arbiter.

If I set the server array property in the connect-mongostore config object to list the two servers in the monghq connection string, does it discover the full replication set since it's built on top of the mongo driver?

Configuring Timeouts

I'm trying to see what will happen when the database server goes away. I have configured the socketOptions with timeout for various numbers. I have set it to 10, and 10,000, and I have rebooted my Mongo servers. It sits for longer than 10 seconds, quite a bit longer. Any idea on why this would be so, and what I would need to do to get it to timeout? I'm hoping this never happens, but I'd like to be prepared.

This is what I have now:

"options":{"autoReconnect":true,"socketOptions":{"connectTimeoutMS":10000,"socketTimeoutMS":10000,"keepAlive":1,"encoding":"utf8"}}

broken for connect 3.0 +

If you upgrade to connect 3.0+, you'll see the tests no longer pass. I imagine that indicates the reason that I can't get this library to run under connect 3.0 with the README's instructions either.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.