Набор средств интеграции утверждений, Azure и SharePoint (часть 3)

Набор средств интеграции утверждений, Azure и SharePoint (часть 3)

Это третья публикация из пяти в серии материалов, посвященных набору CASI Kit (Claims, Azure and SharePoint Integration — утверждения, Azure и интеграция с SharePoint). Часть 1 содержит общий обзор всей платформы и решения, в ней также перечислены вопросы, рассматриваемые в серии публикаций. Часть 2 включает руководство по созданию приложений WCF, реализации в них поддержки утверждений и перемещении в облако Windows Azure. В этой записи блога я рассматриваю один из важных компонентов этой платформы — базовый класс пользовательского элемента управления, который используется для подключения из SharePoint к приложению WCF, размещенному в облаке Windows Azure. Мы рассмотрим следующие темы:

· Базовый класс — что это такое и как его использовать в своем проекте

· Страница макетов Layouts — как добавить новый элемент управления на страницу в каталоге _layouts

· Важные свойства — обзор самых важных свойств базового класса, о которых необходимо знать

Базовый класс набора CASI Kit

Одним из главных компонентов набора CASI Kit является базовый класс пользовательского элемента управления, который подключается к приложению WCF и направляет запросы с маркером входа текущего пользователя. Базовый класс представляет собой стандартный серверный элемент управления ASP.NET, и для реализации рассматриваемой модели разработки необходимо создать новый серверный элемент управления ASP.NET, который наследуется от этого базового класса. В силу ряда причин, о которых я не стану рассказывать в этой записи блога, данный элемент управления должен выполнять следующие два действия:

1. Создание ссылки на службу для приложения WCF, размещенного в облаке Windows Azure.

2. Переопределение метода ExecuteRequest базового класса. На самом деле это довольно просто, поскольку все, что нужно сделать, это написать примерно пять строк кода при создании и настройке прокси, подключаемого к приложению WCF, и затем вызвать метод ExecuteRequest базового класса.

Для начала можно создать новый проект в Visual Studio с типом Windows Class Library. После изменения желаемым образом пространства имен и имени класса следует добавить ссылку на базовый класс набора CASI Kit, который находится в сборке AzureConnect.dll. Также потребуется добавить ссылки на следующие сборки: Microsoft.SharePoint, System.ServiceModel, System.Runtime.Serialization and System.Web.

В базовом классе добавьте оператор using для Microsoft.SharePoint, а затем измените свой класс таким образом, чтобы в нем выполнялось наследование из AzureConnect.WcfConfig. WcfConfig — это базовый класс, который содержит весь код и логику для подключения к приложению WCF, включает все свойства с целью увеличения гибкости реализации и устраняет необходимость типовых изменений файла web.config, которые обычно требуются для подключения к конечной точке службы WCF. Важно понимать, что обычно требуется добавить примерно 100 строк кода изменений для каждого приложения WCF, к которому выполняется подключение, для каждого файла web.config на каждом сервере для каждого использующего его веб-приложения. Базовый класс WcfConfig объединяет все это в самом элементе управления, поэтому вам достаточно просто организовать наследование от него, и все остальные действия будут сделаны за вас. Вместе с тем, все изменяемые свойства в файле web.config также можно изменить в элементе управления WcfConfig, поскольку в нем имеются для них эквивалентные свойства. Я рассмотрю это далее в разделе, посвященном важным свойствам.

Теперь пора добавить новую ссылку на службу в приложение WCF, размещенное в облаке Windows Azure. Набор CASI Kit не требует здесь выполнения каких-либо особых действий — просто щелкните правой кнопкой элемент "Ссылки" в своем проекте и выберите пункт "Добавить ссылку на службу". Добавьте в URL-адрес своего приложения WCF для Azure элемент “?WSDL”, чтобы оно возвращало WSDL-описание для реализации службы. Затем задайте нужное имя и добавьте ссылку, на этом данный этап будет завершен.

