1

We have an WCF service, using webhttp binding. Users get authenticated, and then a method is called. In the method, we check a variety of settings associated with the user and some information specific to the request before knowing if the user is authorized to make the call.

Since this is WCF, I think I should be throwing a FaultException of some sort, but it's not clear if there is best practices.

My thoughts are that once I know what exception I will be throwing, I'd add a IErrorHandler which would set the headers correctly to 403.

Two questions: 1) Is there a standard FaultException for unauthorized requests? i.e. the equivalent of the http status code of 403? 2) Should I be able to handle the exceptions that I'll be throwing and change the response code to 403? Will I be able to pass through a custom error message? I've seen some posts that setting headers using the operation context in a catch does not get propagated to the client.

Ideally I'd be able to set the status to 403 with additional information like "You must be part of the administrators group to add a user"

bpeikes
  • 3,495
  • 9
  • 42
  • 80

3 Answers3

1

Because you're using webhttp binding, traditional WCF fault management is not pertinent here and it's better to use WebFaultException and WebFaultException<>.

Public string MyOperation()
   // Operation logic
   // ...   
   throw new WebFaultException<string>("You must be part of the administrators group to add a user", HttpStatusCode.Forbidden);
}

As you think, it's very important to use standard HTTP status codes when developping an HTTP (REST-like) service.

Cybermaxs
  • 24,378
  • 8
  • 83
  • 112
  • 1
    I hate the idea of taking a WCF service, which shouldn't be bound to the binding, and adding a WebFaultException. My thought was to throw some standard WCF unauthorized exception, and then handle it in a IErrorHandler which can be bound to the endpoint. That way the business logic code doesn't get bound to webHttpBindings. – bpeikes May 20 '14 at 13:44
0

It's been my experience that throwing fault exceptions, at least with wshttpbinding and basichttpbinding, can cause your web service to fail, so I don't recommend that approach.

If you want to send a message back to unauthorized users, just send an HTML response, setting the status to any one of the 400 responses that seem appropriate.

But from experience, fault exceptions, even if they're a controlled response to user actions and not from an actual processing error, will cause your web service to fail. I think they should be reserved genuine processing exceptions.

Brian
  • 3,653
  • 1
  • 22
  • 33
0

I went ahead and derived custom exceptions from FaultException, and then added an IErrorHandler to set the appropriate headers.

This seemed to be the best of both worlds. The code only throws exceptions derived from ones used in WCF, and all the handling specific to http binding is done via an IErrorHandler outside the business logic.

bpeikes
  • 3,495
  • 9
  • 42
  • 80