How effective is locking down _vti_bin

Question

I've come across a roadblock where the maintainer of the Sharepoint installation has restricted access to the _vti_bin folder (i.e. denied for all users). I am using SPservices to access the GetListItems method to access content from a list to display on a page.

How effective is this method of lock down and is there a way to provide read-only access? I have requested that they provide a custom webservice that acts like this method, but I am sensing that they just don't want to make that move. Are there any alternatives?

Answer 1

There is no such thing as read vs. write access when securing a URL to a web service - You can reference the Web Service URL or you can't. The services themselves are implemented to enforce security just as if you were logged into the site through the browser.

Without access to _vti_bin you are pretty much out of luck for any of the SharePoint Web Service technologies including the Lists.asmx server, the ListData.svc or the Client OM model through the Client.svc - they all reside in the _vti_bin folder.

The alternatives are:

• Write a custom web service and deploy to the _layouts folder. They can't lock out the _layouts folder, but from a security perspective if they allow this, than they should really allow _vti_bin - they work under the same premise.

• Customize the site page to render server-side data into hidden data islands in the page that you can then manipulate from client-side code. Depending on the amount of data this will certainly increase the page size and load time, but can work in some situations for improving user experience if the overall dataset is fairly small. It also had the advantage of making all the data search engine crawl able.

• Abandon using client-side code and post-back the page for every data refresh :(

Answer 2

All I have to say is: It's crazy what some people will do. There are some unintended implications of locking down _vti_bin, such as SharePoint Designer just plain not working anymore. The errors won't make any sense, either. There are also some places where SharePoint internally uses the Web Services, and many managed code developers do as well.

This is a baby with the bathwater situation. Unless they have a clearly articulated reason for doing what they have done, it's been done in fear of the unknown. As Chris mentions, the Web Services respect credentials just like accessing SharePoint through the UI.