Теперь у вас имеется пустой класс и ссылка на службу для вашего приложения WCF. Пора переходить к написанию кода, которого, однако, будет немного. Вам потребуется переопределить метод ExecuteRequest, создать и настроить прокси класса службы и затем вызвать метод ExecuteRequest базового класса. Чтобы упростить это, ниже приведен полный код примера элемента управления, который я присоединил к данной записи блога. Желтым я выделил фрагменты, которые нужно изменить в соответствии с данными вашей ссылки на службу:

using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

using System.Diagnostics;

using Microsoft.SharePoint;

//требуются ссылки на:

//1. AzureConnect

//2. Microsoft.SharePoint

//3. System.ServiceModel

//4. System.Runtime.Serialization

//5. System.Web

namespace AzureWcfPage

{

    public class WcfDataControl : AzureConnect.WcfConfig

    {

        //этот метод должен быть переопределен, чтобы правильно

 //создать и настроить прокси

        public override bool ExecuteRequest()

        {

            try

            {

                //создание экземпляра прокси с привязками и конечными точками, созданными

                //элементом управления базового класса

                CustomersWCF.CustomersClient cust =

                    new CustomersWCF.CustomersClient(this.FedBinding,

                     this.WcfEndpointAddress);

                //configure the channel so we can call it with

              //FederatedClientCredentials.

                SPChannelFactoryOperations.ConfigureCredentials<CustomersWCF.ICustomers>

                     (cust.ChannelFactory,

                     Microsoft.SharePoint.SPServiceAuthenticationMode.Claims);

                //create a channel to the WCF endpoint using the

  //token and claims of the current user

                CustomersWCF.ICustomers claimsWCF =

                    SPChannelFactoryOperations.CreateChannelActingAsLoggedOnUser

                    <CustomersWCF.ICustomers>(cust.ChannelFactory,

                     this.WcfEndpointAddress,

                    new Uri(this.WcfEndpointAddress.Uri.AbsoluteUri));

          //set the client property for the base class

                this.WcfClientProxy = claimsWCF;

            }

            catch (Exception ex)

            {

                Debug.WriteLine(ex.Message);

            }

               

            //now that the configuration is complete, call the method

            return base.ExecuteRequest();

        }

    }

}

Вот и все — фактически пять строк кода, и вы можете просто вставить код переопределенного метода ExcecuteRequest, приведенного здесь, в собственное переопределение. После этого вам потребуется всего лишь заменить выделенные фрагменты на соответствующий класс и интерфейсы, предоставляемые вашим приложением WCF. В выделенном коде выше:

· CustomersWCF.CustomersClient: “CustomersWCF” — это имя, которое я использовал при создании своей ссылки на службу, а CustomersClient — это имя класса, который я предоставляю в своем приложении WCF. В моем приложении WCF класс называется просто “Customers”, а фрагмент “Client” добавляется в конце командой добавления ссылки на службу в VS.NET.

· CustomersWCF.ICustomers: “CustomersWCF” — это то же, что и выше. “ICustomers” — это интерфейс, который я создал в своем приложении WCF, фактически реализованный в классе “Customers”.

Вот и все — это весь код, который нужно написать, чтобы обеспечить обратную связь с вашим приложением WCF, размещенным в облаке Windows Azure. Думаю, вы согласитесь, что это совсем несложно. Небольшое пояснение — написанный вами код обеспечивает передачу пользовательского маркера SharePoint в вызове приложения WCF. Подробнее об этом рассказывается в другой моей записи блога по адресу: http://blogs.technet.com/b/speschka/archive/2010/09/08/calling-a-claims-aware-wcf-service-from-a-sharepoint-2010-claims-site.aspx.

После написания кода вы должны зарегистрировать базовый класс и новый пользовательский элемент управления в глобальном кэше сборок на всех серверах, где они будут использоваться. Очевидно, что это легко можно сделать с помощью решения SharePoint. После создания и регистрации элемента управления время взглянуть на то, как с его помощью осуществляется получение и отображение данных. В наборе CASI Kit я попытался реализовать три основных сценария использования данных Azure:

1. Отображение контента на странице SharePoint с помощью веб-части

2. Получение данных конфигурации, которые будут использоваться одним элементом управления, связанным с несколькими другими, и сохранение их в кэше ASP.NET

