flask-restplus-server-example icon indicating copy to clipboard operation
flask-restplus-server-example copied to clipboard

Different parameters for different roles

Open theveloped opened this issue 5 years ago • 5 comments

I'm wondering what would be the best way to allow a certain endpoint to have its accepted parameters/response differ depending on the role of the user that is requesting it.

Currently, in the project, a good example is the admin that does not require a recapthca code as opposed to other users. At the moment this is handled in the custom validation decorator.

I'm wondering if it would be better to make have multiple parameter schemas defined for the different user roles. In that way, one could also auto-document this. Would this be possible to implement or would a different approach be preferred?

theveloped avatar Jan 30 '19 15:01 theveloped

That is definitely possible to implement. I just didn't have this kind of need often, so I usually ended up using ad-hoc implementations here and there. The PR is very much welcome.

frol avatar Jan 30 '19 15:01 frol

Thank you for the quick feedback! Do you have an idea of the preferred location where one would make the devide? Personally I was looking at adding an optional parameter to the parametes/response decoractors that can make them apply only to a certain role. Another option would be to make the devision at a resource level and allow multiple resourcess (e.g. admin_resource, base_resource) to occupy the same endpoint.

theveloped avatar Jan 30 '19 16:01 theveloped

I haven't really thought about this before, so I don't have a solution in mind at the moment, but let me share some of my thoughts.

Given we want to customize serialization based on the permissions, those two components should be connected somehow. There are two obvious locations for them to integrate: at the serialization level (in schemas and parameters) and at the resource / endpoint level. I don't really like either of those. The first approach breaks composabilty, and the second will be too cumbersome at merging different schemas into a single specification. Thus, my thinking went into designing an extension to schemas that can be described as "advanced" optional fields or sub-schemas, and then design a helper for using this schema extension with permissions with/in permissions_required decorator.

frol avatar Jan 30 '19 20:01 frol

Any update with this one? Thank you

0xecute avatar Dec 02 '19 10:12 0xecute

@0xecute I don't work on this project anymore; though, I am fine to review and to merge PRs.

frol avatar Dec 02 '19 15:12 frol