RSS

从“为什么不能直接打开PDF文件”说到“脚本攻击”

先从一个简单的问题说起。

前两天在网上,有网友问我这样一个问题:“上载到SharePoint 2010文档库中的一个PDF文件,当直接点击此文件链接时,为什么浏览器弹出的对话框只有保存,而没有打开?”

image

就像上面的截图所显示的,在浏览器弹出的对话框上,只能让用户保存(Save)的选项,而没有一个打开(Open)的选项。但可能有人会记得,以前SharePoint 2007的时候,并不是这样的。用户直接点击一个存放在SharePoint 2007文档库里面的PDF文件时,浏览器会提示用户,可以直接打开它,然后本地安装的PDF Reader就会直接打开这个PDF文件,开始阅读。

先说解决这个问题的方法。打开SharePoint 2010管理中心,管理Web应用程序,选择一个Web应用程序,点击Ribbon区域的“常规设置”,然后在弹出的设置对话框中,将“浏览器文件处理程序”这个设置项从默认的“严格”,修改为“许可”。

image

搞定!你会发现修改了这个设置之后,浏览器会重新显示出“打开”选项,让用户可以直接打开PDF文件。

好了,如果你只是想解决这个问题,可以不用继续往下阅读了。

嗯,想知道为什么?好吧,这就是原因。重新将Web应用程序常规设置中的“浏览器文件处理程序”设置项改回默认的“严格”。打开文档库,这次在点击PDF文件链接之前,打开浏览器的Developer Tools(在IE浏览器中是通过F12打开它,下面将使用IE浏览器做例子,FireFox和Chrome也有各自的类似工具可以使用)。在“Network”选项卡中点击“Start capturing”按钮,它会捕获当前浏览器窗口与服务器之间的所有网络通信。然后,点击那个PDF文件链接。

image

在“Network”选项卡里面,找到用户点击PDF链接时所产生的网络请求,双击它,就可以看到这次请求的所有详细的Request和Response信息。点击“Response headers”选项卡,就可以看到从SharePoint 2010服务器所返回的HTTP头信息。嗯,如下图所示,你会看到一个有趣的头信息,“X-Download-Options = noopen”。

image

就是这个HTTP头信息,告诉浏览器:“不要直接打开这个文件,不要给用户显示出打开选项!”

当我们在SharePoint 2010管理中心里面,将Web应用程序的“浏览器文件处理程序”设置项从默认的“严格”修改为“许可”时,SharePoint 2010服务器就会停止在HTTP头里面添加这个头信息,于是,浏览器又会允许用户直接打开文件了。

SharePoint 2010默认会禁止浏览器直接打开所有存放在文档库中的任何文件,方法就是向返回给浏览器的HTTP头信息中添加那个额外的metadata。为什么当用户点击Office文档的时候,仍然会自动打开本地的Office程序,打开Office文档呢?这其实是因为页面上的脚本会调用OpenDocuments这个ActiveX控件,由它来启动客户端的Office程序,打开Office文档。

SharePoint 2010为什么这么做?原因就是为了更好的安全性。由于SharePoint通常会允许非网站管理员上载文件到文档库里面,所以让浏览器随便打开这些用户上载的文件,实际上是一件非常危险的事情。在最严重的情况下,这会给恶意用户提供实施脚本攻击的漏洞,甚至引发跨站点脚本攻击。比如,一个仅仅具备Contributor(参与讨论)角色的用户,可能会上载一个扩展名是.docx,但实际上确实一个含有恶意脚本的.html文件,到文档库中。当管理员尝试打开这个“Word文档”时,浏览器可能会尝试直接打开它,并无意中运行那个文件中所包含的脚本。

当然,除了禁止用户直接在浏览器中打开文档库中的文件之外,SharePoint 2010还在网站的安全性上做了其他一些增强。比如,Contributor现在不能直接上载一个页面文件到Pages(页面)库中,而只能通过Pages库内置的“创建页面”功能,来新建页面。又比如,通过在web.config的<SaveControl>节点中添加“SafeAgainstScript”和“RequiresDesignerPermission”属性,系统管理员可以禁止Contributor修改Web部件的属性。当然,这些又是另外一个话题了。

 

Posted by on 2011/05/16 in 未分类

Leave a comment

Tags:

搜索范围的管理

什么是搜索范围?当我们使用百度的时候,就能看到它们。为了帮助用户更精确的找到自己想要的内容,可以定义一些搜索范围,这样用户通过使用搜索范围,就能告诉搜索引擎,自己想要搜索的内容的范围,以得到更精准的结果。

image

