-
Notifications
You must be signed in to change notification settings - Fork 73
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
Enable security stuff in Open API definition #4
Conversation
This is useful for defining things such as securityDefinitions (see https://swagger.io/docs/specification/2-0/authentication/).
It can be used to document the security scheme to use for all methods of a Blueprint at once.
Ideally, the registration of the security definition would be done the same way definitions are registered. See this issue: marshmallow-code/apispec#245. It shouldn't be too much work, but until it is done, or to allow more flexibility, being able to pass a dictionary makes sense. We could also add a Regarding the security argument to And would it make sense to make it more generic, like adding a def __init__(self, *args, **kwargs):
self.description = kwargs.pop('description', '')
self.view_docs = kwargs.pop('view_docs', {})
[...]
def store_method_docs(method, function):
[...]
endpoint_doc[method_l].update(self.view_docs) |
Yes at first I wanted to add a decorator to add a security definition, but the APISpec code doesn't seem to allow adding that after initialization, i.e. it has to be passed to the APISpec constructor. I then also implemented a solution as you suggested (adding arguments to Api constructor), but at the end it was not so clean because the args had to be passed from functions to functions internally, so I prefered the config solution, which is somewhat similar to what you did for passing the versions. For the blueprint, I agree it could be made more generic, maybe rename |
In any case, I am completely fine with another solution as long as I got a way to define my security schemes. I need it to easily test my API directly from swaggerdoc |
Both ways have their use case. I think using an app parameter makes sense if it is really something that may be set for a specific application instance (like URL, local path, or various settings). Hardcoded parameters are for stuff that is not meant to be changed when deploying, especially if it is made of complicated python objects you wouldn't put in a config file, or if it needs a processing (for instance, parameters, responses, errors, that you'd like to parse using MarshmallowPlugin) before being passed. We can have both. Yes, I won't be able to merge, let alone release, any of this before one or two weeks. In the meantime, I think you can safely use |
OK, fine for me, I'm not in a hurry, I have mu own branch. Thanks Jérôme! |
Hi @xalioth. I just released a 0.8.0 version implementing I didn't take much time to think about |
If suppose you're using a decorator to enforce security. Can't you change it to auto-document the security scheme applied to the route? (See #36 for a similar issue.) |
Allows to specify a swagger securitySchemes in the top level API doc
Also allows to specify the security scheme for a whole Blueprint at once rather than specifying the security='xxx' for each functions