How to handle exceptions on WCF Custom Authentication?

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

When the validation fails, I throw a SecurityTokenValidationException.

The way it was built, in my client, I'm receiving a CommuinicationException with the message: The remote server returned an error: NotFound.

What's the best way to开发者_StackOverflow handle this exception in the client side?

My validation code:

if (user == null || (Environment.TickCount - user.LastCall) > 300000)
{
    if (!LoginUser.ValidateUser(userName, password))
    {
        throw new SecurityTokenValidationException("Usuário/Senha inválido");
    }
}

Throwing an exception from a service will (I believe) fault the channel, and the client will receive a a non-descriptive message. This is by design - WCF "hides" exceptions on the service side.

To return an error to the client so the client can handle it you should use a FaultException. You can specify a FaultContract for the operation and that will be returned to the client.

Do a search on error handling in WCF and you should get plenty of examples. I'm short on time or I'd add some, but hopefully this will get you pointed in the right direction.

Edited to add

Change the line

throw new SecurityTokenValidationException("Usuário/Senha inválido");

to

throw new FaultException("Usuário/Senha inválido");

Throwing the FaultException will prevent the communication from being faulted - the client can then receive the exception, know it was due to validation failure, and decide what to do from that point (retry, prompt the user to reenter credentials, etc).

This is a very simple change and the example is to illustrate the point. The links I posted below will give more detailed information.

How are you identifying the user object that you check the last call on? Are you using a LINQ Single call? if so this will throw an exception if the user is not found and so the server will abort authentication at that point rather than with the SecurityTokenValidationException which I think would give you the behavior you are seeing