WCF 用户名身份验证和故障契约

发布于 2024-08-02 22:36:17 字数 804 浏览 12 评论 0原文

我有一个 WCF 服务,配置为通过 System.IdentityModel.Selectors.UserNamePasswordValidator 类的重写 Validate() 方法使用自定义用户名验证。

契约的所有方法都已使用FaultContractAttribute 进行修饰,以将自定义SOAP 错误指定为可返回。

当抛出FaultException时,其中T是FaultContractAttribute中指定的类型,一切都按预期运行,并且我在响应XML中得到了自定义错误。

但是,如果我尝试抛出FaultException在用户名身份验证类的重写 Validate() 方法中,我收到一个通用 SOAP 错误,原因如下:

“此错误的创建者未指定原因。”

但是,如果我更改代码以抛出一般 SOAP 错误,如下所示:

抛出新的FaultException(“身份验证失败。”);

我至少会得到“身份验证失败”。在原因要素中。

我的问题是:

  • 为什么FaultException没有出现?如果在 Validate() 中抛出异常,那么它们的处理方式与在服务实现中的异常相同吗?
  • Validate() 方法中抛出的异常是否可能符合契约方法上指定的FaultContractAttribute?

非常感谢任何帮助。我自己的猜测是,身份验证是在消息与合约的任何方法关联之前进行的,因此与FaultContractAttribute 无关,但任何确认这一点并提供解决方法的文章都将非常有用。

塔利

I have a WCF service configured to use custom UserName validation via the overriden Validate() method of the System.IdentityModel.Selectors.UserNamePasswordValidator class.

All methods of the contract have been decorated with the FaultContractAttribute to specify a custom SOAP fault as being returnable.

When throwing FaultException<T>, where T is the type specified in the FaultContractAttribute, everything behaves as expected and I get the custom fault in the response XML.

However, if I try and throw FaultException<T> in the overriden Validate() method of the username authentication class, I get a generic SOAP fault with the following reason:

"The creator of this fault did not specify a Reason."

However, if I change the code to throw the general SOAP fault as in:


throw new FaultException("Authentication failed.");

I will at least get "Authentication failed." in the reason element.

My questions are:

  • Why aren't the FaultException<T> exceptions treated the same if they're thrown in the Validate() as they are within the service implementation?
  • Is it possible to have exceptions thrown in the Validate() method conform to the FaultContractAttribute specified on the contract methods?

Any help greatly appreciated. My own guess is that the authentication comes before the message is associated with any method of the contract, and therefore, is not associated with the FaultContractAttribute, but any article confirming this and giving a workaround would be very useful.

Tali

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

顾北清歌寒 2024-08-09 22:36:17

这有点烦人,但我通过这样做解决了这个问题:

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

另外包含该消息意味着您不会收到愚蠢的“未指定原因”消息。

It's a bit annoying but I got round it by doing this:

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

Including the message additionally means that you don't get the silly "did not specify a reason" message.

萌能量女王 2024-08-09 22:36:17

问题在于自定义验证代码在任何特定 OperationContract 的上下文之外运行,因此没有 FaultContract 可供 WCF 处理。所以简短的答案是否定的,您无法从自定义验证器中抛出异常来遵守 FaultContract

您在这里有几个选择。我更喜欢的是抛出非泛型 FaultException 并提供预先确定的 FaultCode;这样我的 catch 块就可以区分合同错误和“管道”错误。请注意,从自定义验证器引发的任何异常都应作为 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.
}

The problem is that the custom validation code is running outside of the context of any specific OperationContract, so there is no FaultContract is place for WCF to handle. So the short answer is no, you cannot get the exceptions thrown from your custom validator to honor the FaultContract.

You have a few options here. The one I prefer is to throw the non-generic FaultException and provide a pre-determined FaultCode; this way my catch blocks can differentiate contract faults from "plumbing" faults. Note that any exception you throw from a custom validator should come back as a MessageSecurityException, as shown below:

// 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.
}
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文