You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
All collections should have the "owner" property by default, where user ID or 0 should be stored.
Similar to how all collections have the "id" property at the moment.
The long story
Regular application with any user content usually needs to:
Assign the ownership of created content to its creator (user) and limit other users in manipulating with foreign content.
Allow administrators to manipulate with any content.
Apiko can help with the second point, because while POST (CREATE) endpoint of a database collection can be open to anyone, GET (READ), PUT (UPDATE) and DELETE endpoints can be restricted to certain user roles, like "admin".
Restricting GET, PUT and DELETE endpoints to specific user roles will on the other side prevent anyone else from using these endpoints, including the content creator if they don't possess the specified user roles.
A solution is to create custom endpoint handlers for each of the mentioned restricted endpoints that would also check whether the user, who is trying perform the request, is also the creator of the requested content and such custom handler would allow them to successfully perform the request in that case.
This common practice could be further automated with Apiko in the following way:
All database collections/tables would have an "owner" property/column in a similar way they now all have the "id" property/column.
The generic POST (CREATE) handler would be modified to check if there is a user ID associated with the currently active session upon a request and if yes, the user ID would be considered the "creator/owner" ID of the content that's being created using the POST request. If there is no session ID specified, 0 would be put to the "owner" property instead. Note that if any Apiko server would need to have every single record of a user content assigned with a user, then the specific POST endpoind could be already restricted to logged-in users only.
If any of the other endpoints (GET, GET-one, PUT, DELETE) would be restricted by any user role, the generic handlers would automatically check if there is the "ownership: true" setting mentioned in the given endpoint's settings/properties and if yes, it would further check if the requesting client is logged in -> if the user's ID == to the owner ID -> it would allow to successfully perform the endpoint request even if the user doesn't possess the required user roles.
The text was updated successfully, but these errors were encountered:
All collections should have the "owner" property by default, where user ID or 0 should be stored.
Similar to how all collections have the "id" property at the moment.
The long story
Regular application with any user content usually needs to:
Apiko can help with the second point, because while POST (CREATE) endpoint of a database collection can be open to anyone, GET (READ), PUT (UPDATE) and DELETE endpoints can be restricted to certain user roles, like "admin".
Restricting GET, PUT and DELETE endpoints to specific user roles will on the other side prevent anyone else from using these endpoints, including the content creator if they don't possess the specified user roles.
A solution is to create custom endpoint handlers for each of the mentioned restricted endpoints that would also check whether the user, who is trying perform the request, is also the creator of the requested content and such custom handler would allow them to successfully perform the request in that case.
This common practice could be further automated with Apiko in the following way:
All database collections/tables would have an "owner" property/column in a similar way they now all have the "id" property/column.
The generic POST (CREATE) handler would be modified to check if there is a user ID associated with the currently active session upon a request and if yes, the user ID would be considered the "creator/owner" ID of the content that's being created using the POST request. If there is no session ID specified, 0 would be put to the "owner" property instead. Note that if any Apiko server would need to have every single record of a user content assigned with a user, then the specific POST endpoind could be already restricted to logged-in users only.
If any of the other endpoints (GET, GET-one, PUT, DELETE) would be restricted by any user role, the generic handlers would automatically check if there is the "ownership: true" setting mentioned in the given endpoint's settings/properties and if yes, it would further check if the requesting client is logged in -> if the user's ID == to the owner ID -> it would allow to successfully perform the endpoint request even if the user doesn't possess the required user roles.
The text was updated successfully, but these errors were encountered: