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

Not MVC resources ? #249

Open
ghost opened this issue Aug 27, 2017 · 3 comments
Open

Not MVC resources ? #249

ghost opened this issue Aug 27, 2017 · 3 comments

Comments

@ghost
Copy link

ghost commented Aug 27, 2017

Hi,
Is it possible to use this module with resources wich are not MVC ?
I want to protect instance objects rather than routes.

I want to do something like this into my controller (i'm using routing-controllers):

@Get("/myaction/candidat_id/:candidat_id")
    test((@Param("candidat_id") candidat_id: number, @Req() request: Request, @Res() response: Response)   
    { 
        ...
 if (acl.isAllowed(myUserId, myArticleId, 'show') {
// display article
}    
}
@ghost
Copy link
Author

ghost commented Sep 1, 2017

Can anyone help me please?

@ghost ghost changed the title Non MVC resources ? Not MVC resources ? Sep 2, 2017
@ghost
Copy link
Author

ghost commented Sep 7, 2017

No idea about this question?

@john-osullivan
Copy link

john-osullivan commented Sep 22, 2017

Your question is kind of unclear, as Model View Controller doesn't really apply in this ACL context. I'm not using the middleware, so no ideas on how it would work there, but you can just make one resource for every article.

It looks like the pattern for max granularity is to:

  • give every object (i.e. a document in a MongoDB collection) its own resource (i.e. article-<id>)
  • give every user their own role (i.e. user-<id>)
  • create roles corresponding to each perm level for each resource (i.e. article-<id>/show, article-<id>/edit, etc.), such that role article-id/<show> has permission show on article-<id> while article-id/<edit> could have permissions show and read on article-<id>. That way you can get hierarchical permission levels with fewer operations when granting permission to a user.
  • grant a user permission on a resource by making their personal role a child of the given resource permission role (i.e. user-<id> becomes a child of article-<id>/show)

Not sure how it scales, but that provides the most granularity across the application. Note that I'm not a contributor to this library, just a developer in the process of implementing the pattern as described. Would love to hear from @manast about any issues he'd foresee as this pattern scales!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant