pfoppe

How useful is 'Disabling the service directory' option?!

Discussion created by pfoppe on Aug 27, 2013
Latest reply on Sep 3, 2013 by ciava.at
Disabling the service directory  seems to only block access with the HTML return type.  Any savey GIS user who knows to access the root with f=json (or f=pjson) can still index the entire site including all folders and services.  Same with any web-crawlers/spiders that automatically index the site. 

I guess my interpretion of this would have been like disabling directory browsing with web-servers, but this only disables HTML browsing.  Is this the intent?  And if so how useful is that?

Our goal:
Publish a service but do not make it browsable.  Once someone 'higher up' reviews the service and approves it then make the service accessible in our simple interactive Javascript/HTML based web-application.  If the user uses a fiddler tool (or browser debugging tools) to reverse engineer the links we dont really care once it had been approved.  Using the 'disable the service directory' option above does not really meet these requirements because I'm sure spiders/bots/crawlers could still index it and savey GIS users could still list all contents with the f=pjson and/or f=json return format types. 

Only way I see us meeting the goal above is to either:

  1. Enable security.  Grant specific roles access and add the 'reviewers' to the roles.  Disable the security once the service is 'approved'

  2. Build a second arcgis site on our internal network with no security enabled (not worried about internal staff accessing the services).  Allow reviewers to review the content an once its approved 'push' it out to external/mirror site. 

  3. Use a Web-Application Firewall (WAF) type device to restrict the non-approved content. 


All 3 options above have somewhat significant downsides (either managing users/roles and enabling HTTPS, building a completly seperate environment, or managing rules on the network WAF).  It would seem that something which truly disabled browsing access to the services (either over HTML or JSON return types) would meet these needs and the risk of someone 'stumbling' onto a link would be quite low. 

Any advise/Feedback?  Thanks!

Outcomes