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

Add documentation about Buckets and permissions #36

Closed
wants to merge 15 commits into from
Closed

Conversation

@Natim
Copy link
Member

@Natim Natim commented May 5, 2015

No description provided.

@Natim Natim force-pushed the permissions-api branch from 8bb4961 to 46e500c May 5, 2015
Buckets
#######

Buckets are a way to group users around some data.

This comment has been minimized.

@almet

almet May 5, 2015
Member

This definition doesn't say much. "Buckets are a group of collections, which can be shared accross users" seems more close to what I have in mind.

Buckets are a way to group users around some data.

Basically has got an and a list of principals that can administrate
it.

This comment has been minimized.

@almet

almet May 5, 2015
Member

Sorry, what?

This comment has been minimized.

@almet

almet May 5, 2015
Member

I believe we should have the same set of permissions we have for other objects (read, create, update, delete)


{
"id": "servicedenuages",
"principals": ["email:natim@example.com"]

This comment has been minimized.

@almet

almet May 5, 2015
Member

Having "principals" returned here doesn't make a lot of sense to me, we should probably have a list of permissions and eventually a group "owners"

This comment has been minimized.

@Natim

Natim May 5, 2015
Author Member

I don't think we want fined permissions on the bucket itself, do you have a usecase in mind that needs it?

===========

Creating a collection inside a bucket enable all buckets principals to
administrate the collection.

This comment has been minimized.

@almet

almet May 5, 2015
Member

I feel this should be handled by more fine grained permissions

There are two kinds of data linked to a bucket:

- collections
- groups

This comment has been minimized.

@leplatrem

leplatrem May 5, 2015
Contributor

I believe it makes more sense to talk about "roles" instead of "groups"

This comment has been minimized.

@Natim

Natim May 5, 2015
Author Member

Well having Daybed experience in mind I don't think it helps :) groups carries less meaning than roles. Is musicians a role?

This comment has been minimized.

@almet

almet May 5, 2015
Member

I don't understand what a role is, but I do with a group. Why are you suggesting we could use "role"?

This comment has been minimized.

@Natim

Natim May 5, 2015
Author Member

A role is a category of people that can do specific actions (administrators, moderators, employees, managers, etc.)

Collections
===========

Creating a collection inside a bucket enable all buckets principals to

This comment has been minimized.

@leplatrem

leplatrem May 5, 2015
Contributor

Principals is weird word. We probably don't want to use it.

@Natim Natim force-pushed the permissions-api branch from 28ec1d4 to 73441e2 May 5, 2015
Buckets
#######

Buckets are a group of collections, shared between users, with fined

This comment has been minimized.

@almet

almet May 5, 2015
Member

fine-grained

permissions on the data stored inside.

Basically a bucket have got an id and a list of people identifier that
can administrate it.

This comment has been minimized.

@almet

almet May 5, 2015
Member

I still believe we shouldn't go with this solution. We should have permissions associated.

===========

Creating a collection inside a bucket enable all buckets owners to
administrate the collection.

This comment has been minimized.

@almet

almet May 5, 2015
Member

administrate doesn't convey a lot of meaning. "To have all permissions on the collection items" seems a better description to me.

This comment has been minimized.

@Natim

Natim May 5, 2015
Author Member

Does: To have all permissions on all bucket collections and bucket collections items. works for you?

This comment has been minimized.

| - id |
| - data |
| - members |
+---------------+

This comment has been minimized.

@almet

almet May 5, 2015
Member

I agree with the schema!

@Natim Natim force-pushed the permissions-api branch from b47a7d7 to 673b1cf May 6, 2015
The data is not anymore linked to a specific user that only has access
to her private data but is linked to the bucket and managed by
bucket's owners (those who have the ``write_bucket`` permission on the
bucket.

This comment has been minimized.

@almet

almet May 9, 2015
Member

From this description, I cannot tell how a bucket is different from a collection. My understanding (not when reading this text) is that buckets are a container of collections, but this text kinda says it's like a collection, but open for others.

So, what's the right definition? :)


**Optional parameters**

- ``permissions``: A mapping object that defines the list of user for

This comment has been minimized.

@almet

almet May 9, 2015
Member

the list of principals.


- ``permissions``: A mapping object that defines the list of user for
each permission
- ``write_bucket``: The list of users principals that have

This comment has been minimized.

@almet

almet May 9, 2015
Member

admins finally looks like a better option then (yes, I know).

- ``write_bucket``: The list of users principals that have
administration permissions on the bucket, the creator is
automatically added to the owner list.
- ``create_groups``: Permission to create new groups

This comment has been minimized.

@almet

almet May 9, 2015
Member

I think only admins should be allowed to do that.


- **read**: It means that the given user or group of users have
got read only access to the object
- **write**: It means that the given user or group of users have

This comment has been minimized.

@almet

almet May 9, 2015
Member

I would actually differenciate between create and update (which seems to be both in the "write" option here).

attributes (schema and permissions)
- **write_collection**: It is a write access to the collection
attributes (schema and permissions)
- **create_records**: It is a permission that let one create new records

This comment has been minimized.

@almet

almet May 9, 2015
Member

oh ok it's actually here.

As soon as there is a need to let people work on the same records set
or to work with the same collection, the solution is to create a :ref:`bucket <buckets>`.

:ref:`Buckets <buckets>` gives a public unique name to the collection.

This comment has been minimized.

@leplatrem

leplatrem May 11, 2015
Contributor

With the bucket name as prefix, the collection name becomes unique. (?)

This comment has been minimized.

@almet

almet May 11, 2015
Member

We're currently changing all the layout of the docs and doing another pass on this proposal. The idea is to have a default bucket for each user.

@almet
Copy link
Member

@almet almet commented May 12, 2015

I've updated. We probably should upate the APIs as well, but I think it's wiser to wait for feedback first.


.. _buckets:

:ref:`Buckets <buckets>` enables the creation of collections handled by

This comment has been minimized.

@leplatrem

leplatrem May 13, 2015
Contributor

enable

a group of ref:`User identifiers <user-identifiers>`.

All collections are created in a bucket. By default, it uses the connected
user's bucket (bucket only the connected user has access to).

This comment has been minimized.

@leplatrem

leplatrem May 13, 2015
Contributor

By default, the bucket of the current user is used.

(the second part between parenthesis could not be processed by my brain at this time of the day)

user's bucket (bucket only the connected user has access to).

:ref:`Buckets <buckets>` can be seen as namespaces: you can have different
collections using the same name, but stored in different buckets, so their

This comment has been minimized.

@leplatrem

leplatrem May 13, 2015
Contributor

collections can have the same name across different buckets

collections using the same name, but stored in different buckets, so their
names don't collide.

Data (everything stored in a bucket: collections, groups and records) is

This comment has been minimized.

@leplatrem

leplatrem May 13, 2015
Contributor

groups appear out of the blue here

names don't collide.

Data (everything stored in a bucket: collections, groups and records) is
not anymore linked to a specific user that only has access to her private data

This comment has been minimized.

@leplatrem

leplatrem May 13, 2015
Contributor

anymore

Data (everything stored in a bucket: collections, groups and records) is
not anymore linked to a specific user that only has access to her private data
but is linked to the bucket and managed by bucket's owners (those who have the
``write_bucket`` permission on the bucket.

This comment has been minimized.

@leplatrem

leplatrem May 13, 2015
Contributor

Do mention that notion of permission here. It comes after.


- ``permissions``: A mapping object that defines the list of users for each of
the following permissions defined in the table below. In any case (even if
not specified), the current logged-in user will get access to the bucket.

This comment has been minimized.

@leplatrem

leplatrem May 13, 2015
Contributor

The part after In any case is not clear at all. It should be put above, after the optionnally specifying....

+------------------------+---------------------------------+
| Permission | Description |
+========================+=================================+
| ``write_bucket`` | The list of users principals |

This comment has been minimized.

@leplatrem

leplatrem May 13, 2015
Contributor

user principals come out of the blue here

| Permission | Description |
+========================+=================================+
| ``write_bucket`` | The list of users principals |
| | that have administration |

This comment has been minimized.

@leplatrem

leplatrem May 13, 2015
Contributor

administration permissions come out of the blue here (it was mentioned as owner before)

Content-Type: application/json; charset=UTF-8

{
"id": "{bucket_id}",

This comment has been minimized.

@leplatrem

leplatrem May 13, 2015
Contributor

here those braces bring confusion. Better put some random UUID

"write_bucket": ["uid:basicauth_5d127220922673e346c0ebee46c23e6739dfa756"],
"create_groups": [],
"create_collections": [],
}

This comment has been minimized.

@leplatrem

leplatrem May 13, 2015
Contributor

I would have prefered something like that :


        "permissions": {
            "admins": ["uid:basicauth_5d127220922673e346c0ebee46c23e6739dfa756"],
            "groups": {
                "create": []
            },
            "collections": {
                "create": []
            },
        }

}
}

