Private and public endpoints

[Cornos (Oussama)]

Imagine we have two endpoints to get Products informations.
In this product informations we have a name and price of the product.

The first endpoint is for authenticated users and have access to the names and prices of the products.

The second one is public, and have only access to the names of the products.

What is the best pattern in this kind of situation:
Creating private handler function and public handler function separately? If yes, should I create as much as endpoints as user scope (public, private, admin…) if I want different access for each user role?
Or use the same handler function and add a parameter like IsPublic ?
I can’t find a key word to read about this.

[kanishka]

I am not an expert here, but my first reaction would be to create one route for all levels of access, and have two layers of services. An outer service would receive some sort of auth token and resolve that to a user id and then create a request to another http service with an http header indicating the user id.

Once you have a user id, you can create some library functions that references a persisted mapping from users to their access level. Each endpoint would look up the user’s access level and then generate the appropriate request based on the access level.

For the keywords related to the authorization implementation you can read about different approaches to authorization such as RBAC.

[Cornos (Oussama)]

All right
Yeah I totally agree about authorization and authentication to add in the middleware.
But what about if we had a third field containing the history of all sold product.

I want to give access all the history of sold product for the admin and only the history of the last month in public.

Should I use the same function with a boolean parameter like isPublic for both or create separate function?
I mean what is the better way to do that?

[kanishka]

Your authorization function can return a policy which describes the fields which are allowed, and the view generation can use that list of attributes to build the view. It makes your view function much more complicated though. I think I would just branch based on the status of the user, in the view function. So the authorization can stay simpler for now, at the cost of being less declarative.

I haven’t looked at oso, but it might also have some guidance related to this.