Disable REST Services Directory through Web Adaptor

[Anonymous User]

When the Web Adaptor is currently installed there is an option to disable or enable the Server Manager. However, there is no option to disable the REST Services Directory on the internet. To hide published service URLs on the internet, all services must be secured through ArcGIS Server Manager or the entire Services Directory must be disabled (both intranet and internet). I would love to see an option to disable it in the Web Adaptor like the Server Manager, but continue to be able to access it through port 6080.

[PF1]

I could also see a big benefit when orginzations use 1 'site' for but public and private content.  1 web-adatpor in the public space can disable service discovery, and thus mitigate many cross-site scripting attacks (for the 6 billion people that can try to hack at it), while the internal web-adaptor has discovery enabled since its locked down to only authenticated users on the internal network.  

[ThomasEdghill]

For those who are reading this and may not be aware, disabling the services directory is possible, though it must be done through the ArcGIS Server Administrator Directory and not through the Web Adaptor.

Disable the Services Directory

Once the services directory is disabled in this way, it is disabled across the site, regardless of whether a Web Adaptor is used or not. This idea is asking for the ability to disable the service directory at the Web Adaptor level while still allowing access when using the internal ports of 6080/6443. If you have any additional use cases for how such a workflow would be beneficial, please continue to leave them in the comments below.

[TonyContreras_Frisco_TX]

Our GIS department would also benefit from this feature. I would like to remove access to the services directory for external users (using our DMZ Web Adaptor), but keep this access for internal use, specifically for a web adaptor we have installed on a server within the firewall. This can help make troubleshooting services much easier by providing a usable interface for interacting with services, sending sample requests and so on. Our developers could also benefit when working with our services for the same reasons. I came here to create an idea for this and was glad to see it already exists but disappointed that 8 years later it has not been implemented.