Сеансы WCF с wsHttpBinding и без безопасности windows
Мне нужно создать службу WCF, которая размещена в IIS, использует транспорт http и удерживает состояние в памяти сервера. Хотя я знаю, что службы с состоянием не являются хорошей идеей, это последнее ограничение необходимо для работы службы с устаревшим клиентом.
моей первой мыслью было asp.net ' s сеанс для хранения значений. Я активировал asp.net режим совместимости в моей службе, который дал мне доступ к HttpContext, но значения, которые были помещены в объект сеанса, были не сохраняется в памяти. Я предполагаю, что это было потому, что http-модуль, который обрабатывает состояние сеанса, был неправильно настроен, но когда я искал ответ, я наткнулся на сеансы WCF и подумал, что было бы лучше их использовать.
однако сеансы WCF кажутся тем, что под документом и размещают странный набор предварительных запросов на службе, и я не смог найти конфигурацию, которая соответствует моим потребностям: должна быть размещена в IIS, должна использовать транспорт http или https и не может ответить на проверка подлинности windows, поскольку клиент и сервер не будут частью одного домена. Я пытаюсь сделать это с помощью wsHttpBinding, я слышал, что сеансы WCF требуют либо безопасности, либо надежного сообщения, но: - Использование стандартной привязки и когда серверы не являются частью того же домена, происходит сбой с исключением "SecurityNegotiationException вызывающий не был аутентифицирован службой". Это довольно логично, поскольку он использовал windows безопасность.
Если я отключу security complete, он завершится с ошибкой "контракт требует сеанса, но привязка "WSHttpBinding" не поддерживает его или не настроена должным образом для его поддержки."
Если при отключении безопасности я включаю надежное сообщение, я получаю исключение " ошибка проверки привязки, потому что WSHttpBinding не поддерживает надежные сеансы над безопасностью транспорта (HTTPS). Не может быть фабрики каналов или хоста службы открытый. Используйте message security для безопасного надежного обмена сообщениями через HTTP."
Я попытался включить безопасность транспортного уровня, но это, похоже, не имеет никакого значения для генерируемой ошибки
есть ли какая-либо конфигурация, которая может работать для меня? Или мне просто вернуться к плану использования asp.net сеансы?
2 ответов
вы можете иметь информацию о сеансе WCF в памяти довольно простым способом. Чтобы исключить любые возможные внешние влияния в моих Инструкциях, я предполагаю, что вы начинаете с совершенно нового проекта:
- создайте новый проект Библиотеки служб WCF. Этот проект уже будет содержать службу с
WSHttpBiding
связывание предварительно. -
перейдите к сервисному контракту (IService1.cs) и измените атрибут ServiceContract на следующий:
[ServiceContract(SessionMode = SessionMode.Required)]
-
перейдите к имплиментации службы (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), и предотвращает возможные проблемы параллелизма при доступе только к данным из класса обслуживания (и внешних потокобезопасных расположений).
EDIT: по умолчанию WSHttpBinding
разрешает только сеансы безопасности. Но он также поддерживает надежные сеансы, которые позволяют устанавливать сеансы без включенной безопасности. Следующая конфигурация привязки отключает безопасность и включает надежные сеансы:
<wsHttpBinding>
<binding name="wsHttpBindingConfiguration">
<security mode="None" />
<reliableSession enabled="true" />
</binding>
</wsHttpBinding>
IMO это то, что происходит, когда вы используете технологию с плохой абстракцией по HTTP, как WCF. Тот факт, что веб-службы WCF теоретически могут размещаться без HTTP (т. е. через NET TCP, MSMQ и т. д.) , Просто затрудняет использование встроенных функций HTTP без входа в configuration hell и запуска игры "угадайте правильную конфигурацию методом проб и ошибок", где вы пытаетесь каждую возможную перестановку конфигурации, пока не найдете правильный, который работает!
в конечном счете, если вы не можете использовать WCF и должны были реализовать веб-службу с нуля, вы просто установите cookie, когда клиент успешно прошел аутентификацию. Затем с каждым запросом клиента просто возьмите информацию о сеансе, на которую ссылается этот файл cookie.
одно из возможных решений, если вы должны использовать WCF-взять управление сеансами в свои руки (это то, что я делаю, когда я недоволен усилиями, необходимыми, чтобы заставить что-то работать) и явное свойство "Session" для всех ваших веб-служб, требующих сеанса/аутентификации (обычно guid, созданный при аутентификации). Поэтому для каждого последующего запроса вы используете guid для регидратации информации сеанса, связанной с этим клиентом.
Если вы заинтересованы в опробовании различных фреймворков веб-служб, я поддерживаю Open Source Web Services Framework это позволяет вам создавать конфигурации-бесплатные, сухие, тестируемые веб-службы, где (без каких-либо требуется настройка) каждая создаваемая веб-служба автоматически доступна через конечные точки REST XML, JSON, JSV, SOAP 1.1, SOAP 1.2. Эффективно он позволяет получить доступ к той же веб-службе через HTTP GET url для остальных клиентов и легкой отладки, а также конечных точек SOAP (популярный выбор, все еще санкционированный некоторыми предприятиями). The Привет, Мир учебник должен дать вам хороший обзор некоторых его функций и того, как он работает.