On an internet facing SharePoint sites where anonymous access is enabled something that many implementations face is unintended anonymous user access to kitchen, that is, ability for anonymous users to peek into All Site Content that resides in various lists and document libraries. This include ability not just to see the data content but also the metadata, that is user names associated with it, date/time when created/modifies and so on. This includes content that is you have not published yet. This is like browse directory access to a web site where you can see the web virtual directory content or ability to view all content in a ftp site. Restricted users like anonymous users cannot cause any harm but the ability to view is undesired. Using the analogy of a restaurant, guests are welcome in the guest area (dining hall) you may have a galls window to show the best part of the kitchen but they are not welcomed to roam around in the kitchen.
How do you restrict that access? Simple, there is a hidden feature that you can activate at Site Collection level that will lock them out from the areas where they not need to be.
Activate (enable) that feature like this:
stsadm -o activatefeature -url http://www.agileconcepts.com -filename ViewFormPagesLockDown\feature.xml
Deactivate (disable) that feature like this:
stsadm -o deactivatefeature -url http://www.agileconcepts.com -filename ViewFormPagesLockDown\feature.xml
Once Activate/Deactivate you will need to go and toggle Anonymous Access off and on for change to take effect
Now there are couple of things that you need to know and think through the implications:
1. It’s a Site Collection level feature and applies to all sub-sites in the given Site Collection.
2. It’s a publishing feature. However, it does not mean that it is applicable to only publishing sites. It is effective on any site template (I have not tested all but few).
3. It’s only available on MOSS implementations. You won’t find it on Windows SharePoint Services Only implementation.
4. It’s all inclusive: it takes away the permissions from all collections like sub sites, lists and libraries, means, you cannot grant anonymous write access to any list or library.
Let’s examine the implication of fourth list item above. What this feature does is enable\disable couple of permissions (1) View Application Pages permission, and (2) Use Remote Interfaces permission. The View Application Pages is the one that allows our anonymous users to access the Forms pages. After enabling the lockdown feature, they no longer have that right. There is an excellent posting at: http://blogs.msdn.com/ecm/archive/2007/05/12/anonymous-users-forms-pages-and-the-lockdown-feature.aspx
What it does (among other things), it restricts anonymous user access to list support pages in /forms/ folder. For example, http://www.example.com/Pages/forms/AllItems.aspx
http://www.agileconcepts.com/Blogs/AQ/Lists/Posts/Post.aspx?ID=9
http://www.agileconcepts.com/KB/_layouts/viewlsts.aspx
http://www.agileconcepts.com/Products/PE/Lists/Tasks/DispForm.aspx?ID=1
http://www.agileconcepts.com/Products/PE/Lists/Tasks/DispForm.aspx?ID=1
All Document Libraries have their application support pages within the document library under /forms/ folder (that includes doc library views like AllItems.aspx pages and metadata view/edit pages like DispForm.aspx and EditForm.aspx). Lists have their own supporting pages in the root of the list like <site>/Lists/[List Name]/[ Display Item Form | Edit Item Form | New Item Form |List Items Views].aspx. Once lockdown feature is enabled these are all off limits for the site collection (entire web tree – root web, webs and sub-webs) no exception and irrespective of zones.
What if you have a blog site where you want anonymous users to comment on postings or you have an online survey that you want to use to solicit some input? With Lockdown feature enabled you lose your ability to allow anonymous users to give feedback in scenarios like blog comments or surveys.
One thing is certain about tomorrow, something is going to change. You might be thinking that’s fine and it will work for me but think about when it may come back and box you:
Lock down feature will not impact the sites where inheritance was broken before activating the feature. Once you re-inherit and break it again lockdown behavior will pass through to that branch of the tree.
Example One: Before activating the feature, you created a blog site and break its permission inheritance. You modified the comments list to allow anonymous users to add list items so they can post comments. You then activated the feature to lockdown the site. Your blog site is protected from this lockdown behavior as you stopped the inheritance before you activated the feature. Later something got messed up on the blog site and you have to re-inherit the permissions or you have to restore a blog site or a list (like posts) on the blog site. Once you re-inherit the permissions lock down effect will penetrate in it.
Example Two: You might have to create another blog site (a sibling site or somewhere else in the collection) now you have to deactivate the lockdown feature (at site collection level) break the inheritance and reactivate it. What might be the implication of this SC level activation/deactivation on other objects on the site? I don’t know and the answer will depend upon the size of the site, customizations that you have and the level of change control and rollbacks you have.
Is it good thing or a bad thing? It depends on what you want to achieve. If it’s a pure publishing site you are fine. If you want to solicit user input through custom form logic you are fine. Your site is either pure publishing, or you are among those who favor custom codes over what you can use out of the box.
What if your deployment has a mix of requirements like publishing, collaboration, blogs and so on? You are among those who want to maximize the return of your investment in SharePoint by using core features some customizations and some configurations. After all that was the reason at the first place you chose to use SharePoint as your Web Application Platform.
Now take the example of a blog that you want to host on your public facing site, or you are a large corporation and allows anonymous access to you intranet for people who are on your network. With this feature enabled
· People cannot view your blogs (blogs use Display Form which is application page)
· People cannot comment on your blog (as you cannot grant anonymous user that right).
· If you have blogs you may want them to be discovered and crawled by search engines or able to provide RSS feeds (feed will work but when user will click on the feed item they will land on the page that is not available to anonymous user L)
How do you work around it?
(a) You can wait for MOSS v.Next and hope there will a more elegant solution.
(b) Use some community work like CKS from CodePlex and have smart developers who can understand it and tweak it to your needs.
(c) Buy some COTS solution – reasonable approach where cost is spread across volume
(d) Build your own solution - Have a good business case and funding to build it and maintain it.
(e) Work with your implementation’s Information Architect for a slightly modified approach.
(f) Use some configuration tweaks that can give you most if not everything.
Before you embark upon building your own custom solution, read a post written by Marwan Tarek (MVP SharePoint) at http://www.sharepointblogs.com/marwantarek/archive/2008/09/09/relation-between-viewformpageslockdown-feature-layoutspagebase-and-unsecuredlayoutspagebase.aspx
For item (e) track above, one reasonable solution is to carve out all your blogs to a separate Site Collection dedicated to blogging and do not activate the lockdown feature to this site collection. It may be a better approach if you are expecting a lot of blogs or similar things to live in their own container (Site Collection). One implication may be, more applicable to a project that was based upon a single or very few site collections is that, now you have another site collection to brand, secure, and operate. This may be a doable solution to carve out (re-factor) all blog sites to separate Site Collection. Use the same strategy for any content where you might need anonymous users to have the ability to add or edit.
For item (f) track above, let’s see what we can do. A use case might be.
· You want your site accessible to anonymous users.
· You want anonymous users to be able to read the blogs and be able to comment or rate them as well.
· You want your site blogs etc be discoverable by search engines as well.
· You want to control anonymous access differently from zone to zone (Internet facing anonymous sites vs anonymous but little more relaxed intranet sites)
Here the solution is simple and is in the core ASP.NET platform that SharePoint respects and supports it.
In the web.config file for the zone where you want to restrict the access to View All Site Content Page set the restrictions who can and cannot access the url string pattern. In your Web Applications Web.Config create a block like the following block where other blocks of type <location path= are
<location path="_layouts/viewlsts.aspx">
<system.web>
<authorization>
<deny users="?" />
</authorization>
</system.web>
</location>
In the example above, <deny users="?" /> is denying access to all unknown users (anonymous users) to viewlsts.aspx page in /_layouts/ application folder. They will have access once they are known (logged on, authenticated, and registered users in case of FBA). Or you can deny it to all users (no exception) by <deny users="*"/> or using <allow roles=""/> to allow by specific roles (ASP.NET Role Provider).
I chose to deny access to everyone (includes anonymous and known logged on users), as if I have registered users who logon, I still do not want them to see all internal un-branded pages, content (data) and meta data.
What path or filename can you specify? For path you can have other paths as well (implemented in their own location blocks or you can use regular expressions to match all paths to be evaluated to match the regular expression.