SharePoint Server 2010内置的搜索功能也支持搜索范围。SharePoint 2010已经内置定义好了两个搜索范围:“所有网站”和“人员”。前者包括所有内容源中的所有内容,后者则只包含了所有用户(来自于用户配置文件)。如果需要,管理员也可以添加额外的搜索范围,帮助用户更方便的搜索到希望的内容。

要创建一个自定义搜索范围,并使其显示在SharePoint 2010搜索中心,需要进行一些额外的设置。本文将演示为SharePoint 2010系统添加一个“Word文档”搜索范围,并使用户可以通过搜索中心,方便的使用这个搜索范围来进行Word文档的搜索。

(一) 在搜索服务应用程序中添加搜索范围

打开SharePoint 2010管理中心,通过“管理服务应用程序 – Search Service Application”打开搜索管理界面。点击搜索管理页面左侧的“范围”链接,然后点击“新建范围”。

image

为新范围取名为“Word文档”,然后在目标结果页面中输入“WordResults.aspx”这个页面。别担心,稍后我们会在搜索中心网站中,把这个页面创建出来。这个页面将用来显示“Word文档”搜索范围的搜索结果。

接下来,为“Word文档”范围添加规则。规则定义了哪些搜索结果是属于某个搜索范围的。规则有多种类型,既可以使用URL匹配(比如某个路径下的内容属于某个范围),也可以使用属性(比如凡是作者等于kaneboy的内容属于某个范围),或内容源(比如凡是来自某个BCS外部数据内容源的内容属于某个范围)来定义规则。

image

由于只希望扩展名为“.doc”和“.docx”的文件出现在“Word文档”搜索范围中,所以需要定义一个属性查询类别的规则,并添加一个“FileExtension = docx”的属性查询条件。在规则行为中,选择“包含”。如法炮制,为“Word文档”范围再添加一个“FileExtension = doc”的规则。定义好这两个规则的搜索范围设置界面如下图。

image

SharePoint 2010搜索服务是定时更新范围设置,所以为了让我们修改的范围设置立即生效,可以在搜索管理首页,点击“立即开始更新”链接。

image

为了让新建的搜索范围可用,可以在定义好了范围之后,对所有内容源进行一次完全爬网。

(二) 在网站集中使用搜索范围

在网站集中,就可以直接使用我们在搜索服务应用程序中定义的范围。打开网站集顶级网站的网站设置页面,在“网站集管理”区域中点击“搜索范围”链接,应该就能看到我们之前定义好的“Word文档”范围。

image

点击“显示组”,就能看到“搜索下拉列表”和“高级搜索”这两个组。分别编辑它们,把“Word文档”范围包含进去。

image

然后在网站设置页面中的“网站集管理”区域中点击“搜索设置”,打开网站集搜索设置页面。通过在“网站集搜索中心”里面输入一个搜索中心网站的路径,可以将网站集的搜索与一个搜索中心连接起来。比如,如果在这个网站集里面,使用“search”路径和“企业搜索中心”模板创建了一个搜索中心网站,就可以将“search/pages”填入到“网站集搜索中心”文本框。这样,当用户在网站集里面使用搜索功能时,都会被自动导向到这个搜索中心。

“网站集搜索下拉列表模式”用来定义是否在网站集的搜索框左侧,显示范围下拉框。如果选择“显示范围下拉列表”,就会将范围下拉框显示在搜索框左侧。

image

完成这些设置后,回到网站首页,就会看到上面所做的这些设置是如何影响网站集里面的搜索功能的。

image

最后,由于指定了网站集的搜索会和路径为“search”的搜索中心网站连接起来,接下来我们就来创建这个搜索中心网站。

(三) 在搜索中心网站使用搜索范围

首先,我们需要在网站集里面,使用“企业搜索中心”模板,在指定的“search”路径上(以与网站集设置中指定的路径想匹配)创建一个搜索中心网站。

image

打开新建的搜索中心网站,你会看到在这里并不会自动出现我们定义好的“Word文档”范围。

image

打开搜索中心网站的“所有网站内容”页面,能看到在这个网站里面,有2个非常关键的列表,“搜索结果中的选项卡”和“搜索页中的选项卡”。

image

打开“搜索页中的选项卡”列表,添加一个新项目,在“选项卡名称”中输入“Word文档”,在“页面”中输入“WordSearch.aspx”(别担心,我们会稍后再创建这个页面)。

image

如法炮制,在“搜索结果中的选项卡”列表中添加一个新项目,“选项卡名称”指定为“Word文档”,“页面”指定为“WordResults.aspx”(我们也会稍后创建它)。

image