3. Получение и использование данных в исполняемых задачах, таких как задания таймера SharePoint

Первый сценарий, скорее всего, будет самым распространенным, поэтому с него мы и начнем. После определения этого подхода кажется, что проще всего создать настраиваемую веб-часть, которая выполняет все эти вызовы во время события Load или какого-либо сходного с ним, извлекает данные и отображает их на странице. Однако на мой взгляд это будет ОГРОМНОЙ ошибкой. Размещение этого кода внутри самой веб-части, чтобы он выполнялся на сервере во время обработки запроса к странице, может привести к резкому падению общей пропускной способности фермы. У меня были серьезные сомнения по поводу размещения на странице веб-частей, связанных с несколькими другими, которые бы направляли скрытые вызовы ко многим другим веб-частям в приложениях и центрах обработки данных для извлечения данных, и я легко мог придумать ситуацию, когда широкое использование таких веб-частей привело бы к полному исчерпанию ресурсов фермы. Однако мы помним, что код должен выполняться на сервере, поскольку необходимо настроить канал для приложения WCF для отправки маркера пользователя вместе с запросом. Мое решение в этой ситуации состоит из двух частей:

1. Пользовательская страница, расположенная в папке _layouts. В ней содержится пользовательский элемент управления, о котором говорилось выше и который будет отображать данные, возвращаемые из вызова WCF.

2. Пользовательская веб-часть, которая НЕ ИСПОЛНЯЕТ КОДА на сервере, а вместо этого с помощью JavaScript и jQuery вызывает страницу из папки _layouts. Она считывает данные, возвращенные со страницы, и передает их для функции JavaScript, которая по умолчанию просто отображает их в веб-части. Разумеется, предоставляемые веб-частью возможности гораздо шире, но их мы рассмотрим в следующей записи блога. Однако в целом, когда пользователь запрашивает страницу, она обрабатывается без необходимости дополнительных скрытых вызовов к приложению WCF. Вместо этого страница проходит по конвейеру обработки и поступает непосредственно в браузер пользователя. Затем после полной загрузки страницы выполняется вызов с целью извлечения только контента WCF.

Страница макетов Layouts

Страницу макетов (layouts), в которой будет размещен ваш пользовательский элемент управления, написать очень просто. Я сделал это в Блокноте минут за пять. Думаю, у вас это получится еще быстрее, потому что я привожу здесь код своей страницы layouts и покажу места, которые вам потребуется заменить.

<%@ Page Language="C#" AutoEventWireup="true" Inherits="Microsoft.SharePoint.WebControls.LayoutsPageBase,Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" MasterPageFile="~/_layouts/simple.master" %>

 

<%@ Assembly Name="Microsoft.SharePoint.ApplicationPages, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"%>

<%@ Import Namespace="Microsoft.SharePoint.ApplicationPages" %>

<%@ Register Tagprefix="SharePoint" Namespace="Microsoft.SharePoint.WebControls" Assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>

<%@ Register Tagprefix="Utilities" Namespace="Microsoft.SharePoint.Utilities" Assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>

<%@ Import Namespace="Microsoft.SharePoint" %>

<%@ Assembly Name="Microsoft.Web.CommandUI, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>

 

<%@ Assembly Name="AzureConnect, Version=1.0.0.0, Culture=neutral, PublicKeyToken=c0b51bd3d3b33212"%>

<%@ Register Tagprefix="AzWcf" Namespace="AzureWcfPage" Assembly="AzureWcfPage, Version=1.0.0.0, Culture=neutral, PublicKeyToken=f0ed63b2f4046026" %>

 

 

<asp:Content ID="Content1" ContentPlaceHolderId="PlaceHolderPageTitle" runat="server">

    <SharePoint:EncodedLiteral ID="wcfConnectPageTitle" runat="server" text="Azure Wcf Connect Page" EncodeMethod='HtmlEncode'/>

</asp:Content>

<asp:Content ID="Content2" ContentPlaceHolderId="PlaceHolderPageTitleInTitleArea" runat="server">

    <SharePoint:EncodedLiteral ID="wcfConnectPage" runat="server" text="Azure Wcf Connect Page" EncodeMethod='HtmlEncode'/>

