Implement ACLs in the best possible way

[leplatrem]

(previous title was "remove the notion of token")

Suggested by @AntoineCezar

Daybed should be as standard as possible in terms of REST and CRUD.

If any ACL feature (see #8) has to be implemented, it may be relevant to implement it in a separated frontend rather than in daybed core.

[almet]

I don't completely understand what do you mean by "in a separate frontend"? I think about daybed as an integrated way to handle data.

In this case, we need to be able to control who has access to the data we're talking about. HTTP and REST do have ways to handle this.

The token provides a way to be sure that everybody doesn't have the right to delete data, for instance.

If I understand correctly, you're suggesting that anyone is able to delete everything? How should we handle ACLs? What are you considering daybed core and what are the other parts?

All of this is a bit fuzzy to me: I see one product, named daybed. It can be composed of different parts, but if we want to do so, we need to explicit which are the different parts and how are we planning to use them / tie them together.

[AntoineCezar]

What I had in wind was not to remove ACLs. I just find strange having a token has the only response of creating a resource.
In addition, why being tied to one ACL implementation, to one storage implementation ?
I thougth the main point of daybed was "schemas validation has a service". If its the purpose, then I should be able to change the storage and the ACL. But I may be wrong.

[almet]

I understand better, thanks for the clarifications.

About pluggable backends, I agree, see #42 (and let's continue the discussion about that there).

What are you expecting as a result? Maybe should we change the way we're handling all this. For instance, we could have a token being defined by the user agent at data-creation time, and passed upon (that's what #8 is about). If you have a specific use case in mind, please share it, that could help us to find the best solution here.

About the use cases of daybed, it already can do schema validation as a service, but atm it's a "if this validates, then store the data", unless we ask daybed to do otherwise (for instance with a specific HTTP header, see https://github.com/spiral-project/daybed/blob/master/daybed/views/data.py#L41).

That may or may not be the best way to handle this, I'm open to suggestions, but that's the way we're currently doing this.

[leplatrem]

Hey merry christmas guyz !

We all agree that ACL can be necessary. However its seems odd to implement our own pattern.
Currently, this token thing implies a specific implementation on the client in order to store tokens for later use. In addition, clients like Backbone.js expects the created id as a response.

In the end, if we develop what's described in #8, the client may become too specific.

We could imagine daybed as fully open, and start a separate project (daybed-plaid !), which could act as a proxy/middleware, handling authentication and ACLs. (user/URI/permissions)

Like this, daybed remains a generic validation and storage backend. If we want to implement our own google forms, we will need to assemble and deploy a few separate components anyway, this ACL part would be just one of them.

[almet]

Yep, we'll need to split things anyway;

I'm pretty sure this ACL thing can be done in a standard way. I need to read a bit more the HTTP specification.

Also, I don't exactly know how pyramid handles ACLs so this is something I would like to play with. So, let's experiment, and put back our findings here!

And yeah, happy christmas everyone :-)

[Natim]

Fixed :)