Skip to content
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

Different parameters for different roles #130

Open
theveloped opened this issue Jan 30, 2019 · 5 comments
Open

Different parameters for different roles #130

theveloped opened this issue Jan 30, 2019 · 5 comments

Comments

@theveloped
Copy link

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?

@frol frol added the question label Jan 30, 2019
@frol
Copy link
Owner

frol commented Jan 30, 2019

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.

@theveloped
Copy link
Author

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.

@frol
Copy link
Owner

frol commented Jan 30, 2019

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.

@0xecute
Copy link

0xecute commented Dec 2, 2019

Any update with this one?
Thank you

@frol
Copy link
Owner

frol commented Dec 2, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants