2009-08-24 5 views
6

У меня есть служба WCF, настроенная для использования пользовательской проверки UserName с помощью метода переопределения Validate() класса System.IdentityModel.Selectors.UserNamePasswordValidator.WCF UserName проверки подлинности и сбоя

Все методы контракта были украшены атрибутом FaultContractAttribute, чтобы указать пользовательскую ошибку SOAP как возвращаемую.

При бросании FaultException <T>, где T - тип, указанный в атрибуте FaultContractAttribute, все ведет себя так, как ожидалось, и я получаю пользовательскую ошибку в ответе XML.

Однако, если я пытаюсь бросить FaultException <T> в переопределен метода Validate() класса аутентификации имени пользователя, я получаю общую ошибку SOAP со следующей причиной:

«Создатель этой ошибки сделал не указывать причины ».

Однако, если изменить код, чтобы бросить общую ошибку SOAP, как в:

throw new FaultException("Authentication failed.");

Я по крайней мере, получить «Ошибка аутентификации». в элементе причины.

Мои вопросы:

  • Почему же FaultException <T> исключения не относились так же, если они выброшены в Validate(), поскольку они находятся в рамках реализации услуг?
  • Возможно ли, что исключения, введенные в метод Validate(), соответствуют атрибуту FaultContractAttribute, указанному в методах контракта?

Любая помощь очень ценится. Моя собственная догадка заключается в том, что аутентификация возникает до того, как сообщение связано с каким-либо способом контракта, и поэтому не связано с FaultContractAttribute, но любая статья, подтверждающая это и дающая обходной путь, будет очень полезна.

Тали

+0

Спасибо за размещение этого вопроса. Любые решения? Я все еще ищу ответ в марте 2013 года. –

ответ

0

Это немного раздражает, но я обошел его, делая это:

 
SecurityTokenValidationException stve 
    = new SecurityTokenValidationException("Invalid username or password"); 
throw new FaultException<SecurityTokenValidationException>(stve, stve.Message); 

В том числе сообщения дополнительно означает, что вы не получите глупое «не уточнили причину» сообщение ,

0

Проблема заключается в том, что пользовательский код проверки работает вне контекста любого конкретного OperationContract, поэтому нет FaultContract - это место для обработки WCF. Таким образом, короткий ответ - нет, вы не можете получить исключения, сброшенные с вашего пользовательского валидатора, чтобы почтить FaultContract.

У вас здесь есть несколько вариантов. Тот, который я предпочитаю, заключается в том, чтобы выбросить не-общий FaultException и предоставить предварительно определенный FaultCode; таким образом, мои блоки блокировки могут дифференцировать дефекты контракта от «сантехнических» неисправностей. Обратите внимание, что любое исключение, вы бросаете из пользовательского валидатора должен вернуться в MessageSecurityException, как показано ниже:

// Custom Validator: 
public override void Validate(string userName, string password) 
{ 
    throw new FaultException(
    "Invalid username or password.", 
    new FaultCode("AUTHENTICATION_FAILURE")); 
} 

// Client Code: 
try 
{ 
    client.DoSomething(); 
} 
catch (MessageSecurityException ex) 
{ 
    var inner = ex.InnerException as FaultException; 
    if (inner != null && inner.Code.Name.Equals("AUTHENTICATION_FAILURE")) 
    { 
    // Security failure. 
    } 
} 
catch (FaultException<SomethingFault> ex) 
{ 
    // Exception from the method itself. 
} 
+0

Я пробовал вышеупомянутое, но я получаю нулевое значение, когда пытаюсь использовать ex.innerException как FaultException. Любая помощь будет оценена по достоинству. – vikasse

+0

Ну, какое исключение является внутренним исключением? Если это не ошибка, тогда ваша проблема не в обслуживании. –

+0

Я выбрал тип исключения Fault на сервере, но в клиенте он говорит, что внутреннее исключение имеет тип system.net.webexception, и у меня нет msg, который я выбрал из сервера. – vikasse

 Смежные вопросы

  • Нет связанных вопросов^_^