Thursday 10 March 2011

Anonymous Access and SharePoint

I've recently done some work creating a some public-facing websites using SharePoint 2010. Needless to say, in the scenario of a website that anyone can access we have to obviously rely on anonymous access rather than forcing every user to somehow register and log in.

As a result of this doing work and experiencing some of the pain involved, it's safe to say that there are some areas of SharePoint 2010 that don't quite deliver what you would expect - in fact, one could go so far as to use the word "flake-y" in hushed tones.

Let me set the scenario of Problem One:

In SharePoint 2007, one aspect of content management is how content should be displayed to a content author as opposed to a content viewer. On one hand, the content author may want to see everything in the same way the viewer should see it, however, this is not always true or possible. A content author may have to configure any number of additional options and choices that the viewer of a page will never have sight of so therefore, the balance between author and viewer is slightly skewed.

In light of this skewed balance, we have often implemented different views for an author of a page and a viewer. How we do this in a single page layout, fortunately, has become quite simple by using the misnamed Edit Mode Panel that comes with SharePoint. The Edit Mode Panel has a Page Display Mode property which can be set to Edit or Display and it's this very important control that helps us out and works perfectly.

Moving on to SharePoint 2010 and the same situation, we start to put the Edit Mode Panel in everywhere to help us out - CSS, Field Controls, maybe a bit of JavaScript etc. Everything looks fine until we start looking in anonymous mode. Where's everything gone?

Well looking here: http://svengillis.blogspot.com/2010/06/inconvenient-editmodepanel-control.html and here: http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.publishing.webcontrols.editmodepanel.aspx (at the comments) quickly tells us there's a problem. Oh dear.

So, moving on to the Problem Two:

One new aspect of SharePoint 2010 is the ability to use LINQ to SharePoint. You un-wrap SPMetal and generate your classes based on your site structure and libraries, and start writing your LINQ queries. Off you go creating your code without a care in the world. And then, anonymous mode again and you start getting some errors. You have a search and dig up some interesting links:

http://blog.mastykarz.nl/sharepoint-2010-linq-doesnt-support-anonymous-users/ and http://jcapka.blogspot.com/2010/05/making-linq-to-sharepoint-work-for.html

So what do you do? Go back to CAML or hack your way around the problem by storing, destroying and then reinstating the HttpContext. Oh dear.

Another one to chalk up, Problem Three:

You want to use the Client Object Model to get some list items back. Fortunately, this isn't something we've had to commercially deploy yet - although perhaps only a matter of time, but is none-the-less another anonymous-mode quirk. I wrote a blog article explaining the issue here:


http://whats-the-sharepoint.blogspot.com/2011/03/anonymous-access-using-sharepoint-2010.html and how to work around it. But once again, it's an anonymous-related issue that unless you do some digging you enter into blindly.

Oh dear, Microsoft.

Here's a more recent one, Problem Four:

Take a Content Query Web Part and use it to display items from a Picture Library or Document Library. Everything is fine. Swap into anonymous mode and suddenly the page is littered with errors and Correlation IDs. “What's going on?”, I hear you ask.

Waldek Mastykarz to the rescue again: http://blog.mastykarz.nl/inconvenient-sharepoint-2010-content-query-web-part-anonymous-access/ on the basis of a find by Paul Galvin here: http://www.mstechblogs.com/paul/sp-2010-cqwp-document-libraries-and-anonymous-users

Now, obviously, you have to add two additional fields to the Common View Fields property of the Content Query Web Part to resolve it, and they are SetDocumentIconUrlAndOnClickString and DocumentIconImageUrl, of course.


Thanks again, Microsoft, and oh dear again.

Last of all, Problem Five:

This isn't so much a problem as a question about how to work around an issue that appears to have been inherited from SharePoint 2007. As you already know there were multiple JavaScript files required in 2007, and with the added Ribbon, there are many more. In anonymous mode, the Ribbon isn't display and therefore its supporting JavaScript doesn't need to be included either. Enter the Script-on-demand framework (SOD). As Chris O'Brien points out, this doesn't resolve everything (and perhaps doesn't resolve "anything"):


http://www.sharepointnutsandbolts.com/2011/01/eliminating-large-js-files-to-optimize.html

It's a hack, an elegant one at that, and does get around the problem that is presented to us. Despite the scripts only being required "on demand" they are still loaded, even for anonymous users. So, hopefully, for the last time we utter: "oh dear, Microsoft".

In Conclusion

My advice is to watch out for anonymous access and go into it open eyed as it's an unavoidable part of public-facing websites. If you don't, you will see it as nasty and dirty and leave you with a feeling of being soiled, rueing the day you ignored my warning. Also, don't be fooled: there are five problems listed here, four of which will relate to every public-facing website we develop, however, there are more. I know of two more problems: one related to Style Library access in anonymous sites which causes the client browser to re-request resources instead of using its cache, and the second related to the Ribbon still being displayed in anonymous mode instead of being completely hidden. I wouldn't be surprised if there were more.

1 comment:

  1. Problem One I noted above some time ago appears to have been fixed in SP1 having taken a look at the code using Reflector. There's now no code in there to suggest any authentication checks, simply permission checks. Well done Microsoft.

    ReplyDelete