Disable 'Try it out' button

[peter004]

How can I just disable 'Try it out' button for specific POST method?

Thanks in advance

[fehguy]

Hi, currently this isn't supported, but you should be able to modify the json before calling swaggerUi.load();

[vasiliysablin]

Disabling 'Try it out' button would be very useful in some situations.

[fehguy]

@woodoo wouldn't a static version of the documentation be a better solution when you don't want people trying it out? See here

[Xyand]

A hack would be to use a CSS selector setting display: none;

[jchannon]

I think this would be a good feature.

[matiwinnetou]

+1

[lluu]

agreed. There are cases where one can't really Try the API w/o making other call(s), or it's too much work for the service provider to setup dummy data for the TryIt function to work. Most 'Delete' operations fall into this bucket. It is still useful for the end user to see the operation (e.g. Delete) in the same locations as the other operations.

[defaultbob]

+1 it's important for us to be able to disable this in production, whereas it's useful in dev and qa for testing.

[webron]

I see a problem with implementing this, but let's open this for a discussion. Perhaps together we can come up with a possible solution.

The problem I'm seeing here is that the Swagger specification is meant for API documentation, and Swagger-UI utilizes that documentation in order to display and execute the available API documentation.

Disabling the Try it out button is a functionality issue and not a documentation issue, so adding meta data on this in the Swagger documentation seems wrong. However, since most of you are not talking about all-or-nothing but want to disable specific operations, I'm not sure how those can be decided. We could possibly offer some kind of a generic way to define which operations should not be enabled for testing, but that would lead to a maintenance issue as it won't depend on the swagger specification served by the server exposing the API.

In Swagger 2.0 we could use the vendor extensions for this, but I'm reluctant to do so as it breaks the barrier between documentation and specific tool functionality. If we allow support for say x-swagger-ui-disable-execution: true, soon enough people would request the community libraries to support it inherently and it becomes de-facto part of the spec and not really a 'vendor extension'. This ends up blurring the boundary between documentation and functionality, which I don't like.

[rage-shadowman]

@lluu "...too much work for the service provider to setup dummy data..."

This is a documentation and debug/testing tool. It is not the serice provider's job to setup dummy data. The developers should know (because the documentation tells them) that they cannot delete something that does not exist, so they first must PUT/POST to create the resource, then they can and should be able to DELETE it.

I don't see the issue here. Why do you want to disable things in only some cases? As long as it is documented well and the preconditions and error cases are documented, why not allow your developers to "Try it out"? What am I missing?

[matiwinnetou]

Depending on organisations sometimes swagger endpoints are exposes in production for all users of a particular organisation but still internal in those orgs. In many cases we want to restrict that those users simply cannot invoke any state modifying methods. Swagger-ui is also easier to use instead of a static doc generation tool, therefore sometimes the only usecase you want to serve by using this single page webapp is - documentation, nothing less nothing more.

[rage-shadowman]

@matiwinnetou Turning the button off completely can make sense to me. It's the partially-turned-off part that confuses me.

If the RESTful endpoint is accessible, then the user could just as easily run a curl script to execute that function. The user doesn't need the "Try it out" button to do it. If the endpoint really is internal, then it should be secured and the "Try it out" button should result in a 401 or 403 error if they don't have the required priveleges.

