Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ACL Allows Relation access even though DENY * #115

Closed
ritch opened this issue Dec 23, 2013 · 7 comments
Closed

ACL Allows Relation access even though DENY * #115

ritch opened this issue Dec 23, 2013 · 7 comments

Comments

@ritch
Copy link
Member

ritch commented Dec 23, 2013

@raymondfeng

See strongloop/loopback-example-access-control#2 (comment)

For a reproducible case.

Connect to #1362

@bajtos
Copy link
Member

bajtos commented Oct 15, 2014

@superkhau could you help us here and check if strongloop/loopback-example-access-control#2 can be still reproduced in loopback 2.x?

@bajtos bajtos added the bug label Oct 15, 2014
@superkhau
Copy link
Contributor

@bajtos it is reproducible. say we have two models, customers and reviews. if you create an acl that:

  1. denies access to reviews only = you can still see reviews via a curl request to /api/customers/1/reviews, meaning the acl on relations are not enforced
  2. denies access to customers and review = acl works properly and does not let the user access to api/customers/1 or /api/customers/1/reviews

@raymondfeng
Copy link
Member

What is your ACL?

@superkhau
Copy link
Contributor

  1. deny all for reviews, allow all for customers
  2. deny all for reviews, deny all for customers

@hotaru355
Copy link

I have just bumped into this issue and it is a major roadblock for us to get our server into production. I tried to track down the problem and would greatly appreciate your help. All I can say is that the before.** event is never fired for second level endpoints (/model/:id/relatedModel). Since the
application.js calls Model.checkAccess on this event, the entire ACL evaluation is disabled for those remotes. Clearly, those second level remotes must be setup differently than the first level remotes. Are those second level remotes maybe created after the eventhandler is registered?
Any hint would be greatly appreciated.

@ritch
Copy link
Member Author

ritch commented May 7, 2015

I have just bumped into this issue and it is a major roadblock for us to get our server into production. I tried to track down the problem and would greatly appreciate your help. All I can say is that the before.** event is never fired for second level endpoints (/model/:id/relatedModel).

I don't think this is correct. Or to be specific I don't think you are attaching your before hook to the correct model. Consider this endpoint:

/customers/1/reviews

This calls the Customers.prototype.__get__reviews method. It triggers the Customers before hook (not the Reviews). I have just confirmed this with [email protected].

A potential issue (depending on how you expect ACL to work) is that the set of Review access controls are not applied when accessing Review through a relation. Only the Customer ACL is enforced.

@ritch
Copy link
Member Author

ritch commented Jun 1, 2015

I'm closing this as its no longer an issue.

Improvements will come to relation access control. Keep an eye on #1362

@ritch ritch closed this as completed Jun 1, 2015
@altsang altsang removed the #tob label Jun 1, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants