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

Parent attributes with child creation (fixes #803, #101) #828

Merged
merged 18 commits into from Oct 4, 2016

Conversation

leplatrem
Copy link
Contributor

@leplatrem leplatrem commented Sep 21, 2016

Fixes #803, Fixes #101

  • Add failing tests
  • Fix tests.
  • Update documentation
  • Bump protocol
  • Add a changelog entry.

@leplatrem leplatrem force-pushed the 803-parent-metadata-with-child-creation branch from 5939c63 to 9eb3249 Compare September 26, 2016 22:46
@leplatrem
Copy link
Contributor Author

I applied the same logics to bucket metadata (collection:create and group:create gives access to (parent) bucket metadata).

Maybe we shouldn't and keep it for record+collection metadata only?

What do you think @enguerran / @magopian ?

@magopian
Copy link
Contributor

I don't see any drawbacks in having the same behavior. Do you think it could be a security issue or something?

Copy link
Contributor

@magopian magopian left a comment

Choose a reason for hiding this comment

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

Commented ;)


- Parent metadata is now readable if children creation is allowed
- Now returns a ``412`` instead of a ``403`` if the ``If-None-Match: *`` header is
provided and the ``create`` permission is allowed
Copy link
Contributor

Choose a reason for hiding this comment

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

Do you want to add a note about the fact that GETing the list of records will return an empty list (and not a 403) if the user doesn't have the read permission on the collection, and has not created any records yet? (as discussed in the issue #803)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I believe test_list_can_be_obtained_if_allowed_to_create and test_list_is_denied_if_not_allowed_to_create cover this (?)

Copy link
Contributor

Choose a reason for hiding this comment

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

Sure, the tests and the code are there, but how was wondering if you wanted to add a note to the changelog about that?

def test_list_can_be_obtained_if_allowed_to_create(self):
resp = self.app.get('/buckets/beer/collections', headers=self.bob_headers)
self.assertEqual(len(resp.json['data']), 1)
self.assertEqual(resp.json['data'][0]['id'], 'barley')
Copy link
Contributor

Choose a reason for hiding this comment

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

I thought one could only see the list of his own created entries, or is that only for records? Is it expected that Bob can see this collection, while he only has the "create" permission on collections, and the 'barley' collection has been created by Alice?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

the barley collection was created by Bob (and Alice is allowed to create records). But you're right, the current version of the patch is not correct. I added a failing test that shows that users should only see their own records in this particular case.

@leplatrem
Copy link
Contributor Author

Do you think it could be a security issue or something?

I wouldn't say a security issue, but it makes the impact of the change bigger.

@leplatrem leplatrem changed the title Add failing test for parent metadata with child creation (ref #803) [WIP] parent metadata with child creation (ref #803) Sep 27, 2016
@enguerran
Copy link
Member

I cannot take a decision on this as I am not yet aware enough of kinto permissions system. I do discussed with @Natim. But I cannot understand how my needs are different from formbuilder's.

Extract from https://github.com/Kinto/formbuilder/blob/master/formbuilder/actions/server.js:

  • bucket: { "collection:create": ["System.Authenticated"], "write": [] }
  • collection (a form): { "record:create": ["System.Authenticated"], "read": [userId] }

The extra need is

We also want to be able to list the collection the user can administrate. It makes it impossible if we give the read permission on the collection.

In formbuilder, access are controlled by "encoded" URL. If you have the admin token, you'll have access to the collection's administration. If you have the user token, you'll have access to the form and can only create a record. As far as I could understand formbuilder's code.

If I create a collection of "url with admin token" in a specific user's default bucket, I guess an admin could have access to several forms' administration.

Again, I am just a beginner user of kinto and maybe I am wrong.

@leplatrem leplatrem changed the title [WIP] parent metadata with child creation (ref #803) Parent metadata with child creation (ref #803) Sep 28, 2016
@leplatrem leplatrem changed the title Parent metadata with child creation (ref #803) Parent metadata with child creation (fixes #803, #101) Sep 28, 2016
@leplatrem
Copy link
Contributor Author

This cannot be reviewed without going through each commit. I'm very confident in the code and the test suite though.

I changed and simplified a lot of code. Basically:

  • I renamed many variables and method names in the authorization code. It is now more consistent with what it does.
  • I added a level of keys in the inheritance tree of permissions. Before it used to have some concat and join strings for the keys.
  • There is now a read:attributes permission in the inheritance tree of permissions. It is not exposed yet to the HTTP API but we could eventually. It gives the finer grain we need (ETag is only returned on GET #110) to allow reading attributes and not the whole list of records.
  • I changed the way the authorization code relies on settings. This paves the way for No inheritance for permissions forced in settings #350
  • I removed the specific case we had for allowing listing buckets. It now behaves as other: if you can create buckets, you can receive an empty list on /buckets if none are accessible to you.

Don't hesitate to ping me for questions!

@magopian r?

allowed = shared is not None
# If allowed to create this kind of object on parent, then allow to obtain the list.
if len(bound_perms) > 0:
parent_uri = bound_perms[0][0] # Bounds perms are ordered.
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This takes the first object URI of the bound perms.
But the first is not always the parent! (Ex. record → collection → bucket)
So I guess this is wrong for records, because it will check that the user has the permission record:create on /buckets/test which will never be the case.

@leplatrem leplatrem force-pushed the 803-parent-metadata-with-child-creation branch from f87e8d6 to 8e238d4 Compare October 3, 2016 14:53
@leplatrem
Copy link
Contributor Author

Final r+ my friends?

@leplatrem leplatrem merged commit bb8e66d into master Oct 4, 2016
@leplatrem leplatrem deleted the 803-parent-metadata-with-child-creation branch October 4, 2016 07:58
@leplatrem
Copy link
Contributor Author

\o/

@leplatrem leplatrem changed the title Parent metadata with child creation (fixes #803, #101) Parent attributes with child creation (fixes #803, #101) Oct 25, 2016
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.

None yet

4 participants