Comments (6)
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.
from daybed.
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.
from daybed.
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.
from daybed.
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.
from daybed.
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 :-)
from daybed.
Fixed :)
from daybed.
Related Issues (20)
- Plug loads with Daybed functional tests
- Resolve relation fields
- Add definition PUT, that would create/update models HOT 4
- Plugin idea : Daybed history HOT 2
- Hide the system.Everyone and system.Authenticated pyramid paradigm from daybed users.
- Record validation error appears several times in response
- Sharing single records HOT 7
- GET model definition should return the required parameter for all fields. HOT 6
- Multiple time the same validation errors HOT 2
- Missing location header in PUT /models/:id
- PUT/POST /models/:modelid/records with an unknown field type in the model definition (stored in the database) raise a 500 HOT 4
- Mention appback among competitors
- Should store deserialized value of records HOT 1
- Revoke / update tokens
- Redis backend: colander.null is not JSON serializable
- ElasticSearch bottleneck for batch record creation HOT 1
- [CouchDB] Having a - in the model name breaks the server
- Include the list of plugins in the hello page.
- Document the Daybed search endpoint
- Let's define a model field as primaryKey that will be used on the POST /records and validated with the recordId on PUT HOT 6
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from daybed.