部署到 Web 应用程序的 bin 目录时,自定义 RoleProvider 不起作用

发布于 2024-10-30 14:40:18 字数 2864 浏览 3 评论 0原文

我已经为 SharePoint Web 应用程序创建了自定义成员资格和角色提供程序。

如果我将这些类的 DLL 部署到 GAC 中,成员资格/角色规定就可以正常工作。如果我将这些 DLL 部署到 IIS 中 Web 应用程序的 bin 文件夹,则 Web 应用程序在浏览该站点时会立即因服务器错误而失败。

解析器错误消息:调用目标已引发异常。

如果我在错误页面上查看源代码,我会得到更多信息:

[ConfigurationErrorsException]:调用目标已引发异常。 (C:\inetpub\wwwroot\wss\VirtualDirectories\theportal.com80\web.config 第 119 行) 在 System.Web.Security.Roles.Initialize() 在 System.Web.Security.RoleManagerModule.OnLeave(对象源,EventArgs eventArgs) 在 System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() 在 System.Web.HttpApplication.ExecuteStep(IExecutionStep 步骤,Boolean&completedSynchronously)

它所指的行是:

<add name="PortalRoleProvider" applicationName="/" 
     type="Portal.Security.PortalRoleProvider, 
           Portal.Security, Version=1.1.0.0, 
           Culture=neutral,PublicKeyToken=5be544eaa65820dd" 
/>

它必须是一个权限事物,因为正如我所说,如果部署到GAC - 此外,如果我完全信任地设置 Web 应用程序的 web.config,则不会出现错误。

<trust level="full" />

我已经添加了 CAS 策略(嗯,WSPBuilder 已自动为我添加了它们。)但它们似乎不起作用。对于容纳角色提供程序的 DLL,它们如下:

<PermissionSet class="NamedPermissionSet" version="1" Description="WSPBuilder generated permissionSet" Name="portal.shareddllsinstaller.wsp-3a7ba544-2178-4505-a9d9-28622c565d07-1">
    <IPermission class="AspNetHostingPermission" version="1" Level="Medium" />
    <IPermission class="SecurityPermission" version="1" Flags="Assertion, Execution, ControlThread, ControlPrincipal, RemotingConfiguration" />
    <IPermission class="SharePointPermission" version="1" ObjectModel="True" />
    <IPermission class="EnvironmentPermission" version="1" Read="TEMP;TMP;USERNAME;OS;COMPUTERNAME" />
    <IPermission class="PrintingPermission" version="1" Level="DefaultPrinting" />
    <IPermission class="WebPartPermission" version="1" Connections="True" />
    <IPermission class="FileIOPermission" version="1" Read="$AppDir$" Write="$AppDir$" Append="$AppDir$" PathDiscovery="$AppDir$" />
    <IPermission class="WebPermission" version="1">
        <ConnectAccess>
            <URI uri="$OriginHost$" />
        </ConnectAccess>
    </IPermission>
    <IPermission class="IsolatedStorageFilePermission" version="1" Allowed="AssemblyIsolationByUser" UserQuota="9223372036854775807" />
    <IPermission class="DnsPermission" version="1" Unrestricted="true" />
    <IPermission class="SmtpPermission" version="1" Access="Connect" />
    <IPermission class="SqlClientPermission" version="1" Unrestricted="true" />
</PermissionSet>

有什么想法如何让这些自定义角色/成员资格提供程序在 bin 目录中工作吗?什么可能导致他们失败?

I have created custom membership and role providers for a SharePoint web application.

If I deploy the DLL for these classes into the GAC, the membership/role provision works just fine. If I deploy these DLLs to the web application's bin folder in IIS, the web app bails with a server error immediately when browsing to the site.

Parser Error Message: Exception has been thrown by the target of an invocation.

If I view source on the error page I get a bit more info:

[ConfigurationErrorsException]: Exception has been thrown by the target of an invocation. (C:\inetpub\wwwroot\wss\VirtualDirectories\theportal.com80\web.config line 119)
at System.Web.Security.Roles.Initialize()
at System.Web.Security.RoleManagerModule.OnLeave(Object source, EventArgs eventArgs)
at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

The line it is referring to is:

<add name="PortalRoleProvider" applicationName="/" 
     type="Portal.Security.PortalRoleProvider, 
           Portal.Security, Version=1.1.0.0, 
           Culture=neutral,PublicKeyToken=5be544eaa65820dd" 
/>

It must be a permissions thing, because as I say there is no error if deployed to the GAC -- and furthermore, there are no errors if I set the web app's web.config up with full trust.

<trust level="full" />

I have added CAS policies (well, WSPBuilder has added them automatically for me.) They don't seem to be working though. They are as follows for the DLL that houses the role provider:

<PermissionSet class="NamedPermissionSet" version="1" Description="WSPBuilder generated permissionSet" Name="portal.shareddllsinstaller.wsp-3a7ba544-2178-4505-a9d9-28622c565d07-1">
    <IPermission class="AspNetHostingPermission" version="1" Level="Medium" />
    <IPermission class="SecurityPermission" version="1" Flags="Assertion, Execution, ControlThread, ControlPrincipal, RemotingConfiguration" />
    <IPermission class="SharePointPermission" version="1" ObjectModel="True" />
    <IPermission class="EnvironmentPermission" version="1" Read="TEMP;TMP;USERNAME;OS;COMPUTERNAME" />
    <IPermission class="PrintingPermission" version="1" Level="DefaultPrinting" />
    <IPermission class="WebPartPermission" version="1" Connections="True" />
    <IPermission class="FileIOPermission" version="1" Read="$AppDir$" Write="$AppDir$" Append="$AppDir$" PathDiscovery="$AppDir$" />
    <IPermission class="WebPermission" version="1">
        <ConnectAccess>
            <URI uri="$OriginHost$" />
        </ConnectAccess>
    </IPermission>
    <IPermission class="IsolatedStorageFilePermission" version="1" Allowed="AssemblyIsolationByUser" UserQuota="9223372036854775807" />
    <IPermission class="DnsPermission" version="1" Unrestricted="true" />
    <IPermission class="SmtpPermission" version="1" Access="Connect" />
    <IPermission class="SqlClientPermission" version="1" Unrestricted="true" />
</PermissionSet>

Any ideas how to get these custom role/membership providers to work in the bin dir? What might be causing them to fail?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

眼泪都笑了 2024-11-06 14:40:24

这可能是一个疯狂的猜测,但也许:您的应用程序根目录是否低了几级?即

http://foo.com/MyApp
http://foo.com/bar/MyApp

代替

http://foo.com/

?如果是这样,您需要确保 IIS 知道将 /MyApp / /bar/MyApp 视为应用程序根目录,方法是在 IIS 中单击“创建应用程序”(它将获得一个沼泽图标)。

本质上,~/bin 是相对于应用程序根目录的,默认情况下是站点根目录。因此,即使您的代码位于 /bar/MyApp,它也会在 /bin/some.dll 中查找 dll。通过正确标记应用程序根目录,它将查找 /bar/MyApp/bin/some.dll

This might be a wild guess, but perhaps: is your application-root a few levels down? i.e.

http://foo.com/MyApp
http://foo.com/bar/MyApp

instead of

http://foo.com/

? If so, you need to ensure that IIS knows to consider /MyApp / /bar/MyApp the app-root, by clicking "create application" in IIS (it'll get a bog icon).

Essentially, ~/bin is relative to the app-root, which is by default the site-root. So even though your code is at /bar/MyApp, it is looking for the dll in /bin/some.dll. By correctly marking the application root, it will look for /bar/MyApp/bin/some.dll.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文