-
Notifications
You must be signed in to change notification settings - Fork 9k
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
Divide API in public and private #4326
Comments
If you're looking to hide some of the operations, providing it all in one API definition is probably not the way. Even if it's not rendered, users could still get the API definition itself and see the hidden API calls. |
Versioning is the way to go, and your swagger-ui will look like: |
As an alternative to the above: the OpenAPI Specification describes a |
Versioning might be an option. I'm using https://github.com/Surnet/swagger-jsdoc to define my swagger definition as comments in the code. So maybe I can use versioning, but I think I may end up splitting it. |
Right now I'm trying to write a wrapper component plugin, but I'm stuck a little bit. Any ideas? |
@heldersepu working on a project where we'll need to display different docs for different API versions. I saw you have something that might fit the bill of what I'm looking for with the example you posted. Do you have a reference or something I could look at to try and accomplish something similar? |
The code for my example is here: |
@heldersepu awesome! Thanks! |
Would you want the operation block to show when any authorization data is set, or do you have an endpoint on your server that you'd like to ping before revealing the documentation? Also note that this can't be truly secure at the Swagger-UI level, since the user's browser will already have the entire documentation file loaded over the network. |
Hey @shockey Thanks for the answer.
This would be ideal. It doesn't matter, if the Security wise, it does not matter. We just want to give away a documentation of operations where we can say, that those are safe to use. They can still go into their devtools of choice and sniff for endpoints and reveal them. Thanks in advance already for any solution or workaround. Right now - CSS does the job but it is done manually. |
@MartinMuzatko, here's a plugin that should achieve what you're looking for: const HideOperationsUntilAuthorized = function() {
return {
wrapComponents: {
operation: (Ori, system) => (props) => {
const isOperationSecured = !!props.operation.get("security").size
const isOperationAuthorized = props.operation.get("isAuthorized")
if(!isOperationSecured || isOperationAuthorized) {
return system.React.createElement(Ori, props)
}
return null
}
}
}
} Let me know if this helps (or not!) 😄 |
@shockey first of all: thank you a lot for your effort. I very much appreciate it. This is how the page looks without the script: With the script you suggested, the operation blocks are hidden (but not the section that marks the tag) I still get This is my definition: securityDefinitions: {
basicAuth: {
type: 'basic'
}
} This is my endpoint: /**
* @swagger
* /Server:
* get:
* tags:
* - server
* description: Returns the Server configuration
* produces:
* - application/json
* responses:
* 200:
* description: 'OK'
* security:
* - basicAuth
*/ I think I will just go with the CSS option (that also hides the tag) and document our internal API using unit tests. |
Hey @MartinMuzatko, here's a video of the plugin in action on my end: http://recordit.co/WY6tsdIJnN I think the security requirement in your operation is malformed; it should be |
Oh cool. I have to try that out. Thank you :) |
Closing due to inactivity. This is simply to keep our issue tracker clean - feel free to comment if there are any further thoughts or concerns, and we'll be happy to reopen this issue. |
Locking due to inactivity. This is done to avoid resurrecting old issues and bumping long threads with new, possibly unrelated content. If you think you're experiencing something similar to what you've found here: please open a new issue, follow the template, and reference this issue in your report. Thanks! |
Hello.
We try to divide our swagger documentation in two parts. One for our internal documentation and one for consumers.
What is the best way to go about this? We thought about providing two definitions, but maybe there is a YAML flag or whatever to do this. What also works, is that the relevant sections are hidden, before authentication.
Thanks in advance.
The text was updated successfully, but these errors were encountered: