代码改变世界

Web Deploy 高级应用:自动设置 ACL

2011-01-04 19:39  Nana's Lich  阅读(6042)  评论(0编辑  收藏  举报

引言

前一篇文章中讲解了 Web Deploy 技术的简单使用,以及避免已有的 ACL 设置被清除的办法。

而这一次我将会讲解在使用 Visual Studio (Express) 进行一键发布时自动完成 ACL 设置的办法。

原理

在解决上一篇文章的问题的过程中中提到了 MSBuild 指令的使用,稍加思考的话并不难得出这样一个结论:

Web Deploy 设置 ACL 的具体方式也是通过 MSBuild 操控的。

而如果我们调查了 Microsoft.Web.Publishing.targets 的话,就会发现这样的一些指令:

<!--Make sure the by default Networkservice/AppPoolIdentity have read permissing to the fodler-->
<MsDeploySourceManifest Include="setAcl"
                        Condition="$(IncludeSetAclProviderOnDestination)">
  <Path>$(_MSDeployDirPath_FullPath)</Path>
  <setAclResourceType>Directory</setAclResourceType>
  <AdditionalProviderSettings>setAclResourceType</AdditionalProviderSettings>
</MsDeploySourceManifest>


<!--Make sure the by default anonymousAuthenticationUser have read permissing to the fodler so MIME type files will work-->
<MsDeploySourceManifest Include="setAcl"
                        Condition="$(IncludeSetAclProviderOnDestination)">
  <Path>$(_MSDeployDirPath_FullPath)</Path>
  <setAclUser>anonymousAuthenticationUser</setAclUser>
  <setAclResourceType>Directory</setAclResourceType>
  <AdditionalProviderSettings>setAclUser;setAclResourceType</AdditionalProviderSettings>
</MsDeploySourceManifest>


<!--Additionally if App_Data Need to be ReadWrite-->
<MsDeploySourceManifest Include="setAcl"
                  Condition="$(IncludeSetAclProviderOnDestination) And $(MarkApp_DataWritableOnDestination) And Exists('$(_MSDeployDirPath_FullPath)\App_Data')">
  <Path>$(_MSDeployDirPath_FullPath)\App_Data</Path>
  <setAclAccess>Write</setAclAccess>
  <setAclResourceType>Directory</setAclResourceType>
  <AdditionalProviderSettings>setAclResourceType;setAclAccess</AdditionalProviderSettings>
</MsDeploySourceManifest>

其中 XML 元素名称 MsDeploySourceManifest 表示了它会在 Web Deploy 的程序清单(Manifest)中产生一个对应的指令;

Include="setAcl" 指示了将要产生一个 setAcl 指令,顾名思义,它是用来设置 ACL 的;

Condition="..." 表示这条指令将在特定的条件下产生,由于其中涉及到了大量的其它 MSBuild 指令,现在就详细讲解似乎有点早,为了不让大家被一大堆概念搞得晕头转向,这部分放后面说;

<Path>$(_MSDeployDirPath_FullPath)</Path> 指示了将要向网站程序的根目录设置 ACL,$(_MSDeployDirPath_FullPath) 表示了 Web Deploy 的目标路径(它的实际含义其实是有些区别的,同样放后面);

<setAclAccess>Write</setAclAccess> 指示了赋予写操作的权限,如果只需要读操作权限,可以省略掉;

<setAclUser>anonymousAuthenticationUser</setAclUser> 指示了将要向谁赋予操作权限,anonymousAuthenticationUser 表示匿名访问者,如果希望向应用程序池的身份标识赋予操作权限,就可以省略掉;

<setAclResourceType>Directory</setAclResourceType> 表示将要向一个目录设置 ACL,可以省略掉;

<AdditionalProviderSettings>setAclResourceType</AdditionalProviderSettings> 表示启用 setAclResourceType 选项,如果其中不包含任何选项,就同样可以省略。

 

综合来说,上面所列出的这些指令说明了在默认情况下,Web Deploy 会自动赋予匿名用户及应用程序池对网站目录的读操作权限(省略时)、赋予应用程序池对数据库目录的写操作权限(看来这里不需要写成“Read,Write”,是个有意思的现象)

操练起来