接着我们就来创建之前指定的“WordSearch.aspx”和“WordResults.aspx”页面。前者是用来进行搜索的页面,后者是用来显示搜索结果的页面。

打开搜索中心网站中的“页面”文档库,点击Ribbon区域的“新建文档 – 页面”。

image

为新页面指定一个标题,“搜索Word文档”,将页面的URL指定为“WordSearch.aspx”(与前面所指定的路径相对应),页面布局选择“搜索框”。

image

如法炮制创建第2个页面,页面标题为“Word文档搜索结果”,页面URL为“WordResults.aspx”,页面布局选择“搜索结果”。

image

创建了“WordSearch.aspx”和“WordResults.aspx”页面之后,还需要对它们进行一些设置。打开“WordSearch.aspx”页面,进入到编辑状态,然后编辑“搜索框”Web部件的属性。

image

将“搜索框”Web部件的“目标搜索结果页面URL”属性的值修改为“WordResults.aspx”。这样当用户在当前页面搜索时,才会将搜索请求发送到“WordResults.aspx”页面。

image

接着打开“WordResults.aspx”页面,进入到编辑状态,同样修改页面上的“搜索框”Web部件,将“目标搜索结果页面URL”属性的值修改为“WordResults.aspx”(也就是当前页面)。

image

接着修改页面上“搜索核心结果”Web部件的属性。

image

将“搜索核心结果”Web部件的“范围”属性修改为指定的“Word”文档范围。

image

这样我们就完成了对这两个页面的修改。最后要记得将它们签入为主要版本,否则普通用户会无法访问它们。

image

回到搜索中心网站的首页,就会看到现在有了第三个范围,“Word文档”。当点击这个范围时,页面实际上会跳转到“WordSearch.aspx”页面。当使用这个范围进行搜索时,搜索结果会显示在“WordResults.aspx”页面。

image

除了使用搜索中心网站,当在网站集里面进行搜索时,由于网站集搜索已经与搜索中心网站连接了起来,用户的搜索请求也会被转向到搜索中心网站。

总结

通过定义自定义的搜索范围,用户可以更加方便的使用SharePoint 2010所提供的搜索功能。但是要让自定义搜索范围能正常工作,管理员需要在搜索服务应用程序、网站集和搜索中心网站中,进行一系列的设置。

 

Posted by on 2011/04/30 in 未分类

Leave a comment

Tags:

创建自定义主机头的网站集

当我们在一个SharePoint Web应用程序中创建新网站集时,虽然我们可以指定网站集的路径,但是网站集的主机头,似乎必须使用Web应用程序所定义的主机头。比如,当在“http://sp2010”这个Web应用程序中创建一个新网站集时,网站集的路径可以是下面这些格式:
http://sp2010/sites/itg (通过使用默认定义的“sites”管理路径)
http://sp2010/itg (通过创建一个新的“itg”管理路径)

image

但是无论使用哪种路径合适,这个新网站集的主机头仍然需要使用“http://sp2010”,这个主机头是在创建Web应用程序时,指定给Web应用程序的。

实际上,SharePoint是允许我们创建自定义主机头的网站集的。比如,在“http://sp2010”Web应用程序里面,我们完全可以创建一个访问路径为“http://itg.contoso.com”的网站集。

当然,如果你要使用一个自定义的主机头,首先需要确保DNS系统能够正确的将这个主机头的域名解析到正确的IP地址上。比如,如果需要使用“itg.contoso.com”作为新网站集的主机头,可能就需要在DNS服务器上添加对这个域名的解析记录。

image

要创建自定义主机头的网站集,不能通过Web UI界面完成,而必须使用PowerShell指令。打开SharePoint服务器上的SharePoint 2010 Management Shell,然后使用下面这行指令来创建自定义主机头的网站集:

New-SPSite http://itg.contoso.com -Name “Contoso IT Group” -OwnerAlias contoso\administrator – HostHeaderWebApplication http://sp2010

New-SPSite的4个参数分别指定了新网站集的路径、名称、所有者和所属的Web应用程序。

image

在管理中心,查看Web应用程序中的网站集时,就会看到这个拥有自定义主机头的网站集。

image

由于使用New-SPSite指令创建网站集时,并未指定要使用的网站模板,所以通过浏览器第一次访问它时,会提示管理员为首要网站指定一个网站模板。

image

最后值得一提的是,并非只有SharePoint 2010才能支持自定义主机头的网站集,SharePoint 2007就已经支持这个特性了。在SharePoint 2007系统中,创建自定义主机头网站集的方法是使用stsadm指令。例如:

