What About Anonymous Writes to SharePoint Lists with Web Services? – Follow Up
In my post What About Anonymous Writes to SharePoint Lists with Web Services? the other day, I wondered why the SharePoint Web Services don’t allow anonymous updates to SharePoint lists through the Web Services, even when anonymous write access is enabled on those lists.
Since then, I’ve gotten two independent answers that tell me that it just isn’t possible.
From a well-respected SharePoint MVP (I won’t name him because I didn’t ask him if I could):
The anonymous settings in Site Settings / Central Admin will only update the content virtual directory in IIS. Web services live in the _vti_bin folder, which is not updated from those settings pages.
I would recommend writing a custom web service that accepts anonymous input, performs data validation, value scrubbing, logging (IP address, date-time, etc.) and most importantly watches for multiple updates from the same source to prevent denial of service attacks.
And in a blog post that my pal Ben McInerney found: 401 Reasons Why SharePoint Web Services Don’t Work Anonymously (From someone named Chris Domino? Chris, you need an About page!):
But when anonymous is set, we get that one line message: “401 UNAUTHORIZED.” Obviously, this is not coming from IIS. My only guess, after going through the trouble of Reflecting what I could of Microsoft.SharePoint.dll, is that code inside the web method sends this response if the current user is not authenticated, regardless if it’s virtual directory is set to be anonymous.
Regardless whether allowing this type of access is a good idea, it just doesn’t make sense to me. If you are running a serious corporate site that gets thousands of hits a day, then the Denial of Service (DoS) issue is a very real one. If you’re using WSS for your kid’s soccer team or for a small business, then this concern just isn’t on your radar screen.
I’m disappointed in these findings, and would love to hear that I’m wrong in my conclusions. Luckily, I’ve at least been able to get anonymous reads working with the Web Services in my jQuery Library for SharePoint Web Services (SPServices). That’s a huge set of capabilities right there, but I really wish that the writes worked, too.
So what you are saying is —
– You can read/update content anonymously using a web browser.
– You can only read content anonymously using web services.
I wonder if they addressed this in SP2010.
Yes, you are summarizing correctly if what I am hearing is correct.
Good question about SP2010. I wish that I had some sort of channel into Microsoft to get definitive answers to this sort of thing.
M.
@Marc and Ben: thanks for the follow up and regular updates on this key topic.
@Brian: this is a question I asked to Jan Tielens in his January EMEA webinar, and the answer was that from the client side (JavaScript/jQuery) neither Web Services nor the Client Object Model work with anonymous access.
Marc, I am still careful about using Web services anonymously, even if your tests show that it works. As long as it is not confirmed by Microsoft, this may fall in the “hack” category and be wiped out by a version update.
Christophe:
Unfortunately, I don’t have anyone at Microsoft who I can turn to to discuss things like this. The guys I contacted through Twitter (hardly a reliable mechanism, of course, but all I have) didn’t reply. Do you have any contacts I can use for this? I’d rather have Microsoft’s blessing, or at least acknowlegement that this is probably an OK approach.
In actual fact, it’s hard to say what Microsoft, in a larger sense, would think about my library.
M.
Thanks for the clarification. I am using the Excel Rest API to render Excel sheets for mobile devices. Works well, but when you add parameters to the query SharePoint thinks it is a write access and you get back a 403.
Once again, SharePoint wasted my time and at the end it just doesn’t work.