如果要给应用程序池指派其它的操作权限——比方说完全控制网站目录,也需要使用像是这样的指令。

不过实际上在 *.wpp.targets 里面添加这样的 MSBuild 指令的时候是有些技术细节需要注意的,比方说这些指令应该添加在什么地方、怎么样让它们被执行。

就以这次的“完全控制”来说,首先自然要依葫芦画瓢地写一段指令,大概会是这样:

<MsDeploySourceManifest Include="setAcl">
  <Path>$(_MSDeployDirPath_FullPath)</Path>
  <setAclAccess>FullControl</setAclAccess>
  <AdditionalProviderSettings>setAclAccess</AdditionalProviderSettings>
</MsDeploySourceManifest>

注:由于 setAclResourceType 的默认值就是 Directory,所以可省略掉。

 

本质上说,MsDeploySourceManifest 是一种自定义的指令物件,依赖于 MSBuild 的可扩展性发挥作用。

而这种指令物件必须放置在<ItemGroup/>指令中,然后为了能在合适的时机执行这些指令,还需要把它们放进一个命名的<Target/>指令中,结果大概就是这样:

<Target Name="MySetAcl">
  <ItemGroup>
    <MsDeploySourceManifest Include="setAcl">
      <Path>$(_MSDeployDirPath_FullPath)</Path>
      <setAclAccess>FullControl</setAclAccess>
      <AdditionalProviderSettings>setAclAccess</AdditionalProviderSettings>
    </MsDeploySourceManifest>
  </ItemGroup>
</Target>

而指定了名称之后,还需要在适当的生成任务中调用它,才能真正地发挥作用。

如果搜索关于 Web Deploy 和 setAcl 的文章的话,可能会发现有些文章建议在 AfterAddContentPathToSourceManifest 事件中调用这个自定义生成任务,但是实际上这样做的结果是自定义的 setAcl 指令会添加到 Web Deploy 自动生成的 setAcl 指令之前,导致我们设置的 ACL 被覆盖而失去作用。

对于这个问题,国外有同样研究自动设置 ACL 的人,给出的建议是:把调用添加在 AfterAddIisSettingAndFileContentsToSourceManifest 事件中,也就是这样:

<AfterAddIisSettingAndFileContentsToSourceManifest>
  MySetAcl;
</AfterAddIisSettingAndFileContentsToSourceManifest>

到现在为止,我们的 *.wpp.targets 看起来差不多就是这样了:

<?xml version="1.0" encoding="utf-8" ?>
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <AfterAddIisSettingAndFileContentsToSourceManifest>
      MySetAcl;
    </AfterAddIisSettingAndFileContentsToSourceManifest>
  </PropertyGroup>
  <Target Name="MySetAcl">
    <ItemGroup>
      <MsDeploySourceManifest Include="setAcl">
        <Path>$(_MSDeployDirPath_FullPath)</Path>
        <setAclAccess>FullControl</setAclAccess>
        <AdditionalProviderSettings>setAclAccess</AdditionalProviderSettings>
      </MsDeploySourceManifest>
    </ItemGroup>
  </Target>
</Project>

 

而到这个程度,就已经可以达到“向应用程序池赋予对应用程序目录的完全控制权限”的目的了。

在进行发布之前请注意保存 *.wpp.targets,并重新加载项目。

补充说明

有两个技术细节在这里补充一下:

  1. 如果把 IncludeSetAclProviderOnDestination 设置为 False 的话,是可以在 AfterAddContentPathToSourceManifest 事件调用我们的自定义任务的,但是这样做到话 Web Deploy 也不会自动为匿名访问者赋予读取权限,需要我们手动添加相关的指令,所以不推荐这样做。
  2. 在起草本文的过程中参考了 http://leethams.com/blog/?p=102,但是本文省略掉了 AfterAddIisSettingAndFileContentsToSourceManifest 事件的条件属性,原因是:从 *.wpp.targets 导入的指令的执行顺序比较靠前,这个时候绝大部分和 Web Deploy 有关的 MSBuild 属性(包括事件)的内容都为空,条件判断的结果一定为真,没有实际意义。

另外由于实际写出来之后文章内容比预期得要长,所以为了让大家阅读起来方便一些,关于“自定义子目录的 ACL”的部分就要放到后面的部分中了,敬请期待。