Implementing CORS support in WCF

Article
05/14/2012

The code for this post can be downloaded from the MSDN Code Gallery.

A pair of popular posts which I did a couple months back was to show how one can implement CORS (Cross-Origin Resource Sharing) in the net ASP.NET Web API framework. This week I found a couple of posts in the WCF forums from a user who wanted to make cross-domain calls to a WCF REST service. They were trying to use JSONP, but it didn’t work because the request needed to be made using non-GET verbs. So let’s try to implement the same support which we did fairly easily in the new API in WCF.

Cross-domain calls

A quick recap about the problem: in order to prevent malicious sites to “stealing” cookies from good sites and using them to get access to protected resources (imagine going to a bad site, and scripts in that site accessing your online bank and transferring your money elsewhere), browsers block by default AJAX requests going to domains other than the one where the HTML page originated. This is good for security purposes, but it blocks some valid scenarios, such as mash-up applications which gather data from many sources. There are some alternatives to make this scenario work, including JSONP (JSON with Padding), or using a separate “proxy” service on the same domain as the page to route the requests to the destination server. But those approaches have limitations: JSONP only works for GET requests (since it uses the <script> element in the HTML DOM, and proxy services need to be deployed on many places and add another level of indirection (and point of failure) to the system.

CORS (Cross-Origin Resource Sharing) is a new specification which defines a set of headers which can be exchanged between the client and the server which allow the server to relax the cross-domain restrictions for all HTTP verbs, not only GET. Also, since CORS is implemented in the same XmlHttpRequest as “normal” AJAX calls (in Firefox 3.5 and above, Safari 4 and above, Chrome 3 and above, IE 10 and above – in IE8/9, the code needs to use the XDomainRequest object instead), the JavaScript code doesn’t need to worry about “un-padding” responses or adding dummy functions. The error handling is also improved with CORS, since services can use the full range of the HTTP response codes (instead of 200, which is required by JSONP) and the code also has access to the full response instead of only its body.

CORS operation

There are two types of requests in the CORS world, “normal” requests and preflight requests. Normal requests are the requests which the page would normally make to the service, with an additional header, “Origin”, which indicates the origin and the service can determine whether to allow cross-domain calls from that origin or not (via the “Access-Control-Allow-Origin” response header). “Safe” requests (GET and HEAD) only use that extra headers to work. The browser will add the Origin header to requests going to domains other than the one where the page originated, and if the service doesn’t allow that domain, then the call will fail.

“Unsafe” requests, such as POST, PUT or DELETE, can’t be done the same way. If the service isn’t CORS-aware, it would ignore the “Origin” header and accept the request, with possible side effects (e.g., deleting a record), and at the time the client gets the response, the browser could still “fail” the request, but the damage has already been done. What the browser does in those cases is to first send a preflight request, which is a HTTP OPTIONS request asking for permission to send the actual request. If the service answers that request allowing the call, only then the browser will send the user request to the service.

CORS in WCF

So let’s start with the “normal” requests. That’s actually fairly simple to implement – we can use an inspector to check the “Origin” header in the requests, and if it’s present (and we want to allow the cross-domain request) on the reply we add the “Access-Control-Allow-Origin” header. As usual, we’ll start with a simple example, and go from there. And to make the comparison between WCF and the version I wrote in ASP.NET Web API easier, let’s use the exact same contract as that one.

[ServiceContract]
public interface IValues
{
[WebGet(UriTemplate = "values", ResponseFormat = WebMessageFormat.Json)]
List<string> GetValues();
[WebGet(UriTemplate = "values/{id}", ResponseFormat = WebMessageFormat.Json)]
string GetValue(string id);
[WebInvoke(UriTemplate = "/values", Method = "POST", ResponseFormat = WebMessageFormat.Json)]
void AddValue(string value);
[WebInvoke(UriTemplate = "/values/{id}", Method = "DELETE", ResponseFormat = WebMessageFormat.Json)]
void DeleteValue(string id);
[WebInvoke(UriTemplate = "/values/{id}", Method = "PUT", ResponseFormat = WebMessageFormat.Json)]
string UpdateValue(string id, string value);
}

The implementation is exactly the same as in the Web API one, so I’ll leave it out. Now, we need one “tagging” attribute to indicate whether an operation can be called via cross-domain calls or not. We can use an empty operation behavior attribute, which will be easily accessible via the operation description later.

public class CorsEnabledAttribute : Attribute, IOperationBehavior
{
public void AddBindingParameters(OperationDescription operationDescription, BindingParameterCollection bindingParameters)
{
}
public void ApplyClientBehavior(OperationDescription operationDescription, ClientOperation clientOperation)
{
}
public void ApplyDispatchBehavior(OperationDescription operationDescription, DispatchOperation dispatchOperation)
{
}
public void Validate(OperationDescription operationDescription)
{
}
}

And by having the CorsEnabled attribute as a IOperationBehavior, it allows us to filter through he operations for which we should implement the CORS handshake in our endpoint behavior.

class EnableCorsEndpointBehavior : IEndpointBehavior
{
public void AddBindingParameters(ServiceEndpoint endpoint, BindingParameterCollection bindingParameters)
{
}
public void ApplyClientBehavior(ServiceEndpoint endpoint, ClientRuntime clientRuntime)
{
}
public void ApplyDispatchBehavior(ServiceEndpoint endpoint, EndpointDispatcher endpointDispatcher)
{
List<OperationDescription> corsEnabledOperations = endpoint.Contract.Operations
.Where(o => o.Behaviors.Find<CorsEnabledAttribute>() != null)
.ToList();
endpointDispatcher.DispatchRuntime.MessageInspectors.Add(new CorsEnabledMessageInspector(corsEnabledOperations));
}
public void Validate(ServiceEndpoint endpoint)
{
}
}

The inspector is divided in two parts: incoming requests and the verification whether the “Origin” header was sent and whether the operation for where the request is directed is one of those which are CORS-enabled. The first information we get via the HttpRequestMessageProperty property. The second one we could look at the request URI, but since the inspector is executed after the operation selector, that information is already available in the message properties via the WebHttpDispatchOperationSelector.HttpOperationNamePropertyName key. If those two conditions are met, then we return the value of the Origin header, which will be passed to the BeforeSendReply method of the inspector.

The second part, for the response, starts by looking at the correlation state returned by the AfterReceiveRequest method. If there is something, then the request had an Origin header, and we’ll use the HttpResponseMessageProperty on the reply message to send back the Access-Control-Allow-Origin method.

class CorsEnabledMessageInspector : IDispatchMessageInspector
{
private List<string> corsEnabledOperationNames;
public CorsEnabledMessageInspector(List<OperationDescription> corsEnabledOperations)
{
this.corsEnabledOperationNames = corsEnabledOperations.Select(o => o.Name).ToList();
}
public object AfterReceiveRequest(ref Message request, IClientChannel channel, InstanceContext instanceContext)
{
HttpRequestMessageProperty httpProp = (HttpRequestMessageProperty)request.Properties[HttpRequestMessageProperty.Name];
object operationName;
request.Properties.TryGetValue(WebHttpDispatchOperationSelector.HttpOperationNamePropertyName, out operationName);
if (httpProp != null && operationName != null && this.corsEnabledOperationNames.Contains((string)operationName))
{
string origin = httpProp.Headers[CorsConstants.Origin];
if (origin != null)
{
return origin;
}
}
return null;
}
public void BeforeSendReply(ref Message reply, object correlationState)
{
string origin = correlationState as string;
if (origin != null)
{
HttpResponseMessageProperty httpProp = null;
if (reply.Properties.ContainsKey(HttpResponseMessageProperty.Name))
{
httpProp = (HttpResponseMessageProperty)reply.Properties[HttpResponseMessageProperty.Name];
}
else
{
httpProp = new HttpResponseMessageProperty();
reply.Properties.Add(HttpResponseMessageProperty.Name, httpProp);
}
httpProp.Headers.Add(CorsConstants.AccessControlAllowOrigin, origin);
}
}
}

And now, by decorating the GET operations with [CorsEnabled] and adding the EnableCorsEndpointBehavior to the endpoint, those operations can now be called via cross-domain.

Implementing preflight requests

The first part was easy. For the second part, we need to intercept the requests with the OPTIONS verb, and return the response immediately, without going to the operation. And that’s probably one of the biggest features missing in the WCF extensions – the ability to bypass the rest of the WCF pipeline at a given point. The first option is to use a custom reply channel (which, with anything in the channel layer, is really hard to write). The other option is to use a custom operation invoker which can bypass the actual operation. But the invoker by itself doesn’t work – on the invoker call you don’t have a reference to either the incoming request (to look for CORS headers) or the outgoing response (to set the response headers). Also, in order for the invoker to be called for OPTIONS requests (instead of the actual request), we needed to also have an operation selector which will map requests for OPTIONS verb to the actual operation. And it would also need some way to not map multiple operations which have the same URI template (but different verbs) to different operations, since OPTIONS will be the common ground there. And we’d also need to change the formatter so that the response for the OPTIONS request would be an empty response instead of the actual result of the operation… In short, not simple at all.

Another option, which I got the idea from the post about how to add dynamic operations from Zufilqar’s blog, is to not change the existing operations, but instead add new ones to handle the OPTIONS requests. Since I always try to avoid channels programming whenever possible, this seemed the best option given all the problems of using a custom invoker for the existing operations. Those operations actually need a custom invoker, but by making them operations with untyped messages (Message in, Message out), we don’t need a custom formatter, and we can access to the HTTP headers via the message properties as well.

To make this scenario simpler to use, let’s create a custom service host (and service host factory) to wrap the logic for creating the new operations. The service host will use as the contract type either the service type itself (if it is decorated with ServiceContractAttribute), or one interface the service type implements (and the interface is decorated with ServiceContractAttribute). More complex logic can be added if needed, but for this scenario, this is enough.

When the service host is being opened, we’ll add the single endpoint, find all the operations which are decorated with the CorsEnabled attribute, and for those, add a corresponding operation which deals with the preflight requests.

class CorsEnabledServiceHostFactory : ServiceHostFactory
{
protected override ServiceHost CreateServiceHost(Type serviceType, Uri[] baseAddresses)
{
return new CorsEnabledServiceHost(serviceType, baseAddresses);
}
}
class CorsEnabledServiceHost : ServiceHost
{
Type contractType;
public CorsEnabledServiceHost(Type serviceType, Uri[] baseAddresses)
: base(serviceType, baseAddresses)
{
this.contractType = GetContractType(serviceType);
}
protected override void OnOpening()
{
ServiceEndpoint endpoint = this.AddServiceEndpoint(this.contractType, new WebHttpBinding(), "");
List<OperationDescription> corsEnabledOperations = endpoint.Contract.Operations
.Where(o => o.Behaviors.Find<CorsEnabledAttribute>() != null)
.ToList();
AddPreflightOperationSelectors(endpoint, corsEnabledOperations);
endpoint.Behaviors.Add(new WebHttpBehavior());
endpoint.Behaviors.Add(new EnableCorsEndpointBehavior());
base.OnOpening();
}
private Type GetContractType(Type serviceType)
{
if (HasServiceContract(serviceType))
{
return serviceType;
}
Type[] possibleContractTypes = serviceType.GetInterfaces()
.Where(i => HasServiceContract(i))
.ToArray();
switch (possibleContractTypes.Length)
{
case 0:
throw new InvalidOperationException("Service type " + serviceType.FullName + " does not implement any interface decorated with the ServiceContractAttribute.");
case 1:
return possibleContractTypes[0];
default:
throw new InvalidOperationException("Service type " + serviceType.FullName + " implements multiple interfaces decorated with the ServiceContractAttribute, not supported by this factory.");
}
}
private static bool HasServiceContract(Type type)
{
return Attribute.IsDefined(type, typeof(ServiceContractAttribute), false);
}
}

In order to add the preflight operations, we first iterate over all the CORS-enabled operations which need to respond to the preflight request (GET requests don’t need those). For those operations, we first get the URI template for the operation, and normalize it (remove query string parameters, and remove the parameter lists replacing them with wildcards) so that two operations with similar URI templates (e.g., [WebInvoke(Method = “POST”, UriTemplate = “/products/{param1}?x={param2}”)] and [WebInvoke(Method = “DELETE”, UriTemplate = “/products/{id}”)]) will have only one new operation for the “/products/*” URI. If there is already an OPTIONS operation for the normalized URI we’ll add HTTP verb to it, otherwise we’ll create a new operation to handle the OPTIONS request.

private void AddPreflightOperations(ServiceEndpoint endpoint, List<OperationDescription> corsOperations)
{
Dictionary<string, PreflightOperationBehavior> uriTemplates = new Dictionary<string, PreflightOperationBehavior>(StringComparer.OrdinalIgnoreCase);
foreach (var operation in corsOperations)
{
if (operation.Behaviors.Find<WebGetAttribute>() != null || operation.IsOneWay)
{
// no need to add preflight operation for GET requests, no support for 1-way messages
continue;
}
string originalUriTemplate;
WebInvokeAttribute originalWia = operation.Behaviors.Find<WebInvokeAttribute>();
if (originalWia != null && originalWia.UriTemplate != null)
{
originalUriTemplate = NormalizeTemplate(originalWia.UriTemplate);
}
else
{
originalUriTemplate = operation.Name;
}
string originalMethod = originalWia != null && originalWia.Method != null ? originalWia.Method : "POST";
if (uriTemplates.ContainsKey(originalUriTemplate))
{
// there is already an OPTIONS operation for this URI, we can reuse it
PreflightOperationBehavior operationBehavior = uriTemplates[originalUriTemplate];
operationBehavior.AddAllowedMethod(originalMethod);
}
else
{
ContractDescription contract = operation.DeclaringContract;
OperationDescription preflightOperation;
PreflightOperationBehavior preflightOperationBehavior;
CreatePreflightOperation(operation, originalUriTemplate, originalMethod, contract, out preflightOperation, out preflightOperationBehavior);
uriTemplates.Add(originalUriTemplate, preflightOperationBehavior);
contract.Operations.Add(preflightOperation);
}
}
}

Creating the preflight operation means creating a new operation description for the contract, adding two messages to it: an input message with a single body part of type Message, and an output message with a return value of the same type. We then use the same URI template as the original operation, and add a WebInvokeAttribute to the operation. We then add a DataContractSerializerOperationBehavior to the operation description, since it will give us a formatter which understands the (Message in, Message out) pattern. Finally, we add our custom operation behavior, which we’ll use to implement the operation invoker which will ultimately deal with the preflight request

private static void CreatePreflightOperation(OperationDescription operation, string originalUriTemplate, string originalMethod, ContractDescription contract, out OperationDescription preflightOperation, out PreflightOperationBehavior preflightOperationBehavior)
{
preflightOperation = new OperationDescription(operation.Name + CorsConstants.PreflightSuffix, contract);
MessageDescription inputMessage = new MessageDescription(operation.Messages[0].Action + CorsConstants.PreflightSuffix, MessageDirection.Input);
inputMessage.Body.Parts.Add(new MessagePartDescription("input", contract.Namespace) { Index = 0, Type = typeof(Message) });
preflightOperation.Messages.Add(inputMessage);
MessageDescription outputMessage = new MessageDescription(operation.Messages[1].Action + CorsConstants.PreflightSuffix, MessageDirection.Output);
outputMessage.Body.ReturnValue = new MessagePartDescription(preflightOperation.Name + "Return", contract.Namespace) { Type = typeof(Message) };
preflightOperation.Messages.Add(outputMessage);
WebInvokeAttribute wia = new WebInvokeAttribute();
wia.UriTemplate = originalUriTemplate;
wia.Method = "OPTIONS";
preflightOperation.Behaviors.Add(wia);
preflightOperation.Behaviors.Add(new DataContractSerializerOperationBehavior(preflightOperation));
preflightOperationBehavior = new PreflightOperationBehavior(preflightOperation);
preflightOperationBehavior.AddAllowedMethod(originalMethod);
preflightOperation.Behaviors.Add(preflightOperationBehavior);
}

Finally, the custom invoker. The implementation of the IOperationInvoker interface is fairly trivial: allocate 1 input, only work with synchronous operations. The Invoke calls the operation to handle the preflight request: take the incoming message HttpRequestMessageProperty property, get any CORS-specific headers, then create an empty reply message, and add to it a HttpResponseMessageProperty property with the appropriate headers.

class PreflightOperationInvoker : IOperationInvoker
{
private string replyAction;
List<string> allowedHttpMethods;
public PreflightOperationInvoker(string replyAction, List<string> allowedHttpMethods)
{
this.replyAction = replyAction;
this.allowedHttpMethods = allowedHttpMethods;
}
public object[] AllocateInputs()
{
return new object[1];
}
public object Invoke(object instance, object[] inputs, out object[] outputs)
{
Message input = (Message)inputs[0];
outputs = null;
return HandlePreflight(input);
}
public IAsyncResult InvokeBegin(object instance, object[] inputs, AsyncCallback callback, object state)
{
throw new NotSupportedException("Only synchronous invocation");
}
public object InvokeEnd(object instance, out object[] outputs, IAsyncResult result)
{
throw new NotSupportedException("Only synchronous invocation");
}
public bool IsSynchronous
{
get { return true; }
}
Message HandlePreflight(Message input)
{
HttpRequestMessageProperty httpRequest = (HttpRequestMessageProperty)input.Properties[HttpRequestMessageProperty.Name];
string origin = httpRequest.Headers[CorsConstants.Origin];
string requestMethod = httpRequest.Headers[CorsConstants.AccessControlRequestMethod];
string requestHeaders = httpRequest.Headers[CorsConstants.AccessControlRequestHeaders];
Message reply = Message.CreateMessage(MessageVersion.None, replyAction);
HttpResponseMessageProperty httpResponse = new HttpResponseMessageProperty();
reply.Properties.Add(HttpResponseMessageProperty.Name, httpResponse);
httpResponse.SuppressEntityBody = true;
httpResponse.StatusCode = HttpStatusCode.OK;
if (origin != null)
{
httpResponse.Headers.Add(CorsConstants.AccessControlAllowOrigin, origin);
}
if (requestMethod != null && this.allowedHttpMethods.Contains(requestMethod))
{
httpResponse.Headers.Add(CorsConstants.AccessControlAllowMethods, string.Join(",", this.allowedHttpMethods));
}
if (requestHeaders != null)
{
httpResponse.Headers.Add(CorsConstants.AccessControlAllowHeaders, requestHeaders);
}
return reply;
}
}

That’s it. We can now use the custom service host factory to webhost our service, and use a page in another web service to call our service – as long as the browser supports CORS (which means the latest Chrome and Firefox, and IE 10 and above). You can find the code for a sample page at the sample in the code gallery.

Final thoughts: WCF vs. ASP.NET Web APIs

This is a good example to compare the extensibility between WCF and the ASP.NET Web APIs. The implementation of this scenario took a lot more code (and a non-negligible number of extension points) to be done in WCF compared with a similar solution in Web API. This is a specific HTTP scenario, and for those cases, Web APIs will likely be easier. But what I tried to do (and did) was to show that it can be done in WCF, so if you have an investment in that technology, you don’t need to hurry to make the change (if you’re starting a new project, and the focus of the project is HTTP only and the Web, then Web API would be a logical choice).

[Code in this post]

Comments

Anonymous
May 14, 2012
Interesting Finds: May 15, 2012
Anonymous
June 13, 2012
Hi,Thanks for this, it explains a lot.However, after trying to implement it I found this exception in the logs:"A binding instance has already been associated to listen URI 'http://<mysite>/jsapi/Login/1.0.0/Auth.svc'. If two endpoints want to share the same ListenUri, they must also share the same binding object instance. The two conflicting endpoints were either specified in AddServiceEndpoint() calls, in a config file, or a combination of AddServiceEndpoint() and config."The web.config has the following: <system.serviceModel> <services> <service name="API.Login.Auth"> <endpoint name="apiEndPoint" contract="API.Login.IAuth" address="" binding="webHttpBinding" behaviorConfiguration="webHttpBehavior" /> </service>parent web.config has: <behaviors> <endpointBehaviors> <behavior name="webHttpBehavior"> <webHttp defaultBodyStyle="Bare" defaultOutgoingResponseFormat="Json" automaticFormatSelectionEnabled="false" /> </behavior> </endpointBehaviors> </behaviors>Is there some kind of double association of binding objects going on ? The error message seems to indicate the CORS support code above is adding something that I had already added and that the config needs to be adjusted accordingly.Any thoughts on what that config adjustment would need to be ? Thanks.
Anonymous
June 14, 2012
Rick, if you're defining endpoints using a service host factory (as I did on the example above), you shouldn't define them via config as well, otherwise you may end up with two endpoints trying to listen to the same address.
Anonymous
June 19, 2012
Does this work when the WCF service is https?
Anonymous
July 15, 2012
The comment has been removed
Anonymous
September 11, 2012
This works well with IE but it does not work in Firefox and Chrome. I have specified the headers for handling options for FF and Chrome in global.asax file.HttpContext.Current.Response.AddHeader("Access-Control-Allow-Origin", "http://localhost:16154"); if (HttpContext.Current.Request.HttpMethod == "OPTIONS") { //These headers are handling the "pre-flight" OPTIONS call sent by the browser HttpContext.Current.Response.AddHeader("Access-Control-Allow-Methods", "GET, POST"); HttpContext.Current.Response.AddHeader("Access-Control-Allow-Headers", "Origin, Content-Type, Accept"); HttpContext.Current.Response.AddHeader("Access-Control-Max-Age", "1728000"); HttpContext.Current.Response.End(); }Fiddler shows that the response is going through without any problem but Chrome and FF says that access is denied because of the same origin policy.Please advise...Thanks!!!
Anonymous
September 20, 2012
@PrashantI had the same issue, I got round it by sending CORS headers back when return data and not just when the OPTIONS request is received. It's not pretty but I haven't had time to make it more elegant, it works with Firefox and Chrome using a Javascript mobile client.public List<dtCustomer> GetCustomers(string SearchTerm) { try { // Check for browser pre-flight CORS request if (WebOperationContext.Current.IncomingRequest.Method == "OPTIONS") { AllowAccess(); return null; } // Stop an empty search returning everything, this is enforced on the mobile client but for other services services that connect if (SearchTerm == null) { AllowAccess(); return null; } using (DataAccessAdapter adapter = new DataAccessAdapter()) { LinqMetaData metaData = new LinqMetaData(adapter); var q = metaData.Customer.Where(f => f.Surname.StartsWith(SearchTerm)) .Select(dCustomers => new dtCustomerList { Forename = dCustomers.Forename, Surname = dCustomers.Surname, DOB = dCustomers.DOB }); AllowAccess(); return q.ToList() ; } } catch (Exception ex) { throw (ex); } } /// <summary> /// Set response header for browser CORS support /// </summary> /// <returns> /// </returns> private void AllowAccess() { WebOperationContext.Current.OutgoingResponse.Headers.Add("Access-Control-Allow-Origin", "http://Server:Port"); // * doesn't work WebOperationContext.Current.OutgoingResponse.Headers.Add("Access-Control-Allow-Methods", "GET"); WebOperationContext.Current.OutgoingResponse.Headers.Add("Access-Control-Allow-Methods", "POST"); WebOperationContext.Current.OutgoingResponse.Headers.Add("Access-Control-Allow-Headers", "Content-Type, Accept"); } }Service contract [OperationContract] [WebInvoke(Method = "*", RequestFormat = WebMessageFormat.Json, UriTemplate = "/GetCustomers", ResponseFormat = WebMessageFormat.Json)] List<dtCustomer> GetCustomers(string SearchTerm); [DataContract] public class dtCustomer { [DataMember] public string Forename { get; set; } [DataMember] public string Surname { get; set; } [DataMember] public string POST { get; set; } }This works with POST.Hope this is of some use.
Anonymous
October 15, 2012
Hi, I have implemented CORS successfully. But now, I need to pass a lot of data from the Service to Client Side. I know we can set <readerQuotas maxDepth="2147483647" maxStringContentLength="2147483647" maxArrayLength="2147483647" maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647" />.But I do not know where to set these values. Do I have to do it web.config like we always do or in any of the cs files that I downloaded to make CORS work.Please advise...Thanks!
Anonymous
October 16, 2012
The comment has been removed
Anonymous
January 20, 2013
Carlos -excellent article and thank you - I have implemented CORS successfully, but have have also implemented an authorizationmanager that inherits from ServiceAuthorizationManager. The function CheckAccessCore is hit and if the user is not authorised I would like to send a meaningful message back to the browser. What happens is that because I'm returning false from the checkaccesscore function...the CorsEnabledMessageInspector - "AfterReceiveRequest" method does not get hit and thus the browser receives the "Origin http://localhost:51106 is not allowed by Access-Control-Allow-Origin" message. - Any advice as to how to workaround this?Thanks in advance!
Anonymous
October 08, 2013
I am trying to acess https wcf web service hosted on different domain.I am getting following error:The HTTP method 'OPTIONS' of the incoming request (with URI 'https://serverName/Secure/Service.svc/GetName') is not allowed.Here is config details :<system.serviceModel> <bindings> <wsHttpBinding> <binding name="wsHttpBindingClient"> <security mode="Transport"/> </binding> </wsHttpBinding> <webHttpBinding> <binding name="webHttpBindingClient" closeTimeout="00:50:00" openTimeout="00:50:00" receiveTimeout="00:50:50" sendTimeout="00:50:00" allowCookies="false" bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard" maxBufferSize="2147483647" maxBufferPoolSize="2147483647" maxReceivedMessageSize="2147483647" transferMode="Buffered" useDefaultWebProxy="true" crossDomainScriptAccessEnabled="true"> <security mode="Transport"/> </binding> </webHttpBinding> </bindings> <services> <service behaviorConfiguration="ServiceBehaviour" name="Service"> <endpoint address="" behaviorConfiguration="EndpBehaviour" binding="webHttpBinding" bindingConfiguration="webHttpBindingClient" name="webHttpEndPointBinding" contract="IService"/> </service> </services> <behaviors> <serviceBehaviors> <behavior name="ServiceBehaviour"> <serviceMetadata httpsGetEnabled="true"/> <serviceDebug includeExceptionDetailInFaults="true"/> </behavior> </serviceBehaviors> <endpointBehaviors> <behavior name="EndpBehaviour"> <webHttp helpEnabled="true"/> </behavior> </endpointBehaviors> </behaviors> <service HostingEnvironment aspNetCompatibilityEnabled="true" multipleSiteBindingsEnabled="true"/> <standardEndpoints> <webHttpEndpoint> <standardEndpoint crossDomainScriptAccessEnabled="true"/> </webHttpEndpoint> <webScriptEndpoint> <standardEndpoint crossDomainScriptAccessEnabled="true"/> </webScriptEndpoint> </standardEndpoints> </system.serviceModel>Please advise....Thanks
Anonymous
October 22, 2013
Thank you for your contributions Carlos,How would one need to modify this implementation if the REST service is hosted in a Windows Service?Thanks
Anonymous
June 10, 2014
Hi,I have download your code and run. I have called the method from JavaScript like:var valuesAddress = "http://localhost:8080/Values"; $("#getAll").click(function () { $.ajax({ url: valuesAddress, type: "GET", success: function (result) { var text = ""; for (var i = 0; i < result.length; i++) { if (i > 0) text = text + ", "; text = text + result[i]; } $("#result").text(text); }, error: function (jqXHR, textStatus, errorThrown) { $("#result").text(textStatus); } }); });this run successfully but when I change the address like:var valuesAddress = "192.168.1.103/Values"; (IP Address instead of localhost)its retuning error and got following message:"Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://192.168.1.103:85/Values. This can be fixed by moving the resource to the same domain or enabling CORS" !!!What is the resolution?Thanks,Jahid
Anonymous
June 17, 2014
Carlos, thank you very much for this blog post! It was very helpful - for the first time I actually understand what CORS is supposed to be doing.
Anonymous
July 13, 2014
how to configure self hosted WCF with CORS?
Anonymous
July 17, 2014
To use it in a self-hosted project, you can just use the CorsEnabledServiceHost type and open it directly.
Anonymous
November 18, 2014
Perfect code! Thanks.
Anonymous
January 11, 2015
Hello @CarlosFigueira,  I tried the code provided by you but it's not working in Chrome and FF at all.I tried solution provided by @Taz also but it's not working,I am using visual studio 2012.
Anonymous
February 18, 2015
CarlosFigueira, I have been struggling with getting CORS enabled for a WCF Service. I want to know, if WebInvoke attribute is mandatory to be added OperationContract in the WCF Service? Can I get it working without it? Since, if I host the client and server on the same server, I could call the WCF Service in SOAP call from javascript. Of course, I build the SOAP xml but it works. Please help!!
Anonymous
July 13, 2015
When I use this in a cross domain configuration, the GET work fine, returns data but the POST fails with bad request. What am I doing wrong?

Partager via