</asp:Content>

<asp:Content ID="Content3" ContentPlaceHolderId="PlaceHolderSiteName" runat="server"/>

<asp:Content ID="Content4" ContentPlaceHolderId="PlaceHolderMain" runat="server">

    <AzWcf:WcfDataControl runat="server" id="wcf" WcfUrl="https://azurewcf.vbtoys.com/Customers.svc" OutputType="Page" MethodName="GetAllCustomersHtml" />

</asp:Content>

 

И снова, реализация самой страницы весьма проста. Обязательно нужно заменить только строгое имя сборки для вашего элемента управления. В качестве иллюстрации я также выделил несколько свойств в самом теге элемента управления. Эти свойства используются в моей службе WCF, в вашей реализации их можно изменить, а в некоторых случаях удалить полностью. Ниже мы рассмотрим эти свойства подробнее. После создания страницы layouts ее нужно скопировать в каталог _layouts на каждом интерфейсном веб-сервере в ферме SharePoint. После этого ее можно будет вызывать из любого сайта в любом веб-приложении с поддержкой утверждений в ферме SharePoint. Разумеется, не стоит ждать, что она будет работать на сайте с классической системой проверки подлинности, например в центре администрирования. После развертывания страница может использоваться веб-частью набора CASI Kit, о которой я расскажу в четвертой публикации этой серии.

Важные свойства

Элемент управления WcfConfig содержит две крупные категории свойств — для настройки канала и подключения к приложению WCF и для настройки использования самого элемента управления.

Свойства WCF

Как говорилось выше, в элементе управления WcfConfig инкапсулированы все данные конфигурации для приложения WCF, которые обычно находятся в файле web.config. При этом практически все эти свойства являются открытыми и их можно изменять в зависимости от требований реализации. Имеется два важных исключения: версия безопасности сообщений, для которой всегда: MessageSecurityVersion.WSSecurity11WSTrust13WSSecureConversation13WSSecurityPolicy12BasicSecurityProfile10, и транспорт, которым всегда является HTTPS, а не HTTP. В остальном в элементе управления имеется ряд свойств, о которых полезно знать более подробно при создании своей реализации (хотя в обычном случае менять их не нужно).

Во-первых, имеется пять свойств только для чтения, которые предоставляют доступ к объектам конфигурации верхнего уровня. Говоря "только для чтения", я имею в виду, что изменять нельзя только сами объекты, но при работе с элементом управления программным способом можно задавать отдельные свойства этих объектов. Это свойства:

SecurityBindingElement SecurityBinding

BinaryMessageEncodingBindingElement BinaryMessage

HttpsTransportBindingElement SecureTransport

WS2007FederationHttpBinding FedBinding

EndpointAddress WcfEndpointAddress

Другие свойства можно задавать в теге элемента управления, который добавляется на страницу ASPX layouts. При именовании этих свойств я использовал схему, которая, надеюсь, окажется осмысленной для составных значений свойств. Например, свойство SecurityBinding имеет свойство LocalClient, у которого есть логическое свойство CacheCookies. Чтобы максимально упростить понимание и использование этой схемы, я включил свойство с именем SecurityBindingLocalClientCacheCookies. Вы найдете несколько подобных свойств — они дают подсказку, как найти нужное свойство, если вы работаете с пакетом .NET Framework SDK и вам необходимо изменить значения некоторых из этих свойств в реализации базового класса. Ниже приводится полный список этих свойств:

SecurityAlgorithmSuite SecurityBindingDefaultAlgorithmSuite

SecurityHeaderLayout SecurityBindingSecurityHeaderLayout

SecurityKeyEntropyMode SecurityBindingKeyEntropyMode

bool SecurityBindingIncludeTimestamp

bool SecurityBindingLocalClientCacheCookies

bool SecurityBindingLocalClientDetectReplays

int SecurityBindingLocalClientReplayCacheSize

int SecurityBindingLocalClientMaxClockSkew

int SecurityBindingLocalClientMaxCookieCachingTime

