I know I shouldn’t be using collection allow and deny rules to set permission, but a package I’m using does it and I cannot get around at the moment.
TestCollection.allow({
insert: function(userId, file) {
if(userId)
return true;
return false;
},
read: function (userId) {
if(userId)
return true;
return true;
}
}
The issue is when a user login the app, the userId is undefined in the allow and deny rules. However, if I refresh the browser, then userId is found.
I tried to read Meteor Collection documentation and did not find anything. Please advise, thanks.
It sounds like you are executing these on the client. They must be run on the server.
I’ll try that, thank you.
The allow/deny rules are in server folder, still getting the error. Are there any ways the code can still be executed on the client?
I’ve found the issue. There’s a race condition from the package, and they suggested to send the userId as a parameter to prevent it. Everything seems to be working now
Can you point me to this, please?
Passing userId
from client to server for allow/deny
is a massive security risk.
The package is meteor-file-collection from https://github.com/vsivsi/meteor-file-collection. The code below is from their sample code.
// This autorun keeps a cookie up-to-date with the Meteor Auth token
// of the logged-in user. This is needed so that the read/write allow
// rules on the server can verify the userId of each HTTP request.
Deps.autorun(function () {
// Sending userId prevents a race condition
Meteor.subscribe('myData', Meteor.userId());
// $.cookie() assumes use of "jquery-cookie" Atmosphere package.
// You can use any other cookie package you may prefer...
$.cookie('X-Auth-Token', Accounts._storedLoginToken(), { path: '/' });
});
I understand the security concern, and we are working on rolling out own solution to avoid this package.
1 Like