How to remove Authorize and Try it Out buttons

[northk]

Greetings Swagger UI team,

Is there a way to tell Swagger UI not to render the Authorize and Try it Out buttons, during construction of the SwaggerUIBundle object? I've tried to simply remove the buttons using CSS display:none but I'm integrating with Drupal and I can't get my custom CSS to apply after all the other CSS. I've also tried removing those buttons using Javascript but it's tricky since I have to wait until the Swagger UI instance finishes rendering and for the buttons to exist before I can find them in the DOM and delete them.

Both of these options (css and js) seem like a lot of workaround code when it would be best if I could just tell the SwaggerUIBundle object (through an option) not to render those buttons in the first place. We are giving our users the option to display Try it Out and Authorize buttons, or not.

Thanks

[webron]

We don't have support yet for the supportedSubmitMethods flag in the 3.X version, so there's no easy way to hide these things.

[northk]

Thanks for the quick response. This is a feature I'd like to see added. Thanks for your consideration.

[webron]

It would depend a lot on user contributions. We don't have the capacity to implement everything right now, but we do our best to review PRs as they come in.

[scottohara]

Hey @shockey, I'd like to have a go at a PR for disabling the Try It Out feature via a config option.

But before I start, I'd appreciate your thoughts on if/how you'd prefer this to be implemented.

Option 1: Simple config toggle

Display

Parameter Name	Description
tryItOut	Boolean=true. If set to false, disables the Try it out feature in the operations list. The default is true.

In OperationContainer.jsx, extract the config value and use it to set the existing allowTryItOut prop:

mapStateToProps(nextState, props) {
    ...
    const { docExpansion, deepLinking, displayOperationId, displayRequestDuration, tryItOut } = getConfigs()
    ...
    const allowTryItOut = tryItOut && (typeof props.allowTryItOut === "undefined" ?
          props.specSelectors.allowTryItOutFor(props.path, props.method) : props.allowTryItOut)
}

This would seem to be a trivial change, but I'm not sure whether you had something bigger in mind with the (currently unused) specSelectors.allowTryItOutFor() hook?

Option 2: Reinstate supportedSubmitMethods from 2.x

Network

Parameter Name	Description
supportedSubmitMethods	Array=["get", "put", "post", "delete", "options", "head", "patch", "trace"]. List of HTTP methods that have the Try it out feature enabled. An empty array disables Try it out for all operations. This does not filter the operations from the display.

In OperationContainer.jsx, extract the config value and use it to set the existing allowTryItOut prop:

mapStateToProps(nextState, props) {
    ...
    const { docExpansion, deepLinking, displayOperationId, displayRequestDuration, supportedSubmitMethods } = getConfigs()
    ...
    const allowTryItOut = supportedSubmitMethods.indexOf(props.method) > 0 && (typeof props.allowTryItOut === "undefined" ?
          props.specSelectors.allowTryItOutFor(props.path, props.method) : props.allowTryItOut)
}

This has the advantage of maintaining a consistent interface between 2.x and 3.x.

Or something different entirely?

[shockey]

Hi everyone! Please note that the "disable try-it-out" question has been answered before, you can define a custom plugin to achieve this. See #3725.

You can also create a plugin that disables the Authorize button:

const DisableAuthorizePlugin = function() {
  return {
    wrapComponents: {
      AuthorizeBtn: () => () => null
    }
  }
}

Alternatively, you can just avoid having any security definitions in your definition, and the Authorize button won't show up.

---

@scottohara, I'd love to see this supported through a config parameter. I'm (slightly) in favor of option #2, since it reimplements something we had in 2.x 😄

[nzain]

@shockey could you elaborate what "security definitions" trigger the authorize button? When you create a new Asp.Net WebApi project, enable swagger through the Swashbuckle.AspNetCore nuget package, the Authorize button shows up and, when clicked, presents an empty list. No security definitions specified at all.

[jmendiara]

@shockey
I got your DisableAuthorizePlugin working with this code (note the casing)

Using swagger-ui-dist@3.13.2

const DisableAuthorizePlugin = function() {
  return {
    wrapComponents: {
      authorizeBtn: () => () => null
    }
  };
};

[shockey]

@nzain, the Authorize button renders when any security definitions exist. If your security definitions are invalid (most likely an incorrect or missing type value), then you won't see anything in the Authorizations modal.

Try loading your JSON/YAML document into Swagger-Editor, to make sure your document is valid 😄

---

@jmendiara thanks! case sensitivity strikes again!

[nzain]

Did that, it is valid. It was a bug in the Asp.Net layer and has been fixed already. kyle <notifications@github.com> schrieb am Di., 3. Apr. 2018, 18:33:

…

@nzain <https://github.com/nzain>, the Authorize button renders when any security definitions exist. If your security definitions are invalid (most likely an incorrect or missing type value), then you won't see anything in the Authorizations modal. Try loading your JSON/YAML document into Swagger-Editor, to make sure your document is valid 😄 ------------------------------ @jmendiara <https://github.com/jmendiara> thanks! case sensitivity strikes again! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3314 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ANUK-6aZ1UjSgM8zGsjJKiXCEyrckihCks5tk6RIgaJpZM4OIgRq> .

[Mokaffe]

Hi everyone! Please note that the "disable try-it-out" question has been answered before, you can define a custom plugin to achieve this. See #3725.

You can also create a plugin that disables the Authorize button:

const DisableAuthorizePlugin = function() {
  return {
    wrapComponents: {
      AuthorizeBtn: () => () => null
    }
  }
}

Alternatively, you can just avoid having any security definitions in your definition, and the Authorize button won't show up.

@scottohara, I'd love to see this supported through a config parameter. I'm (slightly) in favor of option #2, since it reimplements something we had in 2.x 😄

"AuthorizeBtn" should be "authorizeBtn".