stsadm -o createsite -url http://itg.contoso.com -title “Contoso IT Group” -ownerlogin contoso\administrator -owneremail administrator@contoso.com -hhurl http://sp2007

 

Posted by on 2011/03/25 in 未分类

Leave a comment

Tags:

SharePoint 2010多语言UI,以及开发人员需要注意的

SharePoint 2010支持同一个网站呈现出不同语言的UI。比如,一个中文版的SharePoint 2010系统,管理员可以在服务器上安装SharePoint 2010英文语言包,然后在网站设置的“语言设置”中,选择“英语”为备用语言。

image

然后用户就可以随时使用页面右上角的用户菜单,将当前网站的显示UI,在多个语言之间进行切换。

image

如果你尝试一下这个功能,就会发现一个有趣的现象。对于SharePoint 2010的内置列表和文档库,它们的名称,以及所有字段的名称,都会根据当前的UI语言,显示成不同的语言文字。比如,这是“共享文档”在中文UI语言下所显示的样子:

image

如果这时将UI切换成英文,那么它就会变成:

image

嗯,就如你所见,无论是文档库的名称(“共享文档”->“Shared Documents”),还是字段的名称(“类型”->“Type”),它们都可以很好的适应当前的语言UI,自动显示成不同语言的文本。

那么,对于自定义的列表和文档库,它们也会具备这种能力吗?不用试就知道,除非我们进行额外的处理,SharePoint 2010不可能知道应该如何将自定义列表的名称和字段名称,显示成不同语言的文本。

假设我们有一个自定义列表,“公司客户”,它包含有一个自定义字段,“客户地址”,此列表在中文UI下显示成这样:

image

如果希望“公司客户”列表具备多语言显示能力,可以通过如下的代码实现:

image

上面代码的作用,就是将列表名称的英文版本(en-US),设置为“Company Customers”,并且将“客户地址”字段的英文版本,设置为“Customer’s Address”。下面的截图就是运行了上面的代码后,这个列表在英文UI下的显示:

image

通过代码你应该看出来了,SPList和SPField都有一个TitleResource属性,通过这个属性,我们可以获取或设置在不同语言中,列表或字段的Title值。那么如果在代码中直接获取或设置SPList和SPField的Title属性,会怎么样呢?答案就是,这时SharePoint对象模型会根据当前代码所在线程的UI Culture,来自动获取不同语言版本的Title值。下面的代码就示范了这个用法:

image

两次调用SPList.Title属性,由于分别为当前线程设置了不同的UI Culture,Title属性就会返回不同的值。

由于这个特性的存在,在某些事情,如果没有考虑周全,就会在你的自定义代码中产生一些bug。让我们想象这样的一个场景:你的SharePoint 2010是中文版,但是SharePoint服务器上的Windows Server是英文版本。你需要写一些代码,为某个列表添加一个字段:“QQ号码”。你非常清楚字段的显示名称(Title)和内部名称(InternalName)的区别,你不想SharePoint 2010自动为你的新字段生成一个稀奇古怪的内部名称,于是聪明的你决定这样来创建这个字段:

image

在你的设想中,这个新字段的显示名称将是“QQ号码”,它的内部名称将是“QQNumber”。于是,你兴高采烈的在一个Console程序中加上了如上代码,运行了它,然后惊奇的发现这个新字段的显示名称居然仍然显示为“QQNumber”:

image

发生错误的原因在于,代码运行在一个Console程序中,也就是说,它运行在SharePoint Context之外。在运行代码的线程中,UI Culture是英文(因为Windows Server是英文版),所以虽然代码通过SPField.Title属性将字段显示名称设置为“QQ号码”,但实际上它设置的是这个字段的英文版本显示名称。于是,在中文版本的SharePoint 2010网站上,这个字段的显示名称仍然保持为“QQNumber”。同时由于你的代码的作用,如果以后有人将UI切换成英文,会惊奇的发现这个字段居然在英文UI下显示成“QQ号码”。

正确的创建这个字段的代码应该是:

image

在第一行,代码将当前线程的UI Culture设置为了网站的UI Culture(SPWeb.UICulture),这样无论这个代码是在什么语言版本的Windows Server中运行,都会得到我们想要的结果。如果你的代码会运行在SharePoint Context之外,这一点非常重要。

 

Posted by on 2010/12/21 in 未分类

1 Comment

TechED 2010 上的课程

在刚过去的TechED 2010,我讲了两节有关SharePoint 2010的课程,“将SharePoint 2007系统升级到SharePoint 2010”和“为SharePoint 2010创建工作流”。你可以在这里这里下载它们的幻灯片。