There are two kinds of data linked to a bucket: **collections** and **groups**.

This comment has been minimized.

@leplatrem

leplatrem May 13, 2015
Contributor

This is useless here, better put it above in the introduction


Creating a collection inside a bucket enables all buckets users with
the ``write_bucket`` permission to have all permissions on all bucket's
collections and associated records.

This comment has been minimized.

@leplatrem

leplatrem May 13, 2015
Contributor

Creating a collection inside a bucket enables [..] on all buckets collections ? → not clear :)

.. code-block:: http

> PUT /buckets/servicedenuages/collections/mushrooms HTTP/1.1
< 201 Created

This comment has been minimized.

@leplatrem

leplatrem May 13, 2015
Contributor

what is this ?

"members": ["email:alexis@example.com"]
}

It is now possible to use the ``groups:moderators`` principal to describe

This comment has been minimized.

@leplatrem

leplatrem May 13, 2015
Contributor

group:moderators ?

This comment has been minimized.

@Natim

Natim May 13, 2015
Author Member

We've just created the group moderators the line above, I don't understand the question.

This comment has been minimized.

@leplatrem

leplatrem May 13, 2015
Contributor

group: singular.

This comment has been minimized.

@Natim

Natim May 13, 2015
Author Member

Ok yes good point :)

{
"id": "payments",
"acls": {

This comment has been minimized.

@leplatrem

leplatrem May 13, 2015
Contributor

acls is not suitable IMO :)

permissions is a lot better, and consistent with buckets

"permissions": {
"read_record": ["userid:<buyer-id>", "appid:<seller-appid>"]
}
}

