用户获取403错误(用户具有完全控制权限)

我认为assetportalbrowser.aspx正在进行一个对象模型调用,尝试获取数据以填写文件列表。如果是这种情况,并且页面没有获得文件库获取图像的正确值,则该页面将尝试使用项目列表的默认值。如果该用户对默认位置没有权限,则可能会导致403。

这都是推测,但fiddler不显示assetportalbrowser.aspx请求任何其他页面资源。

我在浏览器窗口中直接输入/_layouts/assetportalbrowser.aspx的简短实验一直默认为文档库。该库与打开页面前立即浏览的网站没有任何关系,因此它可能将默认url存储在某个地方,并且可能会有完全不同的位置。

最好的办法是尝试跟踪该用户权限最近的任何更改(即减少)。

我最近在博客上提到了这个话题

您需要一组特定的权限才能使用AssetPortalBrowser进行浏览。 棘手的是,这些权利必须在网站层面上给予,仅仅给予图书馆这些权利是不够的。 第二个问题是assetportalbrowser会记住上次浏览的url。因此,您当前正在添加权限的站点可能不是生成403错误的站点。

http://autoexe.blogspot.com/2009/03/assetportalbrowser-403-access-denied.html

This 可能会有帮助。也可以使用fiddler查看请求失败时的确切内容。

尽量缩小范围:

• 当这个用户键入url时会发生什么 http://yoursite/_layouts/AssetPortalBrowser.aspx 在他浏览器的位置栏里?

• 是无法访问assetportalbrowser.aspx(=IIS中的错误配置)的浏览器,还是assetportalbrowser.aspx试图访问其他内容(因此assetportalbrowser.aspx正在报告错误)

403的子状态码是什么?这通常显示为IIS日志中403之后的数字。

下表应该有助于确定此403的根本原因:

None  Access is denied. 
1 Execute access is denied.
2 Read access is denied.
3 Write access is denied.
4 SSL is required to view this resource.
5 SSL 128 is required to view this resource.
6 IP address of the client has been rejected.
7 SSL client certificate is required.
8 DNS name of the client is rejected.
9 Too many clients are trying to connect to the Web server.
10 Web server is configured to deny Execute access.
11 Password has been changed.
12 Client certificate is denied access by the server certificate mapper.
13 Client certificate has been revoked on the Web server.
14 Directory listing is denied on the Web server.
15 Client access licenses have exceeded limits on the Web server.
16 Client certificate is ill-formed or is not trusted by the Web server.
17 Client certificate has expired or is not yet valid.
18 Cannot execute requested URL in the current application pool.
19 Cannot execute CGIs for the client in this application pool.
20 Passport logon failed.

(来源: HTTP 403.x-Forbidden (IIS 6.0) )

我确实有这个问题。在深入调查并在组之间移动人员以查看哪些组受到了影响,哪些没有受到影响之后,我发现您至少需要“读取”访问集合根目录下的“网站集文档”库。为什么这个库是特殊的,并且没有继承权限,我不明白…

作为网站管理员,从门户主页:网站设置->网站库和列表->自定义“网站集文档”。让这个库从它的父库继承权限,所有这些都会突然生效。当你在那里的时候也要检查“网站集文档”。

不会受伤的。还要检查“网站集图像”库,因为您的原始错误提到了“发布图像”库。

进一步的思考:我通过将我的测试用户添加到portal owners组,然后检查浏览是否在summary link web部件中工作(它确实是这样做的)来诊断这个问题。如果此测试对您有效,则意味着门户所有者可以访问常规用户不能访问的内容。如果是这样的话,我会在根级别检查每一个libarary(与上面相同的技术),寻找一个常规使用无法访问的库。

此外,当在摘要链接Web部件中添加新链接时,有两个浏览按钮:一个指向此处讨论的页面,另一个指向portalimagepicker.aspx。第二个按钮对你的用户有效吗?还是都禁止给403?

如果它是一个系统库,那么是的,它可能应该继承。系统库的描述通常类似于“这个库是由发布功能创建的”。

至少,您可以写下现有权限,然后继承。如果这不能解决问题,你可以把旧的放回去-没有伤害,没有犯规。

具体来说,不是继承使它工作——而是对库具有读访问权限。如果它没有惰性,但您的用户仍然可以访问它,那么这个库就不是问题所在。