Owner exception in ender.checkRestrictions()

[kasp1]

This function checks whether the user requesting the endpoint meets the endpoint restrictions and if not, it will terminate the request with an error.

Restrictions (if any) are in the endpoint's restrict property, which may contain either true to restrict the endpoint only for logged-in users or it may contain a string with comma-separated list of user roles that the user has to possess in order to be able to perform the request.

We should modify this function if there is a role restriction to behave differently in case of GET, GET-one, PUT and DELETE request methods:

1. Check if the user meets role requirements and proceed if yes, if not:
2. Check if the endpoint contains ownership: true option and terminate the request if not, if yes:
3. Check if a database collection with the name in URL exists var collection = g.ender.endFromReq(req).split('/')[1] and terminate the request if not, if yes:
4. Check if the user's ID (from req.session) equals the ID that was set in the owner property of the record that's being affected by the request and terminate the request if not. If yes, proceed.

The above process applies for GET-one, PUT and DELETE. POST shouldn't be affected by ownership at all, because since data are created with POST, the ownership is yet being created during a POST reqeust.

In case of GET-many, the generic handler should only return records where the session ID matches the owner ID.

The long story

Regular application with any user content usually needs to:

1. Assign the ownership of created content to its creator (user) and limit other users in manipulating with foreign content.
2. 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:

1. All database collections/tables would have an "owner" property/column in a similar way they now all have the "id" property/column.

2. 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.

3. 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.