Otherwise it is even more broken than "security through obscurity" (since you aren't really obscuring anything and they now know exactly how to execute this function with curl).

[matiwinnetou]

@rage-shadowman You are totally right and we discussed this use case, it is not that we are afraid of malicious users so much, rather somebody when it is too easy will be overusing this functionality. It is just we think - it will be way too easy for users to access try it out feature, it also doesn't make sense to me to have try it out exposed when we know this is something that doesn't work, hence would be nice to disable this with one property on swaggerUi javascript object. Sometimes a service may require authentication for state modifying methods and try it out would simply be failing all the time, which makes no sense. In some cases all methods would require auth but it does not change the fact that swagger docs (api-docs) could be exposed rather than secured as well. After all this is only information about service. Unfortunately I don't know very well Swagger-UI internally, is this a difficult feature to implement?

[webron]

@matiwinnetou - but how would you define which operations need to be disabled? "state modifying methods" is not good enough, as we can't really know which ones are state modifying. You can say that non-GET operations are state-modifying, but that's not necessarily true. I've seen people use POST for complex search queries (not saying I like it, saying it is done), and those are definitely not state modifying ops. We could allow for blocking it for specific HTTP methods and just say that it may be useful to some users, but I'm not sure that's the right way to go.

[matiwinnetou]

@webron I would be fine to have a switch disable any method invocations, both non state modifying and state modifying at least for my requirements. I cannot speak for others (think static or read only mode).

[webron]

You mean all method invocations?

[rage-shadowman]

@webron If there is still a verb-based disabler in v2.0 (GET/PUT/POST/DELETE) that might solve hist issue.

[webron]

@rage-shadowman, I'm not even aware of one prior to v2.0 (doesn't mean there isn't one). I suggested it may be possible to implement it, but I'm not sure it's the right approach.

[rage-shadowman]

@webron In the version I'm still using (swagger-ui v2.0.3, based on older spec) there is a "supportedSubmitMethods" property for SwaggerUI that takes an array of verbs "['get', 'post', 'put', 'delete']".

[webron]

I don't see a reason it should be dropped, though as part of the migration some thing may accidentally get lost. If they do, just open an ticket :)

[matiwinnetou]

@webron Yes I mean to disable all method invocations via a property. I see that PetStore example has this: supportedSubmitMethods, is this something that appeared recently? What is the semantics of this property?

[webron]

@matiwinnetou - I'm not entirely sure and @fehguy or more advanced users could comment on it. However, keep in mind this is not what the OP was talking about and not what others were talking about on this topic. The general request is to disable the button for specific operations, not globally.

[matiwinnetou]

@webron I see, I could open a new issue if necessary. I am also wondering what others would say about a property to disable it completely. Any comments?

[rage-shadowman]

@matiwinnetou The "supportedSubmitMethods" property has been around for a while now. It is just an array of verbs. If you only want to support GET, then you would use supportedSubmitMethods: ['get']. Other valie values might be 'put', 'post', 'delete', 'head', 'options', etc.

I haven't tested 'head' or 'options' or anything other than the standard 4, but they might work.

[lluu]

@rage-shadowman "Why do you want to disable things in only some cases? As long as it is documented well and the preconditions and error cases are documented, why not allow your developers to "Try it out"? What am I missing?" Good point. The issue is in some cases, it's more than just a put/post prior to a delete.. delete is just one example. The operation might require a series of calls prior, and so even with adequate documentation (and in most cases there isn't :(), the developers can't really 'try' w/o minimal effort. Having the 'TryIt' button in this case causes more support calls then helping.

[lluu]

A property to disable a HTTP method completely is to broad, won't work for us.

[rage-shadowman]

@lluu Then from a clients perspective, it sounds like you need to document the flow better. If it is well documented then they will know why it doesn't work. If they don't, then leaving the button un-clickable is unlikely to clear it up any for them and they will still need to call you up. That being said, while I disagree, your opinion is still valid and if you want to disable per resource call then I probably can't convince you otherwise.

@webron Do you think a simple "disabled" attribute would work, greying out the button and maybe the entire resource? Or enabled="false" (defaults to "true")?

[webron]

@lluu - As mentioned above, I'm open for suggestions on how to solve this as at the moment I can't find an elegant solution.

@rage-shadowman - regarding the comment you've made to @lluu, I have to say the sometimes you can document from here to eternity and people would still click a button if they see it. In an ideal world, we wouldn't need such mechanism, but... As doe the "disabled" attribute, this is exactly the solution I want to avoid as it describes functionality specific to swagger-ui and in no way does it reflect on the API documentation.

[rage-shadowman]

@webron I would consider the "disabled" attribute to mean that the function is disabled at the moment. Possibly due to not being implemented, being broken and known not to work, deprecated/disabled and only left here for historical reasons to point you to the correct resource, or whatever else. Similar to how the javadoc/jsdoc @deprecated tag works, it could provide a descriptive reason why it is disabled. If @lluu chooses to use the disabled attribute as a hack to disable the "Try it out" button even though the endpoint is itself still enabled, that's his choice.

[webron]

The deprecated property exists, but that's not what they're looking for. The operation is not deprecated nor disabled. It exists and works and expected to be used, just not by the UI.

[rage-shadowman]

Yes, but deprecated resources are eventually removed. Maybe you want to leave it in the documentation because it points you toward the new endpoint even though it just throws UnsupportedOperationException whenever you run it, hence marking it as disabled.

@webron However, I admit this is stretching it a bit. I can't imagine using the feature myself. But I'm trying to play devil's advocate here.

[webron]

I don't disagree, it just isn't related to the problem at hand.

[tokra]

Is "Try it out" removing possible ?

[webron]

For removing it overall, just take the button out of the code.

[tokra]

Where exactly? thx

[fehguy]

I believe there is a readOnly : true setting that you can pass when initializing swagger ui

[tokra]

I put it here, in my index.jsp :

window.swaggerUi = new SwaggerUi({
        url: url,
        readOnly : true,
        validatorUrl: null,
.
.

And it does not work. :(

[nikhiljindal]

Would like to throw in my +1 for a SwaggerUi parameter to remove the "Try it now" button everywhere.

Doesnt look like there is a readOnly Param: https://github.com/swagger-api/swagger-ui#parameters

[sberardelli]

+1 for being able to disable it as needed. Not an all or nothing. Scenario is in a production environment, I want to allow consumers to perform a GET, see what results, formats, etc are returned. I do NOT want them to do a PUT, POST, DELETE, etc. I DO want that ability in a dev, qa, or some other lower environment....

[webron]

@sberardelli - as mentioned above, you have the supportedSubmitMethods property that lets you decide which operations are executable. You can look at the http://petstore.swagger.io for example.

[cnaut]

The supportedSubmitMethods property seems to just grey out certain areas. Is there a property for completely removing the functionality?

[tejasdewan]

Hi,

I am using io.swagger.

In the swagger-ui.js, you can replace "21":function(depth0,helpers,partials,data) { var method = depth0.method; if ( method == "post" ) {return "

\n \n Hide Response\n \n

\n"; } return "

\n \n Hide Response\n \n

\n"; }

to disable the "Try it out!" for the POST request. Likewise it can be used for other httpMethods("delete", etc.) as well.

[fehguy]

per @webron, set the supportedSubmitMethods values https://github.com/swagger-api/swagger-ui#parameters

[FerrariAlberto]

where do i set the supportedSubmitMethods?

[webron]

@FerrariAlberto it's not supported in the current version.

[nickeeromo]

Just also wanted to voice that an easy way to simply get rid of the button for some http requests would be nice. Perhaps an annotation could work well?

[rbjorklin]

If you use Openapi 3.0.0 it seems to default to all methods disabled. Anyone know how to enable them? Found a converter 2.0 -> 3.0.0 here: https://github.com/mermade/swagger2openapi

[webron]

See: https://github.com/swagger-api/swagger-ui/releases/tag/v3.1.0 https://github.com/swagger-api/swagger-ui/issues/3338

[matthhong]

I just put this in the onComplete callback:

         onComplete: function(swaggerApi, swaggerUi){
                    ...

                    $('.sandbox_header').each(function(i,e) {
                               $(e).hide();
                    })
         }