WCF-сессии с wsHttpBinding и без безопасности Windows

Мне нужно создать службу WCF, размещенную в IIS, в хранилищах серверов используется HTTP-транспорт и состояние удержания. Хотя Im знает, что службы с сохранением состояния не являются хорошей идеей, этот последний ограничитель необходим, чтобы сделать работу службы с унаследованным клиентом.

Моя первая мысль заключалась в сеансе asp.nets для хранения значений. Я активировал режим совместимости asp.net в своей службе, что дало мне доступ к HttpContext, но значения, которые были помещены в объект сеанса, не сохранялись в памяти. Я предполагаю, что это связано с тем, что модуль http, который обрабатывает состояние сеанса, был неправильно настроен, но когда я искал ответ, я наткнулся на сессии WCF и подумал, что лучше использовать их.

Однако сеансы WCF показывают, что задокументировано, и помещают странный набор предварительных требований в службу, и я не смог найти конфигурацию, которая соответствует моим потребностям: должна быть размещена в IIS, должна использовать http или https-транспорт и не отвечайте на проверку подлинности Windows, потому что клиент и сервер не будут частью одного домена. Я пытаюсь добиться этого, используя wsHttpBinding, я слышал, что сессии WCF требовали безопасности или надежного сообщения, но: - Используя стандартную привязку и когда серверы не являются частью одного и того же домена, он не работает с "исключением SecurityNegotiationException". Это довольно логично, поскольку он использует защиту Windows.

Если я отключу защиту, он завершится неудачей, когда "Контракт требует сеанса", но привязка "WSHttpBinding" не поддерживает его или не настроена должным образом для его поддержки ".
Если при отключении безопасности я включаю надежное сообщение, я получаю исключение. Ошибка проверки привязки, потому что WSHttpBinding не поддерживает надежные сеансы по безопасности транспорта (HTTPS). Канал factory или узел службы не может быть открыт Используйте защиту сообщений для безопасного надежного обмена сообщениями через HTTP.
Ive попытался включить безопасность транспортного уровня, но это, похоже, не имеет никакого отношения к генерируемой ошибке

Есть ли какая-нибудь конфигурация, которая может работать для меня? Или я должен просто вернуться к плану использования сессий asp.net?

Ответ 1

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

Создайте новый проект библиотеки WCF. Этот проект уже будет содержать службу с привязкой WSHttpBiding, предварительно сконфигурированной.
Перейдите к контракту на обслуживание (IService1.cs) и измените атрибут ServiceContract на следующее:
```
[ServiceContract(SessionMode = SessionMode.Required)]
```
Перейдите в службу implimentation (Service1.cs) и добавьте следующий атрибут ServiceBehavior в класс службы (Service1):
```
[ServiceBehavior(InstanceContextMode = InstanceContextMode.PerSession, ConcurrencyMode = ConcurrencyMode.Single)]
```

Добавить данные сеанса как члены класса службы (Service1):

public class Service1 : IService1
{
    ...

    private string UserFullName { get; set; }

    ...
}

Используйте члены для представления данных, относящихся к сеансу (не забудьте также добавить их к контракту на обслуживание, IService1):

public class Service1 : IService1
{
    ...

    public string Welcome(string fullName)
    {
        UserFullName = fullName ?? "Guest";
        return string.Format("Welcome back, {0}!", UserFullName);
    }

    public string Goodbye()
    {
        return string.Format("Come back soon, {0}!", UserFullName ?? "Guest");
    }

    ...
}

SessionMode.Required гарантирует, что ваши клиенты будут отслеживать сеанс.
InstanceContextMode.PerSession гарантирует, что для каждого сеанса создается экземпляр вашего класса обслуживания (Service1), чтобы вы могли сохранить в нем данные сеанса, и он будет существовать в памяти для нескольких вызовов в одном сеансе.
ConcurrencyMode.Single гарантирует, что только один поток может входить в каждый экземпляр класса обслуживания (Service1) и предотвращает возможные проблемы concurrency, если вы получаете доступ только к данным из класса обслуживания (и к внешним потокобезопасным местоположениям).

EDIT: По умолчанию WSHttpBinding разрешает сеансы безопасности. Но он также поддерживает надежные сеансы, которые позволяют устанавливать сеансы без обеспечения безопасности. Следующая конфигурация привязки отключает безопасность и обеспечивает надежные сеансы:

<wsHttpBinding>
    <binding name="wsHttpBindingConfiguration">
        <security mode="None" />
        <reliableSession enabled="true" />
    </binding>
</wsHttpBinding>

Ответ 2

IMO это то, что происходит, когда вы используете технологию с плохой абстракцией по HTTP, например WCF. Тот факт, что веб-сервисы WCF теоретически могут размещаться без HTTP (т.е. Через NET TCP, MSMQ и т.д.), Просто затрудняет использование встроенных функций HTTP без ввода конфигурации ада и запускает игру "угадать правильную конфигурацию путем проб и ошибок", где вы пытаетесь выполнить все возможные перестановки конфигурации, пока не найдете правильный, который работает!

В конечном счете, если вы не смогли использовать WCF и должны были выполнить веб-сервис с нуля, вы просто установили бы cookie, когда клиент успешно прошел аутентификацию. Затем каждый клиентский запрос просто захватывает информацию сеанса, на которую ссылается этот файл cookie.

Одним из возможных решений, если вам пришлось использовать WCF, - это взять управление сеансами в свои руки (это то, что я делаю, когда я недоволен усилиями, необходимыми для работы) и имеет явное свойство Session все ваши веб-службы, для которых требуется сеанс/аутентификация (обычно это правило, генерируемое при аутентификации). Поэтому для каждого последующего запроса вы используете руководство для регидратации информации сеанса, связанной с этим клиентом.

Если вы заинтересованы в проверке различных рамок веб-сервисов, я поддерживаю Open Web Web Framework Framework, которая позволяет вам создавать безконфиденциальные, DRY, проверяемые веб-службы, где (без какой-либо конфигурации) каждый создаваемый веб-сервис автоматически доступен через REST XML, JSON, JSV, SOAP 1.1, SOAP 1.2. Фактически он позволяет вам получить доступ к одному и тому же веб-сервису с помощью HTTP GET url для клиентов REST-ful и легкой отладки, а также конечных точек SOAP (популярный выбор, который по-прежнему регулируется некоторыми предприятиями). Учебное пособие Hello World должно дать вам хороший обзор некоторых его функций и того, как это работает.