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?

  • 2
    what is the root of this decision ? Sharepoint is supposed to use its permissions model to restrict access... what is the problem with accessing _vti_bin ?
    – Steve B
    Jul 1, 2011 at 15:46
  • I don't know for sure as it is the client's internal team that made the decision. I think they are aiming to restric access to anonymous users by completely cutting off remote services. Jul 1, 2011 at 16:29
  • is this a public internet-facing site or an intranet site? Do they only have one URL for the Web Application or do authenticated and anonymous users go to different Urls?
    – Dave Wise
    Jul 1, 2011 at 17:35
  • It's not an intranet site, it is public facing, with a mixture of anonymous and restricted sites. The main root site allows anonymous access. Both anonymous and authenticated users go to the same URLs (federated login). Jul 2, 2011 at 17:54

2 Answers 2


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 :(

  • Thanks for the alternatives. I am not able to submit server-side code at all, so writing a custom web service is not in my ability. However, it is something I can request of them to do, but I would need to know a ballpark LOE. To me, it seems like a straightforward procedure, but is it? Jul 2, 2011 at 17:56
  • Is this 2007 or 2010? Do they support Sandbox solutions? Jul 3, 2011 at 4:13

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.