int SecurityBindingLocalClientReplayWindow

int SecurityBindingLocalClientSessionKeyRenewalInterval

int SecurityBindingLocalClientSessionKeyRolloverInterval

bool SecurityBindingLocalClientReconnectTransportOnFailure

int SecurityBindingLocalClientTimestampValidityDuration

int SecurityBindingLocalClientCookieRenewalThresholdPercentage

bool SecurityBindingLocalServiceDetectReplays

int SecurityBindingLocalServiceIssuedCookieLifetime

int SecurityBindingLocalServiceMaxStatefulNegotiations

int SecurityBindingLocalServiceReplayCacheSize

int SecurityBindingLocalServiceMaxClockSkew

int SecurityBindingLocalServiceNegotiationTimeout

int SecurityBindingLocalServiceReplayWindow

int SecurityBindingLocalServiceInactivityTimeout

int SecurityBindingLocalServiceSessionKeyRenewalInterval

int SecurityBindingLocalServiceSessionKeyRolloverInterval

bool SecurityBindingLocalServiceReconnectTransportOnFailure

int SecurityBindingLocalServiceMaxPendingSessions

int SecurityBindingLocalServiceMaxCachedCookies

int SecurityBindingLocalServiceTimestampValidityDuration

int BinaryMessageMaxReadPoolSize

int BinaryMessageMaxWritePoolSize

int BinaryMessageMaxSessionSize

int BinaryMessageReaderQuotasMaxDepth

int BinaryMessageReaderQuotasMaxStringContentLength

int BinaryMessageReaderQuotasMaxArrayLength

int BinaryMessageReaderQuotasMaxBytesPerRead

int BinaryMessageReaderQuotasMaxNameTableCharCount

System.Net.AuthenticationSchemes SecureTransportAuthenticationScheme

System.ServiceModel.HostNameComparisonMode SecureTransportHostNameComparisonMode

System.Net.AuthenticationSchemes SecureTransportProxyAuthenticationScheme

System.ServiceModel.TransferMode SecureTransportTransferMode

bool SecureTransportManualAddressing

long SecureTransportMaxBufferPoolSize

long SecureTransportMaxReceivedMessageSize

bool SecureTransportAllowCookies

bool SecureTransportBypassProxyOnLocal

bool SecureTransportKeepAliveEnabled

int SecureTransportMaxBufferSize

string SecureTransportRealm

bool SecureTransportUnsafeConnectionNtlmAuthentication

bool SecureTransportUseDefaultWebProxy

bool SecureTransportRequireClientCertificate

HostNameComparisonMode FedBindingHostNameComparisonMode

WSMessageEncoding FedBindingMessageEncoding

Encoding FedBindingTextEncoding

SecurityAlgorithmSuite FedBindingSecurityMessageAlgorithmSuite

SecurityKeyType FedBindingSecurityMessageIssuedKeyType

bool FedBindingSecurityMessageNegotiateServiceCredential

int FedBindingCloseTimeout

int FedBindingOpenTimeout

int FedBindingReceiveTimeout

int FedBindingSendTimeout

bool FedBindingBypassProxyOnLocal

bool FedBindingTransactionFlow

long FedBindingMaxBufferPoolSize

long FedBindingMaxReceivedMessageSize

bool FedBindingUseDefaultWebProxy

int FedBindingReaderQuotasMaxDepth

int FedBindingReaderQuotasMaxStringContentLength

int FedBindingReaderQuotasMaxArrayLength

int FedBindingReaderQuotasMaxBytesPerRead

int FedBindingReaderQuotasMaxNameTableCharCount

bool FedBindingReliableSessionOrdered

int FedBindingReliableSessionInactivityTimeout

bool FedBindingReliableSessionEnabled

И опять, все их можно изменять непосредственно в теге элемента управления на странице ASPX layouts. Например, вот так можно задать свойство FedBindingUseDefaultWebProxy:

<AzWcf:WcfDataControl runat="server" id="wcf" WcfUrl="https://azurewcf.vbtoys.com/Customers.svc" OutputType="Page" MethodName="GetAllCustomersHtml" FedBindingUseDefaultWebProxy="true" />

 