关于如何将现有的SharePoint 2007系统升级到SharePoint 2010,是很多人都非常感兴趣的话题。可惜在TechED的这个课程中,由于时间的限制,我只讲述了幻灯片中少部分的内容。为了让大家了解更多有关升级的信息,我将撰写一个2010升级系列的文章,按照TechED幻灯片中的内容,详细的进行介绍。

另外,为了方便和墙内的同志们交流,最近在新浪微博上也注册了帐号,发布的内容基本上和我的twitter帐号是同步的。我的twitter新浪微博帐号都是@kaneboy。

 

Posted by on 2010/12/08 in 未分类

1 Comment

广告贴:本周六的SharePoint技术交流会

本周六(10月30日),我会参加在利星行广场的SharePoint技术交流会,并讲一节“SharePoint 2010 沙盒解决方案”的课程。有兴趣的同志们可以去参加这个活动。

活动地点:望京利星行广场C座微软大厦三层306室(微软中国公司所在)

时间:9:00 – 18:00(8:30开始签到)

费用:无。(但午餐需自己解决。)

活动详情:http://www.msiw.net/Pages/2010%E5%B3%B0%E4%BC%9A%E6%B3%A8%E5%86%8C.aspx

See you there! Smile

 

Posted by on 2010/10/28 in 未分类

1 Comment

SharePoint 2010 RBS FILESTREAM Provider 的“垃圾收集”

在以前的博客中,我曾经介绍过如何在SharePoint 2010系统中安装和配置RBS FILESTREAM Provider,实现将SharePoint中的文件存储到磁盘文件系统中。但是当用户在SharePoint中上载文件时,文件的二进制内容就会通过RBS FILESTREAM Provider,写入到指定的磁盘文件夹之中。通过RBS可以极大的提高SharePoint存储文件的能力,也有效的使SharePoint的内容数据库不会跟着文件数量的增多而不断膨胀。

但是当用户从SharePoint网站上删除一个文件时(并且已经将文件彻底的从SharePoint回收站中删除),RBS FILESTREAM Provider并不会“真正”的从磁盘文件系统把相应的文件也删除掉。为了提高性能,RBS FILESTREAM Provider只会记录下有一个文件被“删除”了,但是要想真正从磁盘文件系统上删除这个物理文件,就需要一些额外的步骤,来完成“垃圾收集”的工作。

RBS FILESTREAM Provider内置了一个命令行维护工具,这个工具就能够实现“垃圾收集”。除此之外,实际上它还可以进行一致性检查、数据维护等诸多工作。但今天我们要讲的,还是集中在如何使用这个维护工具实现“垃圾收集”,来将那些垃圾物理文件从磁盘文件系统上彻底删除。

当RBS FILESTREAM Provider被安装到机器上时,在默认的安装目录中(Program Files\Microsoft SQL Remote Blob Storage 10.50),有一个“Maintainer”文件夹。里面有2个文件:Microsoft.Data.SqlRemoteBlobs.Maintainer.exe和Microsoft.Data.SqlRemoteBlobs.Maintainer.exe.config,前者就是那个命令行维护工具,后者则是维护工具的配置文件。

在使用维护工具之前,需要打开那个配置文件,在配置文件中指定启用了RBS功能的SharePoint内容数据库的连接字符串。每个内容数据库都需要分别指定一个连接字符串。如果你是第一次打开配置文件,会发现里面的连接字符串默认是使用加密方式保存的。嗯,我个人觉得这实在是一件没有必要的事情,因为维护工具本来就需要直接运行在SharePoint服务器上,这是一件需要服务器管理员权限才能干的事情,所以似乎把服务器上配置文件中的连接字符串进行加密,未免过分小心了…当然,如果你是使用混合认证方式连接到数据库,那把连接字符串加密一下也未尝不可。加密连接字符串的方式是使用aspnet_regiis.exe这个命令行工具。不过在这篇文章中,我就只演示用明文保存连接字符串好了。

下图就是在我的机器上,配置文件的内容。里面只定义了一个连接字符串。连接字符串的名称是“WSS_Content_ConnStr”,连接字符串的内容是“Data Source=sp2010;Initial Catalog=WSS_Content;Integrated Security=True”。这些都需要感觉实际环境中的情况进行修改。如果有多个SharePoint内容数据库都启用了RBS,那么就需要针对它们分别添加多个连接字符串,给每个连接字符串一个不同的名称。

image

接下来就可以在命令行中执行维护工具了。输入如下指令并运行:

Microsoft.Data.SqlRemoteBlobs.Maintainer.exe -ConnectionStringName WSS_Content_ConnStr -Operation GarbageCollection -GarbageCollectionPhases rdo

