insert failed: Access denied when calling setUserRoles or addUsersToRoles

[ghost]

I'm getting the error insert failed: Access denied in Chrome's dev tools whenever I use setUserRoles or addUsersToRoles. They still work, though - my test user is updated correctly every time.

[alanning]

I would think this is due to some kind of access restrictions on the client side updating of the users or roles collections. I'd start debugging by adjusting allow/deny rules and see if that helps.

Personally I don't allow client side updates of those collections at all. Rather I use meteor method calls to control any changes to database collections.

Sent from my phone

On May 14, 2014, at 9:23 AM, Carlo DiCelico notifications@github.com wrote:

I'm getting the error insert failed: Access denied in Chrome's dev tools whenever I use setUserRoles or addUsersToRoles. They still work, though - my test user is updated correctly every time.

—
Reply to this email directly or view it on GitHub.

[ghost]

Related question: how do you allow users to be able to have roles assigned to them via UI actions (i.e., create a resource and be made the admin of that resource) while simultaneously preventing users from being able to change/assign their own roles via the console?

Also, if you update collections via Meteor method calls, don't you miss out on simulation? And doesn't that essentially just amount to a conventional client/server architecture, obviating the need for Meteor?

Thanks!

[alanning]

Related question: how do you allow users to be able to have
roles assigned to them via UI actions (i.e., create a resource
and be made the admin of that resource) while simultaneously
preventing users from being able to change/assign their own
roles via the console?

I'm not sure how to do that with allow/deny rules on collections. This
seems like an excellent candidate for Meteor methods.

Also, if you update collections via Meteor method calls, don't
you miss out on simulation? And doesn't that essentially just
amount to a conventional client/server architecture, obviating
the need for Meteor?

Meteor methods are also simulated if you allow them to be sent to the
client (ie. don't put the code in server-side only places like a server
folder). My understanding is that Meteor methods are different than
conventional ajax calls in two ways:

• Meteor methods can be simulated
• Meteor methods are executed in a meteor-context aware fiber

For our use case, we actually don't use simulation since we don't want the
client to think they have successfully done something when they actually
haven't. Meteor is still a core piece of technology for our service for
its other benefits, not the least of which is its simple abstraction
regarding the real-time distribution of data.

On Wed, May 14, 2014 at 1:06 PM, Carlo DiCelico notifications@github.comwrote:

Related question: how do you allow users to be able to have roles assigned
to them via UI actions (i.e., create a resource and be made the admin of
that resource) while simultaneously preventing users from being able to
change/assign their own roles via the console?

Also, if you update collections via Meteor method calls, don't you miss
out on simulation? And doesn't that essentially just amount to a
conventional client/server architecture, obviating the need for Meteor?

Thanks!

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/40#issuecomment-43108435
.

[ghost]

I'm not sure how to do that with allow/deny rules on collections. This
seems like an excellent candidate for Meteor methods.

I'm not sure I follow. Since insert/update/remove are implemented as Meteor methods, this seems like wrapping a Meteor method in another Meteor method for no good reason. Granted, you can do more than just CRUD in a Meteor method, but you could also just use collection hooks or even just a simple callback passed into insert/update/remove. Plus, if I have a Meteor method that assigns a user as the admin of a resource, since that method is executed in the context of that user, in order to update that user's role, he would still need to be able to update his own role.

At any rate, I think I should at least be able to limit updating a user's role to that user's group only via allow/deny rules, which may be enough.

Thanks again for answering my questions!

[sferoze]

I am getting this issue. Why can I not add user to roles client side? As long as I have my allow rules setup it should work

[mitar]

Using allow rules is getting deprecated in Meteor. Create Meteor methods and call roles functions from there.

[sferoze]

@mitar Oh really? no more allow deny rules. very interesting. Do you know of any documentation where they provides this update and what will replace it?

[mitar]

See here some information: meteor/meteor#5559

You just do Mongo operations from inside Meteor methods. This is the recommended way.