Свойства использования

Другие свойства элемента управления предназначены для управления его использованием. Несмотря на то, что список этих свойств довольно внушителен, имейте в виду, что они в основном предназначены для повышения гибкости использования, в простых случаях вам потребуется установить только одно или два свойства или же задать их в веб-части, которая описывается в четвертой части этой серии публикаций. Далее приводится список всех свойств с краткими описаниями каждого.

string WcfUrl — URL-адрес конечной точки службы WCF, то есть https://azurewcf.vbtoys.com/Customers.svc.

string MethodName — имя метода, который должен вызываться при запросе к странице. Может использоваться для задания вызываемого по умолчанию метода. Кроме того, свойству AllowQueryStringOverride можно задать значение false, в результате чего на странице будет использоваться ТОЛЬКО метод MethodName, заданный в теге control. Это свойство можно задать в строке запроса с помощью веб-части набора CASI Kit.

string MethodParams — список значений параметров, разделенных точкой с запятой, которые нужно передать в вызов метода. Они должны быть указаны в том же порядке, в котором указаны в подписи метода. Как объясняется во второй записи блога этой серии, параметры фактически поддерживают только простые типы данных, такие как string, bool, int и datetime. Если в качестве параметров метода нужно передать более сложные объекты, следует использовать строковый параметр и десериализовать такой объект в XML-код перед вызовом метода, а затем внутри своего приложения WCF сериализовать эту строку обратно в экземпляр объекта. При передаче параметра в виде строки запроса помните, что ее длина ограничена максимальной длиной строки запроса, поддерживаемой используемым браузером и службами IIS. Это свойство можно задать в строке запроса с помощью веб-части набора CASI Kit.

object WcfClientProxy — объект, с помощью которого фактически выполняется вызов приложения WCF. В нем нужно настроить поддержку передачи маркера пользователя в вызове. Именно поэтому в самом конце кода конфигурации для вашего пользовательского элемента управления в переопределении метода ExecuteRequest этому прокси-объекту присваивается значение прокси приложения-службы, в котором задано использование учетных данных текущего клиента.

string QueryResultsString — это свойство содержит строковое представление результатов, возвращаемых вызовом метода. Если метод WCF возвращает значение простого типа данных, например bool, int, string или datetime, то значением этого свойства является возвращаемое значение ToString(). Если метод WCF возвращает пользовательский класс, то когда базовый класс получает возвращаемое значение, он десериализует его в строку, предоставляя XML-код данных.

object QueryResultsObject — это свойство содержит представление результатов, возвращаемых вызовом метода, в виде объекта. Оно полезно при программном обращении к элементу управления. Например, если элемент управления используется для получения данных с целью их сохранения в кэше ASP.NET или использования в задании таймера SharePoint, в свойстве QueryResultsObject будет находиться именно то значение, которое возвращает вызов метода WCF. Если оно представляет собой пользовательский класс, то достаточно привести результаты в этом свойстве к нужному типу класса.

DataOutputType OutputType — свойство OutputType является перечислением, которое может иметь одно из четырех значений: Page, ServerCache, Both или None. Если элемент управления используется на странице layouts и результаты будут отображаться с помощью веб-части, то значением OutputType должно быть Page или Both. Если нужно получить данные и сохранить их в кэше ASP.NET, то следует использовать значение ServerCache или Both. ПРИМЕЧАНИЕ. При сохранении результатов в кэше сохраняется ТОЛЬКО QueryResultsObject. Очевидным образом значение Both задает отображение данных и их сохранение в кэше ASP.NET. Если элемент управления используется программным способом, например в задании таймера SharePoint, этому свойству можно задать значение None, поскольку QueryResultsString или QueryResultsObject будут считываться после вызова метода ExecuteRequest. Это свойство можно задать в строке запроса с помощью веб-части набора CASI Kit.