指令中绿色标记的部分,需要等同于配置文件中所指定的连接字符串名称。维护工具在执行时,会输出一些文字信息,显示出它收集了多少个垃圾文件。

image

如果你在自己的实验环境中执行了上面的指令,很可能发现它并没有删除一个垃圾文件,而如果你重复执行它,它甚至会告诉你,由于间隔时间太短,它“拒绝”频繁运行。这是因为每个SharePoint内容数据库在启用了RBS之后,都会多3个与维护工具相关的时间间隔参数:“delete_scan_period”、“orphan_scan_period”和“garbage_collection_time_window”,它们指定了诸如最小允许的扫描周期、清除垃圾文件周期等等设置。这3个参数会共同影响维护工具的扫描和清除垃圾文件的过程。

在通常情况下,是不需要修改这3个参数的。在实验环境中,为了检验垃圾收集的效果,可以尝试修改这3个参数。打开SQL Server 2008 Management Studio,选中一个SharePoint内容数据库,然后执行:

exec mssqlrbs.rbs_sp_set_config_value ‘delete_scan_period’,’time 00:00:00′

exec mssqlrbs.rbs_sp_set_config_value ‘orphan_scan_period’,’time 00:00:00′

exec mssqlrbs.rbs_sp_set_config_value ‘garbage_collection_time_window’,’time 00:00:00′

上面3条SQL指令将这3个时间间隔参数都设置为0。如果维护工具发现有垃圾文件,在它输出到屏幕的信息中会显示相应的信息。

到现在为止,上面所讲的整个过程就是RBS FILESTREAM Provider的垃圾收集。但是由于RBS FILESTREAM Provider使用了SQL Server 2008中的FILESTREAM特性,而FILESTREAM组件自己对于垃圾文件,也有自己的一套管理方法。换句话说,在RBS的层次,RBS会通过自己的垃圾收集来删除垃圾文件,但这并不会影响到FILESTREAM的层次。即使在RBS层次已经完成了“垃圾收集”,并认为已经把一个文件删除了,但在FILESTREAM层次,却可能仍然不会将文件从磁盘文件系统上删除,除非FILESTREAM组件自己进行一次“垃圾收集”。

强制FILESTREAM进行“垃圾收集”最简单的方法就是在数据库上执行下面这个SQL指令:

CHECKPOINT

最后,对于RBS FILESTREAM Provider维护工具,由于它是一个命令行工具,所以可以使用Windows计划任务来定时执行它。对于FILESTREAM的SQL指令,可以通过SQL Server的作业来定时执行。

参考:

关于RBS“垃圾收集”的详细信息

关于FILESTREAM“垃圾收集”的详细信息

 

Posted by on 2010/10/28 in 未分类

3 Comments

ASP.NET Security Vulnerability对SharePoint的影响

嗯,是的,最近闹得沸沸扬扬的ASP.NET Security Vulnerability同样会影响SharePoint Server。如果你手头有正在运行的SharePoint生产服务器(特别是服务器是用来提供Internet Web网站服务的情况),请确保阅读了这篇文章。Erucy已经写了一篇专门的文章讲述SharePoint 2007/2010的workaround

 

Posted by on 2010/09/27 in 未分类

1 Comment

为SharePoint网站创建自定义导航菜单

相信不少人都希望把SharePoint网站内置的那个顶部导航菜单,换成自己希望的样式。由于SharePoint 2007/2010的网站导航基本上基于标准的ASP.NET SiteMap模型,所以只要你对ASP.NET SiteMap有一些了解,就能创建一个自定义的导航菜单。

在开始之前,让我们先从网上随便找一个样子比较cool的菜单控件。在下面的示例中,我会选择使用Smooth Navigation Menu这个jQuery控件,来渲染出SharePoint网站的顶部导航菜单。将Smooth Navigation Menu控件相关的.js、.css、.gif文件统统下载下来,我们将把它们都放进SharePoint项目中。

打开Visual Studio 2010,创建一个SharePoint 2010项目(我最喜欢的项目模板是“空白SharePoint项目”),在项目中添加一个映射文件夹,来存放Smooth Navigation Menu控件所需的所有文件。我选择在Layouts文件夹中创建一个SmoothNavMenu子文件夹来存放这些文件,如下图所示:

image

接下来开始创建自定义导航菜单。实际上,我们有很多方法可以用来创建自定义导航菜单。例如,我们可以选择以自定义控件的方式,来创建一个自定义导航菜单。由于在这个示例中,我们使用的是一个jQuery插件来实现界面渲染,所以选择以用户控件(.ascx)的方式来创建自定义导航菜单,似乎是一个更好的选择。

