session.req undefined in store.allow calls about racer-access HOT 13 CLOSED

've been looking into access control and after a while I think I've got it working pretty okay with racer-access. One thing I noticed though - in the default app the order of the middlewares are non-optimal. Basically, in order to get access control to work, you'll need to make sure cookies are parsed before racerBrowserChannel. In other words, put:

// Session middleware
.use(express.cookieParser())
.use(express.session({
secret: process.env.SESSION_SECRET || 'YOUR SECRET HERE'
, store: new MongoStore({url: mongoUrl, safe: true})
}))

above:

// Add browserchannel client-side scripts to model bundles created by store,
// and return middleware for responding to remote client messages
.use(racerBrowserChannel(store))
// Add req.getModel() method
.use(store.modelMiddleware())

Might it fix this for you?

from racer-access.

I did attempt this after reading your suggestion on the derbyjs google group, unfortunately the session parameter undefined.

from racer-access.

And you are sure you are using racer-access properly? I've now had time to do some more work on the matter and I know have a fully working version of the access control, so I'm pretty confident it'll work :)

from racer-access.

Ok, in follow up to my statement about a suspect section of code, I have again fired up node-inspector and found the piece I was referring to. I hope this will at least help identify the issue.

In /node_modules/derby/node_modules/racer/node_modules/share/lib/server/index.js
I set a break point on line 33, which is the session(this, stream, req); below:

ShareInstance.prototype.listen = function(stream, req) {
  session(this, stream, req);
};

There seem to be two execution paths that are called to hit this point, one which appears to pass in the session data, and the other that does not.

Path 1 stack trace:

ShareInstance.listen (index.js:33)
Store.createModel (Store.js:40)
getModel (Store.js:49)
setSessionUserId (index.js:80)
next (proto.js:190)
actions.pass (actions.js:77)
SessionStrategy.authenticate (session.js:61)
pass (index.js:315)
Passport.deserializeUser (index.js:326)

Store.createModel is as follows:

Store.prototype.createModel = function(options, req) {
  if (this.modelOptions) {
    options = (options) ?
      util.mergeInto(options, this.modelOptions) :
      this.modelOptions;
  }
  var model = new Model(this, options);
  this.emit('model', model);
  var stream = new Duplex({objectMode: true});
  stream.isServer = true;

  model._createConnection(stream, this.logger);
  this.shareClient.listen(stream, req);

  return model;
};

I noticed that the this.shareClient.listen(stream, req); is passing in a second parameter, as the function ShareInstance.prototype.listen = function(stream, req) appears to expect.

Contrast that with path 2's stack trace:

ShareInstance.listen (index.js:33)
(anonymous function) (server.js:34)
module.exports.middleware (server.js:583)
next (proto.js:190)
store.get.next (session.js:313)
(anonymous function) (session.js:337)
module.exports.MongoStore.get (connect-mongo.js:194)
Collection.findOne (collection.js:1010)
Cursor.nextObject (cursor.js:653)
Cursor.nextObject.commandHandler (cursor.js:635)

The (anonymous function) is from /node_modules/racer-browserchannel/lib/server.js

module.exports = function(store, options) {
  if (!options) options = {};
  if (options.reconnect == null) options.reconnect = true;

  store.on('model', function(model) {
    model.on('bundle', function(bundle) {
      bundle.racerBrowserChannel = options;
    });
  });

  store.on('bundle', function(browserify) {
    browserify.add(__dirname + '/browser');
  });

  var middleware = browserChannel(options, function(client) {
    var rejected = false;
    var rejectReason;
    function reject(reason) {
      rejected = true;
      if (reason) rejectReason = reason;
    }
    store.emit('client', client, reject);
    if (rejected) {
      // Tell the client to stop trying to connect
      client.stop(function() {
        client.close(rejectReason);
      });
      return;
    }
    var stream = createBrowserChannelStream(client);
    store.shareClient.listen(stream);
  });
  return middleware;
};

Note near the end the store.shareClient.listen(stream); which does not pass in a second parameter.

This is the closest I've been able to come to finding the source of the issue, I am not sure if it is relevant though.

from racer-access.

Well, then it's easy. You are using the wrong version of browserchannel. Use the latest from master and I think you'll be positively surprised :)

from racer-access.

Which, now when I think about it, of course is very difficult to "just know". I have no idea how I came to know that actually (might have been another guy here, another guy looked into access control previously without success). Anyway, check if that helps!

from racer-access.

And you are sure you are using racer-access properly? I've now had time to do some more work on the matter and I know have a fully working version of the access control, so I'm pretty confident it'll work :)

I am not sure.

Starting from an auto-generated project, in /lib/server/index.js I have the following, basically the relevant portions:

var derby = require('derby');
var racerAccess = require("racer-access");
...
derby.use(racerAccess);
...
var store = derby.createStore({
    db: liveDbMongo(mongoUrl + '?auto_reconnect', {safe: true})
  , redis: redis
});
this.store.allow("change", "prospects.*.legalName", function( docId, newDoc, docBeforeChange, session ){      
      console.trace( "prospect change", arguments );
});  

which does at least trigger the console.trace.

from racer-access.

Well, then it's easy. You are using the wrong version of browserchannel. Use the latest from master and I think you'll be positively surprised :)

Ok, I will try it out, thank you. I suppose I assumed it was up to date.

from racer-access.

Yeah, that looks alright. I think it's browser-channel messing stuff up.

from racer-access.

We are using:
git://github.com/codeparty/racer-access.git#master
and
git://github.com/codeparty/racer-browserchannel.git#master

and it works good. Maybe there's something else with your store.allow that's causing issues?

from racer-access.

and it works good. Maybe there's something else with your store.allow that's causing issues?

Yeah I deleted that specific message you are responding to here because it was due to a silly unrelated thing that I didn't notice.

from racer-access.

Cool - glad things seems to work much better!

from racer-access.

Cool - glad things seems to work much better!

Great, yes, after updating racer-browserchannel and having it also update its browserchannel module dependency I am successfully getting the session in my store.allow call, thanks very much :)

from racer-access.