WCF, поставщик членства ASP.NET и услуга аутентификации
Вы должны настроить время простоя и настроить пул соединений, я рекомендую c3p0
http://www.mkyong.com/hibernate/how-to-configure-the -c3p0-connection-pool-in-hibernate /
Также вы можете здесь описать, как настраивать параметры и как они работают
Что такое требуемые настройки C3P0 для спящего режима, чтобы избежать Deadlock
В некоторых случаях, когда вы «изменяете» свое приложение извне, эти ошибки могут возникать
6 ответов
Я наконец нашел способ сделать эту работу. Для аутентификации я использую" Услуга аутентификации WCF ". Когда аутентификация сервиса попытается установить cookie аутентификации. Я должен вытащить этот cookie из ответа и добавить его к любому другому запросу, выполненному к другим веб-сервисам на той же машине. Код, чтобы сделать, который похож на это:
var authService = new AuthService.AuthenticationServiceClient();
var diveService = new DiveLogService.DiveLogServiceClient();
string cookieHeader = "";
using (OperationContextScope scope = new OperationContextScope(authService.InnerChannel))
{
HttpRequestMessageProperty requestProperty = new HttpRequestMessageProperty();
OperationContext.Current.OutgoingMessageProperties[HttpRequestMessageProperty.Name] = requestProperty;
bool isGood = authService.Login("jonas", "jonas", string.Empty, true);
MessageProperties properties = OperationContext.Current.IncomingMessageProperties;
HttpResponseMessageProperty responseProperty = (HttpResponseMessageProperty)properties[HttpResponseMessageProperty.Name];
cookieHeader = responseProperty.Headers[HttpResponseHeader.SetCookie];
}
using (OperationContextScope scope = new OperationContextScope(diveService.InnerChannel))
{
HttpRequestMessageProperty httpRequest = new HttpRequestMessageProperty();
OperationContext.Current.OutgoingMessageProperties.Add(HttpRequestMessageProperty.Name, httpRequest);
httpRequest.Headers.Add(HttpRequestHeader.Cookie, cookieHeader);
var res = diveService.GetDives();
}
, Поскольку Вы видите, что у меня есть два сервисных клиента, один fo услуга аутентификации, и один для сервиса, который я на самом деле собираюсь использовать. Первый блок назовет метод Входа в систему и захватит cookie аутентификации из ответа. Второй блок добавит заголовок к запросу прежде, чем назвать сервисный метод "GetDives".
я не доволен этим кодом вообще, и я думаю, что лучшая альтернатива могла бы быть должна использовать "веб-Ссылку" в земельном участке "Сервисной Ссылки" и использовать.NET 2,0 стека вместо этого.
Веб-сервисы, такие как созданные WCF, часто лучше всего используются способом "не сохраняющим состояние", таким образом, каждый вызов к веб-сервису начинает заново. Это упрощает серверный код, поскольку нет никакой потребности иметь "сессию", которая вспоминает состояние клиента. Это также упрощает клиентский код, поскольку нет никакой потребности содержать билеты, cookie или другие geegaws, которые принимают что-то о состоянии сервера.
Создание двух сервисов в пути, который описан, представляет с сохранением информации. Клиент или "аутентифицируется" или "не аутентифицируемый", и MyDataService.svc должен выяснить который.
, Как это происходит, я нашел, что WCF работает хорошо, когда поставщик членства используется для аутентификации каждый вызов к сервису. Так, в данном примере Вы хотели бы добавить аутентификацию поставщика членства gubbins к сервисной конфигурации для MyDataService и не иметь отдельную услугу аутентификации вообще.
для получения дополнительной информации, см. статью MSDN здесь .
[то, Что очень привлекательно об этом для меня, поскольку я ленив, то, что это совершенно декларативно. Я просто рассеиваю правильные записи конфигурации для своего MembershipProvider в app.config для приложения и! бинго! все вызовы к каждому контракту в сервисе аутентифицируются.]
справедливо отметить, что это не будет особенно быстрым. При использовании SQL Server для базы данных аутентификации, у Вас будет по крайней мере один, возможно, два вызова хранимой процедуры на служебный вызов. Во многих случаях (специально для HTTP-связываний) издержки самого служебного вызова будут больше; в противном случае рассмотрите прокрутку Вашей собственной реализации поставщика членства, это кэширует запросы аутентификации.
Одна вещь, которую это не делает , дает, способность обеспечить возможность "входа в систему". Для этого можно или обеспечить (аутентифицируемый!) контракт на обслуживание, который ничего не делает (кроме повышения отказ, если аутентификация перестала работать), или можно использовать сервис поставщика членства, как описано в исходной статье, на которую ссылаются.
Возможно скрыть большую часть дополнительного кода позади пользовательского инспектора сообщения & поведение, таким образом, Вы не должны заботиться о переделывании OperationContextScope сами.
я попытаюсь дразнить что-то позже и отправить его Вам.
- larsw
Необходимо смотреть на объект CookieContainer в Системе. Сеть. Этот объект позволяет клиенту небраузера держаться за cookie. Это - то, что моя команда использовала прошлый раз, когда мы столкнулись с той проблемой.
Вот краткая статья о том, как пойти об использовании ее. Там могут быть лучшие, но это должно запустить Вас.
Мы пошли путем не сохраняющим состояние для нашего текущего набора сервисов WCF и приложения Silverlight 2. Возможно заставить Silverlight 2 работать с сервисами, связанными с безопасностью TransportWithMessageCredential, хотя требуется некоторый пользовательский код в системе защиты на стороне Silverlight. Результат - то, что любое приложение может получить доступ к сервисам просто путем установки Имени пользователя и Пароля в заголовках сообщения. Это может быть сделано однажды в пользовательской реализации IRequestChannel так, чтобы разработчики никогда не волновались об устанавливании самих значений. Хотя WCF действительно имеет простой способ к разработчикам сделать это, которому я верю, serviceProxy. Безопасность. Имя пользователя и serviceProxy. Безопасность. Пароль или что-то одинаково простое.
Я написал это некоторое время назад, когда использовал службы клиентских приложений для аутентификации в отношении веб-служб. Он использует инспектор сообщений для вставки заголовка cookie. Есть текстовый файл с документацией и демонстрационный проект. Хотя это не совсем то, что вы делаете, это довольно близко. Вы можете скачать его с здесь .
На клиенте измените тег
Теперь приложение должно сохранять файл cookie и использовать Это. Вы заметите, что IsLoggedIn теперь возвращает true после входа в систему - он возвращает false, если вы не разрешаете файлы cookie.