在Visual Studio 2010中,向项目中添加一个用户控件,为其命名为SmoothNavMenu.ascx。

image

然后打开新建的这个SmoothNavMenu.ascx用户控件,为其填充内容。

image

SmoothNavMenu.ascx中大部分的内容,都是按照Smooth Navigation Menu控件的要求,添加所需的.css和.js引用。从第20行到第34行的JavaScript代码,作用是在页面载入之后,将Smooth Navigation Menu初始化。具体用法请参考Smooth Navigation Menu的网站

第16行到第18行,我们将一个Literal控件放到一个<div>元素中。在用户控件的后台代码中,会查询当前网站的顶部导航结构,并生成相应的html元素,然后通过这个Literal控件填充进用户控件。<div>元素的声明同样是Smooth Navigation Menu的要求。Smooth Navigation Menu会根据Literal控件所输出的html元素,渲染出导航菜单。

接着打开用户控件SmoothNavMenu.ascx的后台代码文件,SmoothNavMenu.ascx.cs。在用户控件的后台代码中,我们需要获得当前网站的顶部导航结构,并根据其结构生成html元素。获得网站顶部导航结构的代码是:

image

然后在Page_Load事件中,我们调用此方法来得到网站顶部导航结构,然后通过BuildMenuContent方法(此方法的具体实现代码略)生成Smooth Navigation Menu所需的html元素,然后将这些html元素通过Literal控件的Text属性填充到用户控件界面上。

image

好了,到这里,我们已经把自定义的导航菜单创建好了。但是,如果你想要在网站上使用它,还需要把它放到网站的母版页上面去,同时删除母版页上那个默认的导航菜单控件。要做到这些,你可以使用SharePoint Designer,打开网站,找到母版页,然后蛮干。或者使用更好的方法,在项目中创建一个新的母版页,让新母版页上使用我们创建的自定义导航菜单,然后使网站使用新的母版页。

在Visual Studio 2010中,向项目中添加一个“模块”,把VS2010自动创建的那个Sample.txt文件改名为v4_SmoothNavMenu.master,然后把内容替换为SharePoint 2010网站默认使用的v4.master母版页的内容(直接在SharePoint Designer中找到v4.master,打开它,全选所有html内容,复制,然后到VS2010中打开v4_SmoothNavMenu.master,粘贴)。

image

由于我们需要把v4_SmoothNavMenu.master文件放进网站的母版页样式库里面,所以打开Elements.xml,编辑其内容,修改<Module>标签的Url属性为“_catalogs/masterpage”,修改<File>标签的Type属性为“GhostableInLibrary”:

image

现在我们来修改v4_SmoothNavMenu.master这个母版页文件,从Visual Studio 2010中打开它,首先在头部区域,添加一个<%@ Register %>标签,将之前创建的那个用户控件注册到页面上:

image

然后搜索母版页中一个ID为“PlaceHolderHorizontalNav”的ContentPlaceHolder控件,将里面的那个AspMenu控件删除掉(它就是母版页上原本用来显示顶部导航菜单的控件),然后将我们创建的用户控件添加到这个地方:

image

母版页就成功改好了!我们希望网站的管理员可以通过激活或停用一个Feature,就相应的启用或停用这个新建的母版页。所以,在Visual Studio 2010中,打开Features文件夹,将VS2010自动创建的Feature1改名为SmoothNavMenuFeature,双击它,在Feature设计器界面上为这个Feature添加更友好的说明信息:

image

在SmoothNavMenuFeature上点击鼠标右键,选择“添加事件接收器”,然后在生成的代码文件中,取消FeatureActivated和FeatureDeactivating方法的注释,并添加如下代码。简单来说,这些代码的作用是在管理员激活这个功能时,自动为网站应用新的母版页,并在管理员停用功能时,恢复网站原有的母版页。

image

大功告成!编译,部署,激活“Smooth Navigation Menu 导航菜单”功能,回到网站首页,应该就能看到网站的顶部导航菜单已经被替换成了我们创建的这个自定义导航菜单。

通过“网站设置 – 顶部链接栏”管理页面,你可以为顶部导航添加新的节点。但是,如果这个SharePoint网站不是一个发布网站,通过内置的“网站设置 – 顶部链接栏”管理页面是没法直接创建二级菜单的。嗯,实际上,这里有一个小技巧,通过直接在地址栏输入“http://网站url/_layouts/AreaNavigationSettings.aspx”,就能打开原本只有发布网站才能使用的导航设置页面,其中的“全局导航”就是网站的顶部导航,在这里是可以直接向“全局导航”添加二级菜单的:

image 

