-
-
Notifications
You must be signed in to change notification settings - Fork 10
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 generic "resource" endpoint #102
Comments
This is largely done... we have the following: And a separate endpoint to get a single resource by ID: After adding the additional endpoint to get by ID, I'm curious about changing the PUT and DELETE to require a Internally, an
This reminds me... permissions are respected on the farmOS server, but in the Aggregator we created separate OAuth oauth_scopes = {
"farm:create": "Create farm profiles",
"farm:read": "Read farm profiles",
"farm:update": "Update farm profiles",
"farm:delete": "Delete farm profiles",
"farm:authorize": "Complete the OAuth Authorization Code cycle for farm profiles",
"farm.info": "Read farmOS server info",
"farm.logs": "Access logs",
"farm.assets": "Access assets",
"farm.terms": "Access terms",
"farm.areas": "Access areas",
} This doesn't work very well with a single Another complication is that it's possible for a request to one resource type to That said, we can still introduce scopes to limit the CRUD operations an Aggregator user/api-key has (only read resources, vs create and read resources). Anything beyond this and the Aggregator really turns into something "delegated to grant further access" - I think this is outside the scope of OAuth2 & the farmOS -> Aggregator capability :-) But its worth re-iterating why we added scopes + api-keys... largely as another security measure so that a service using the Aggregator API only has the minimum access needed (likely doesn't need the ability to DELETE farms from the aggregator, perhaps only GET resources from farms). At the very least we need a resource_scopes = {
"farm.resources.get": "Read farmOS resources",
"farm.resources.put": "Update farmOS resources",
"farm.resources.post": "Create farmOS resources",
"farm.resources.delete": "Delete farmOS resources",
} Curious for your thoughts @mstenta |
We decided to remove all of the "resource" related scopes. Removing the old |
Since farmOS 2x will have many more entities exposed via the API as JSONAPI resources, it becomes pretty trivial to support these additional resources. Entity permissions are respected.
farmOS.py will have a
client.resource.get()
method which can be used to request these other resources (files, data stream, roles, etc.). If nobundle
is provided, farmOS.py assumes the resource name isentity--entity
eg:file--file
.The text was updated successfully, but these errors were encountered: