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

Adds CLP API to Schema router #898

Merged
merged 9 commits into from
Mar 11, 2016
Merged

Adds CLP API to Schema router #898

merged 9 commits into from
Mar 11, 2016

Conversation

flovilmart
Copy link
Contributor

No description provided.

@drew-gross
Copy link
Contributor

Personally I'd rather have this be part of the existing route rather than a new route (ie just add more info to the existing response to GET /schemas.

@flovilmart
Copy link
Contributor Author

fine by me, what parameter do you suggest
{
className: "className",
permissions: {}
}
it permissions is sent as an empty obj, that locks the object down.

@drew-gross
Copy link
Contributor

I like long names e.g. classLevelPermissions. That aslo leaves room for pointer permissions in a separate key called pointerPermissions.

@flovilmart
Copy link
Contributor Author

OK good, so on the PUT for the schema, and on the GET, I add the permissions to the current result?

@drew-gross
Copy link
Contributor

GET sounds right, for PUT I think just replace the permission on the _SCHEMA object entirely with whatever the include in the PUT, and make no modifications if the key isn't included. POST should probably support CLPs too, which shouldn't be too hard. The dashboard won't need it but people using the schemas API for their own purposes would probably find it handy.

@flovilmart
Copy link
Contributor Author

alrighty!

@facebook-github-bot
Copy link

@flovilmart updated the pull request.

@codecov-io
Copy link

Current coverage is 91.42%

Merging #898 into master will increase coverage by +0.07% as of c9d4569

@@            master    #898   diff @@
======================================
  Files           73      73       
  Stmts         4324    4383    +59
  Branches       863     876    +13
  Methods          0       0       
======================================
+ Hit           3950    4007    +57
  Partial         10      10       
- Missed         364     366     +2

Review entire Coverage Diff as of c9d4569

Powered by Codecov. Updated on successful CI builds.

@@ -76,6 +76,17 @@ var requiredColumns = {
_Role: ["name", "ACL"]
}

let CLPValidKeys = ['find', 'get', 'create', 'update', 'delete'];
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about addField?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Didn't knew it existed :) what's the full list?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

btw addField is never checked anywhere.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These 6 are the full list, you can verify using dashboard.parse.com. We should probably start checking addField :p Schema.js should be able to handle it without too much trouble, since there is that 'freeze' parameter.

@facebook-github-bot
Copy link

@flovilmart updated the pull request.

1 similar comment
@facebook-github-bot
Copy link

@flovilmart updated the pull request.

return;
}
Object.keys(perms).forEach((key) => {
if (CLPValidKeys.indexOf(key) == -1) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this function doesn't go far enough - it should also validate the contents of the keys to make sure they contain only roles and users. Also my preference would be to have it return true/false rather than throw.

@drew-gross
Copy link
Contributor

I think since this is such a security critical feature we should do much more thorough testing than usual - verify that users/roles don't gain permissions after a failed attempt to change permissions, verify that they don't gain one permission after a different permission was modified, etc. At the very least we need to do some tests for users as well as for roles, which I don't currently see. Other than that and the stricter validation in validateCLP this looks good :)

@flovilmart
Copy link
Contributor Author

Agreed with all that!

@facebook-github-bot
Copy link

@flovilmart updated the pull request.

@facebook-github-bot
Copy link

@flovilmart updated the pull request.

})
});

it('should not be able to add a field', done => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wrong name

@drew-gross
Copy link
Contributor

I see lots of tests for public permissions and for permissions on roles, but still none for users. Also we should have some tests for setting a permission to false explicitly (that really should have been done in the original CLP tests but now is as good a time to add them as any)

@facebook-github-bot
Copy link

@flovilmart updated the pull request.

@flovilmart
Copy link
Contributor Author

@drew-gross I updated, the setting permission to false blacklist, I can revert that if we don't want it now. Added 2 test cases with multiple users, as well as role and public

@facebook-github-bot
Copy link

@flovilmart updated the pull request.

className: schema._id,
fields: mongoSchemaAPIResponseFields(schema),
};
if (schema._metadata && schema._metadata.class_permissions) {
result.classLevelPermissions = schema._metadata.class_permissions;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One last request: Can you have the response always include the classLevelPermissions key? Have it return something equivalent to how the server behaves if there is actually no _metadata or _metadata.class_permissions, which appears to be the same as public everything.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No problem!

@drew-gross
Copy link
Contributor

One more small request. Sorry for having to go back and forth so many times on this.

@flovilmart
Copy link
Contributor Author

Don't be sorry, that's part of the process. In that case should we store it as the default?

@drew-gross
Copy link
Contributor

We shouldn't be making any database writes as part of a GET query, but I would be cool with saving in POST/PUT if you want to do that. Thats definitely optional though.

@drew-gross
Copy link
Contributor

Feel free to merge assuming tests pass.

@facebook-github-bot
Copy link

@flovilmart updated the pull request.

flovilmart added a commit that referenced this pull request Mar 11, 2016
@flovilmart flovilmart merged commit 1e7e4fe into master Mar 11, 2016
@flovilmart flovilmart deleted the flovilmart.CLPAPI branch March 11, 2016 05:32
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

Successfully merging this pull request may close these issues.

4 participants