This comment has been minimized.

@leplatrem

leplatrem May 13, 2015
Contributor

Same here, I would have liked this layout:

"permissions": {
   "records": {
       "read": ["userid:<buyer-id>", "appid:<seller-appid>"]
   }
}
}
}
Moderators are special persons with special rights. Rather than adding

This comment has been minimized.

@leplatrem

leplatrem May 13, 2015
Contributor

rights --> permissions

permissions on all records.
- Anybody can read everything.

A "microblog" bucket is created, where new groups can be created by

This comment has been minimized.

@leplatrem

leplatrem May 13, 2015
Contributor

A twitter bucket is created

@Natim Natim force-pushed the permissions-api branch from 0916bbd to 3c1ad73 May 13, 2015
@Natim Natim force-pushed the permissions-api branch from 3c1ad73 to 61486be May 13, 2015
@almet
Copy link
Member

@almet almet commented Jun 1, 2015

OK, I think we're good with this, should we merge?

@almet almet closed this Jun 2, 2015
@almet almet deleted the permissions-api branch Jun 2, 2015
@Natim
Copy link
Member Author

@Natim Natim commented Jun 4, 2015

Is the close an answer to the question?

@almet
Copy link
Member

@almet almet commented Jun 4, 2015

Sorry for the context miss here. This branch has been merged in another temporary one which contains all work related to permissions and buckets. see #46

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

Successfully merging this pull request may close these issues.

None yet

3 participants