Comment you're replying to
Your name *
Your email *
Your comment *
Please type these numbers *
There was an error submitting your comment, sorry..
We use Microsoft Office SharePoint 2007 internally to manage all kinds of work and share documents. It’s a very effective tool. We also use it to manage our software registration database.
To facilitate customer software registrations we have a public-facing web service that uses SharePoint APIs to communicate with our registration site. The configuration of SharePoint required some fiddling to make this work. The problem was that we had SharePoint configured with no anonymous access, and obviously the users of our software that would be registering would not have credentials for our network – we didn’t really want to enable anonymous access so a creative solution was required.
In order to achieve this we used the web.config <identity /> element in our public-facing website to set the identity of the thread to a fixed user account created just for the task. The web service application pool is configured in IIS to run as “Network Service”. The SharePoint API seemed to pick up the user from the HttpContext.Current.User object, rather than from the thread which means that all our communications were failing with 401.5 errors. I was a little surprised to discover that despite the <identity userName=“user” password=“pass” impersonate=“true” /> in the web.config file, the HttpContext.Current.User was still anonymous.
The two tricks that made it work were:
The Global.asax trick ensures that the context carries the same user account as the impersonated thread.
The AllowUnsafeUpdates is required when impersonating.