部署到 Web 应用程序的 bin 目录时,自定义 RoleProvider 不起作用
我已经为 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 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
这可能是一个疯狂的猜测,但也许:您的应用程序根目录是否低了几级?即
代替
?如果是这样,您需要确保 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.
instead of
? 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
.