在sharepoint 中运用匿名访问相信很多人都会，网上也有非常多的操作截屏，这个操作还是比较简单的，下面我们来分析一下他的功能，局限性，以及结合一个例子讲述一下如何运用。
首先，匿名访问分为三个级别，分别为 无，列表和库，整个网站
无 级别这里不做讨论，和没有开匿名一样。
整个网站 级别也没有什么太多讨论的，就是整个网站的所有列表匿名用户为可读权限。
列表和库级别：
当你初次选定该级别的时候你会发现，他们有任何效果。官方的说明为“如果选择“列表和库”，则匿名用户仅能查看并更改对匿名用户启用权限的列表和库中的项目” 。我们之所以感觉不到启用他的区别那是因为我们没有对任何一个列表或者库来对匿名用户启用权限。 这里我们选择停止继承权限，就可以对整个列表实现自定义的权限了。
例子：如果我现在有一个已经运行的网站，里面的大部分内容是不能给匿名用户查看的，怎么办？
我想很多人第一感觉就是尝试列表和库级别的权限，这里我们以让用户能够看到首页为例，我们将网站页面这个库设置为可以匿名访问，直接在没有登录的前提下进入http://domain/SitePages/Home.aspx 是可以的。可是当我们输入http://domain/的时候却弹出来了验证对话框.这是个很悲剧的问题，这说明进入域名后，跳转到http://domain/SitePages/Home.aspx过程中，系统发现了哪个地方权限不足，于是就有了对话框，可是这个过程我们是不能修改的。所以很多管理员在这个时候基本上就已经没有法子了。然后尝试使用将匿名级别设置到整个网站，然后在一一将那些不能公之于众的库一个一个的停止继承权限，再在独立的权限系统上将其匿名级别设为无。这是个体力活。
本人今天遇到了这个问题，苦恼的良久。 最后终于解决了，还是用列表与库级别的，还是上面的操作，只是运行一小点代码而已。这里我写了一个控制台程序来解决这个问题，代码如下：
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Microsoft.SharePoint;
namespace ConsoleApplication
{
class Program
{
static void Main(string[] args)
{
string serverurl = string.Empty;
while (true)
{
Console.WriteLine("Please type the server url here:");
serverurl = Console.ReadLine();
if (string.IsNullOrEmpty(serverurl))
continue;
else
{
try
{
SPSite mysite = new SPSite(serverurl);
SPWeb web = mysite.RootWeb;
web.AnonymousState = SPWeb.WebAnonymousState.Enabled;
web.AnonymousPermMask64 = SPBasePermissions.Open | SPBasePermissions.ViewPages;
web.Update();
Console.WriteLine("Succes!!");
break;
}
catch (Exception e)
{
Console.WriteLine(e.Message);
}
}
}
Console.Read();
}
}
}
文章结尾有源代码下载。如果你再使用sharepoint 2010 的话你也可以直接运行bin文件夹下面的.exe程序来完成。按要求运行此程序后，在到整个网站的权限那看看，权限居然变成了 整个网站，不过你先别急着说我骗你，你在进下你的http://domain/ 是不是能够进去了？可能你立马回给我回一句，匿名界别到整个网站了，能进不去吗？ 呵呵 你再看看那些没有停止继承的列表，难道匿名用户可以访问吗？不能吧。不要被 整个网站 这个级别给迷惑了。这只是表象，事实是我已经完成题设所给的需求。
例二：就拿上面这问题，现在是整个页面库都可以访问，可是我还是有一些页面不能给匿名用户看，怎么办？
首先我想到了停止继承，页面是有自己独立的权限体系的。可是打断继承后我发现，他没有匿名访问这个项目。
让我们进一步了解一下其中缘由：
1、匿名访问在单个列表项目和文件级别上不能配置。
2、单个列表项目和文件从列表库或者文件库中继承匿名权限。
3、当继承关系被断开后，访问单个项目或文件时需要认证访问。（换言之，就不能匿名访问了）
那么微软官方是怎么看待这个问题的尼？
下面看一段译文：
“I can explain why anonymous access at folders with unique permission was not enabled in O12. Basically, the difficult is in managing the anonymous settings, not in browse time permission check.On
“我能解释为什么O12（MOSS 2007）文件夹中的项目具有独有权限后无法匿名访问了。根本上，困难在于管理匿名访问的设置上，而不是访问权限检查。管理匿名访问的一个目标是在一个比较高的层次上阻挡匿名访问后，下面的内容应该会得到保护。如果你在较低层次上启用匿名访问，它不能自动在更高层次上开放内容。
For example, at web level, the anonymous state has three values: disabled, enabled, open. If it’s disabled, then all lists within the web are off limit to anonymous users, no matter whether the list has unique permissions or not. If it’s enabled, then the web itself (and all lists inheriting permission from the web) is not accessible by anonymous user, but lists with unique permissions MAY be opened to anonymous user.
举个例子，在网站层次，匿名状态有3个值，禁止，启用，开放。如果是“禁用”，则网站中的所有项目对匿名用户拒绝访问，无论列表是否有独有权限。如果“启用”，则网站自身（和所有继承了该网站权限的项目）不能被匿名访问，但是拥有独有权限的用户可以对匿名用户设置开放。
Now, suppose that we want to allow user to manage anonymous permission at folder/item level. Then the parent scope (could be parent folder, parent list, or parent web) should at least “enable” anonymous access. This means we have to implement “enable” semantic at list/folder level. Also, when you disable anonymous access at web/list/folder level, we must also update security setting on all subfolder/items to remove anonymous access. This will scan the docs table.This is the reason that in O12, if you set a folder/item to have unique perm, it automatically sets anonymous permmask to 0.”
这样的话，假设我们允许用户管理文件夹/项目级别的匿名权限。那么在上级范围内（父文件夹、父列表、父网站）至少要“启用”匿名访问的设置。这意味着我们不得不在列表/文件夹层支持“启用”状态；同时，当你禁用了某个网站/列表/文件夹层的匿名访问层次后，我们必须也更新所有子文件夹/子列表项目上的安全设置，去掉匿名访问设置。这会扫描文件表。这就是为什么在O12（MOSS2007）中将单个文件夹/项目设置拥有独有权限，它自动将匿名访问设置为0的原因。”