peter_w
Member
Joined 3 years ago
User Profile
User Widgets
Contributions
Don't reveal SwaggerHub APIKey in requests from SwaggerHub Integration for Confluence
Could you please consider proxying any authenticated calls from the Confluence page to the SwaggerHub API back through the domain that you presumably serve the widget content from (https://confluence-plugin.swaggerhub.com)? I'm not sure what constraints exist with the Confluence plugin model, but hopefully this would allow you to manage all sensitive state (ApiKey storage) externally in a location we already trust, and form the appropriate authenticated requests to the SwaggerHub API from there. As things stand right now, the SwaggerHub API requests are observable using browser dev tools as the Confluence page renders. These requests include the chosen SwaggerHub ApiKey in the authorization header. This is a security concern for us as we have external parties and partners who we grant visibility to areas of our Confluence tenant so they can view documentation which includes api specifications. Once the ApiKey is compromised, the holder has far more than the readonly-access to specific API specifications that we intended. There are probably other ways to address this, but the proxy approach seemed the most pragmatic to me. We've worked around this issue in the past with other Confluence swagger plugins by only using exported specifications that are attached to the page. However, you are in a good position to allow the convenient referencing of the api specifications in their natural home in SwaggerHub, while keeping the communication paths secure.364Views0likes0CommentsAllow resolution/selection of API version in SwaggerHub Integration for Confluence
Would be useful to allow just the base url to a SwaggerHub API to be specified in the widget configuration. For example: https://api.swaggerhub.com/apis/acme/products Rather than: https://api.swaggerhub.com/apis/acme/products/1.1.0 When the Confluence page is later browsed (and assuming the url is to SwaggerHub), then the default API version should be automatically resolved. This would allow the current state of the API to be reflected in Confluence without requiring new edits every time a new version is published in SwaggerHub. An extension to this would be to allow the users to choose from the different published versions when browsing the page. This should be an opt-in feature on the widget configuration.321Views1like0Comments