然后,下面就是你可以看到的效果,这个菜单就是通过我们在上面所创建的自定义导航菜单所渲染出来的:

image

虽然这篇文章是以SharePoint 2010为基础进行演示,但其中绝大部分内容是可以工作在SharePoint 2007网站中的(当然肯定没有Visual Studio 2010如此之好的工具支持)。另外,对于导航中的权限、访问群组,并没有在这个示例中有所体现。

 

Posted by on 2010/09/27 in 未分类

3 Comments

SharePoint 2010 服务应用程序(Service Application)架构(3)

一个服务应用程序除了可以为服务器场内的网站提供服务之外,还能发布给其他服务器场,为其他服务器场中的SharePoint网站提供服务。比如,如果企业中存在着多个服务器场,它们都需要某个服务器场中的“企业全局元数据”服务应用程序中所存储的公用元数据,那么管理员可以将这个服务器场中的“企业全局元数据”服务应用程序,发布给企业中所有SharePoint 2010服务器场使用。下图显示了在SharePoint 2010管理中心发布一个服务应用程序时的界面。

image

SharePoint 2010已经包含了一组内置的服务应用程序,它们为SharePoint 2010网站提供了诸多后端服务,是组成SharePoint 2010的重要组成部分。下面的表格列出了主要的SharePoint 2010内置服务应用程序,以及它们的简要说明。

服务应用程序

描述

是否存储数据

是否可发布

SharePoint Foundation 2010

SharePoint Server 2010 标准版

SharePoint Server 2010 企业版

Access Services

在浏览器中查看与编辑Microsoft Access 2010数据库。

仅缓存数据

不包含

不包含

包含

业务数据连接

访问和修改后端业务系统的数据。

使用数据库存储

包含

包含

包含

Excel Services

在浏览器中查看Excel文件。

仅缓存数据

不包含

不包含

包含

Managed Metadata Service

提供了对企业级托管元数据的存储和管理,同时可以在网站集之间共享内容类型。

使用数据库存储

不包含

包含

包含

PerformancePoint

提供了PerformancePoint Services所包含的BI报表功能。

仅缓存数据

不包含

不包含

包含

PowerPoint

在浏览器中查看、编辑和广播PowerPoint幻灯片。

仅缓存数据

不包含

不包含

包含

搜索

提供了SharePoint 2010的企业级搜索功能。

使用数据库存储

不包含

包含

包含

安全存储服务

用来存储访问其他应用系统的用户凭证信息,这些凭证信息可用于SSO单点登录场景。

使用数据库存储

不包含

包含

包含

状态服务

暂时存储用户的会话(Session)数据。

使用数据库存储

不包含

包含

包含

使用率和运行状况数据集

收集用户使用率和运行状况数据,提供相关的数据报表。

使用数据库存储

包含

包含

包含

User Profile

为“我的网站”、配置文件页面、社会化标签和其他社会化功能提供支持。

使用数据库存储

不包含

包含

包含

Visio Graphics Service

在浏览器中查看Microsoft Visio图形。

仅缓存数据

不包含

不包含

包含

Web分析

提供Web Service接口。

不存储

不包含

不包含

不包含

Word Automation Services

进行批量自动化文档转换操作。

仅缓存数据

不包含

不包含

包含

 

在上个版本的SharePoint中,只有Office SharePoint Server 2007才具有共享服务提供程序架构,而Windows SharePoint Services 3.0是没有使用共享服务提供程序架构的。但是对于SharePoint 2010,无论是SharePoint Foundation 2010,还是SharePoint Server 2010,都使用了统一的服务应用程序架构。但SharePoint Foundation 2010、SharePoint Server 2010标准版和SharePoint Server 2010企业版所内置的服务应用程序数量是不同的。

除了上面的表格所列出的服务应用程序之外,在为SharePoint 2010系统安装了额外的Office Web Applications和Project Server组件时,它们都会向服务器场中注册更多的服务应用程序。

从上面对SharePoint 2010服务应用程序架构的讨论中,我们可以了解到,服务应用程序架构比上个版本的共享服务提供程序提供了更好的灵活性,并构建起一个强大的后端服务架构。通过服务与服务应用程序,SharePoint 2010将前端的网站与后端的服务有效的进行了分离。

最后需要提醒的是,并非所有SharePoint 2010服务都是基于服务应用程序架构来构建。例如, “Microsoft SharePoint Foundation 沙盒代码服务”服务就并非基于服务应用程序架构,实际上,它使用了一个名为“SPUserCodeV4”的Windows服务来实现自己的功能。

 

Posted by on 2010/09/26 in 未分类

Leave a comment