Пользовательский RoleProvider не работает при развертывании в каталоге bin веб-приложения

Я создал настраиваемых поставщиков членства и ролей для веб-приложения SharePoint.

Если я разверну DLL для этих классов в GAC, положение о членстве / роли будет работать нормально. Если я развертываю эти библиотеки DLL в папке bin веб-приложения в IIS, веб-приложение сразу выдает ошибку сервера при переходе на сайт.

Сообщение об ошибке парсера: исключение было выброшено целью вызова.

Если я просматриваю источник на странице ошибки, я получаю немного больше информации:

[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, логическое значение и выполнено синхронно)

Строка, о которой идет речь:

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

Это должно быть свойство разрешений, потому что, как я уже сказал, при развертывании в GAC ошибок не будет - и, кроме того, ошибок не будет, если я настрою 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? Что могло заставить их потерпеть неудачу?


authentication c# asp.net membership-provider roleprovider
person ngm    schedule 05.04.2011    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Это может быть дикой догадкой, но, возможно, ваше приложение-root на несколько уровней ниже? т.е.

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

вместо того

http://foo.com/

? Если это так, вам необходимо убедиться, что IIS знает, что нужно рассматривать /MyApp / /bar/MyApp корневой каталог приложения, щелкнув «создать приложение» в IIS (появится значок болота).

По сути, ~/bin относится к корневому каталогу приложения, который по умолчанию является корневым каталогом сайта. Таким образом, даже если ваш код находится в /bar/MyApp, он ищет dll в /bin/some.dll. Если правильно пометить корень приложения, он будет искать /bar/MyApp/bin/some.dll.

person Marc Gravell    schedule 05.04.2011
comment
Спасибо, да, корень приложения - это корень сайта (насколько я понимаю, в любом случае - вполне возможно, что SP выполняет какие-то махинации за кулисами, о которых я не знаю ...) Поставщики работают, если я установил доверие на Полное в web.config, так что я думаю, он может найти хотя бы DLL? - person ngm; 05.04.2011