string ServerCacheName — если значением OutputType является ServerCache или Both, то свойству ServerCacheName нужно задать непустое строковое значение, в противном случае будет вызвано исключение. Этот ключ будет использоваться для сохранения результатов в кэше ASP.NET. Например, если свойству ServerCacheName задать значение “MyFooProperty”, то после вызова метода ExecuteRequest можно получить объект, возвращенный приложением WCF, указав ссылку на HttpContext.Current.Cache["MyFooProperty"]. Это свойство можно задать в строке запроса с помощью веб-части набора CASI Kit.

int ServerCacheTime — время хранения элемента, добавленного в кэш ASP.NET, в минутах. Если свойство OutputType имеет значение ServerCache или Both, этому свойству необходимо задать ненулевое значение, в противном случае будет вызвано исключение. Это свойство можно задать в строке запроса с помощью веб-части набора CASI Kit.

bool DecodeResults — это свойство предоставляется на случай, если приложение WCF возвращает результаты, обработанные методом HtmlEncoded. Если это свойство имеет значение true, то к результатам будет применен метод HtmlDecoding. В большинстве случаев использовать его необязательно. Это свойство можно задать в строке запроса с помощью веб-части набора CASI Kit.

string SharePointClaimsSiteUrl — это свойство предоставляется в основном для сценариев, в которых элемент управления создается программно вне HTTP-запроса, например в задании таймера SharePoint. По умолчанию, когда запрос направляется из веб-части, базовый класс использует URL-адрес текущего сайта для подключения к конечной точке службы SharePoint STS с целью предоставления маркера пользователя в вызов WCF. Однако если элемент управления создан программно и при этом отсутствует HTTP-контекст, этому свойству можно присвоить значение URL-адреса сайта SharePoint с поддержкой утверждений, и для доступа к службе SharePoint STS будет использоваться данный сайт. Таким образом, например, нельзя задавать это свойство в теге элемента управления на странице layouts, поскольку при вызове этой страницы всегда имеется HTTP-контекст.

bool AllowQueryStringOverride — это свойство позволяет администратору блокировать тег элемента управления на странице layouts. Если свойство AllowQueryStringOverride имеет значение false, то все значения переопределения в строке запроса, которые передаются из веб-части набора CASI Kit, будут игнорироваться.

string AccessDeniedMessage — это сообщение об ошибке отказа в доступе, которое должно отображаться в веб-части набора CASI Kit, если для некоторого метода пользователю отказано в доступе. Например, как описывается во второй записи блога этой серии, поскольку маркер пользователя передается вместе с вызовом WCF, любой из этих методов можно дополнить требованием PrincipalPermission, например “пользователь должен входить в группу менеджеров по продажам”. Если пользователь не соответствует требованию PrincipalPermission, то вызов WCF завершится ошибкой отказа в доступе. В этом случае в веб-части будет показано заданное сообщение AccessDeniedMessage. Обратите внимание, что в этом сообщении можно использовать расширенное форматирование, включая полужирный шрифт или красный цвет, с помощью HTML-тегов (например, <font color='red'>Нет доступа, обратитесь к администратору</font>). Это свойство можно задать в строке запроса с помощью веб-части набора CASI Kit.

string TimeoutMessage — это сообщение, которое выводится в веб-части набора CASI Kit при возникновении ошибки превышения времени ожидания в процессе выполнения вызова метода WCF. В нем также можно использовать расширенное форматирование, включая полужирный шрифт, красный цвет шрифта и т. д. Это свойство можно задать в строке запроса с помощью веб-части набора CASI Kit.

Все. Эта запись блога получилась очень ДЛИННОЙ, но, вероятно, она будет самой длинной в серии, поскольку именно здесь описывается основное назначение набора CASI Kit. В следующей записи блога я расскажу о веб-части набора CASI Kit для отображения данных из приложения WCF с помощью пользовательского элемента управления и страницы layouts, которые были созданы на данном этапе.

К этой записи блога также прилагается ZIP-файл с моим образцом проекта Visual Studio 2010, который включает сборку для базового класса набора CASI Kit, мой пользовательский элемент управления, наследующий от базового класса набора CASI Kit, и мою страницу layouts.

Это локализованная запись блога. Исходная статья находится по адресу: The Claims, Azure and SharePoint Integration Toolkit Part 3