那么微软官方是怎么看待这个问题的尼?
下面看一段译文:
“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.One goal of managing anonymous access is to make sure that if you block anonymous access at a higher level, all contents from that level below should also be protected. And if you enable anonymous access at a lower level, it should not automatically open up contents on higher level.
“我能解释为什么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的原因。”
源代码下载