The ‘Access-Control-Allow-Origin’ header contains multiple values


i’m trying to send get request to api like it’s a login url

var url = "****&alias=****&login=****&password=****"
$.get(url, function(data) {

i’m getting this in my console this error

XMLHttpRequest cannot load****&alias=****&login=****&password=****. 
The 'Access-Control-Allow-Origin' header contains multiple values ', *', but only one is allowed. 
Origin '' is therefore not allowed access.

i’m trying to see questions here to solve it but i didn’t get what i need to change, this is annoying actually.

The ‘Access-Control-Allow-Origin’ header contains multiple values

this solved by web.congif

By the way i’m using CHROME BROWSER any help i appreciate.

UPDATE response headers:

Access-Control-Allow-Headers:origin, x-requested-with, Content-Type, accept, Token
Access-Control-Allow-Methods:GET, HEAD, POST, PUT, DELETE, TRACE, OPTIONS
Date:Thu, 02 Jun 2016 16:41:18 GMT
Set-Cookie:JSESSIONID=51FEE1A1206B9B481DD3EEA4167A9256; Path=/gptp

Request Headers:

Accept:application/json, text/javascript, */*; q=0.01
Accept-Encoding:gzip, deflate, sdch
User-Agent:Mozilla/5.0 (Windows NT 10.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36

You are attempting to do Cross-origin resource sharing (CORS) which is a mechanism that allows restricted resources on a web page to be requested from another domain outside the domain from which the resource originated. (such as accessing fonts or JSON files).

Browsers restrict your access to resources from other origins as of Same-origin policy as a security measure for internet users.

To get around this issue you have to options:

  1. allow CORS on the domain (but there is are security concerns, more description about it here:

Enable CORS on the server to be able to access other domains through. this can be done by adding the following headers to responses:

Access-Control-Allow-Origin: Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, Accept
  1. if you are not granted resource sharing with that domain, you are allowed to use JSONP for read only operations (JSONP is inherently read-only)

JSONP wraps a JSON object in a callback, which technically makes the request a non-restricted resource (a script tag) hence can be shared across domains.

it can be done via vanilla js by adding a script tag onto the page.

function process(data) {
    // do stuff with JSON

var script = document.createElement('script');
script.src = '//domainURL?callback=process'


or you can use jquery to achieve the same:

$.ajax({enter code here
    url: "",
    jsonp: "callback",
    dataType: "jsonp",
    data: {
        q: "select title,abstract,url from where query=\"cat\"",
        format: "json"
    success: function( response ) {
        console.log( response ); // server response

jquery documentation:


If you set “Full” CORS (with OPTION pre-request) on in nginx by add ‘access-control-allow-origin *’ and independently you add that header (for Simple CORS – without OPTION pre-request) to each response in SERVER (eg. php):

header('Access-Control-Allow-Origin', "*");

Then you will get this problem. Solution: remove code which add this header in server if already you add this header in your nginx config 🙂

I found this advice here


Why does my JavaScript get a “No ‘Access-Control-Allow-Origin’ header is present on the requested resource” error when Postman does not?


I am trying to do authorization using JavaScript by connecting to the RESTful API built in Flask. However, when I make the request, I get the following error:

XMLHttpRequest cannot load http://myApiUrl/login. No ‘Access-Control-Allow-Origin’ header is present on the requested resource. Origin ‘null’ is therefore not allowed access.

I know that the API or remote resource must set the header, but why did it work when I made the request via the Chrome extension Postman?

This is the request code:

    type: "POST",
    dataType: 'text',
    url: api,
    username: 'user',
    password: 'pass',
    crossDomain : true,
    xhrFields: {
        withCredentials: true
    .done(function( data ) {
    .fail( function(xhr, textStatus, errorThrown) {

If I understood it right you are doing an XMLHttpRequest to a different domain than your page is on. So the browser is blocking it as it usually allows a request in the same origin for security reasons. You need to do something different when you want to do a cross-domain request. A tutorial about how to achieve that is Using CORS.

When you are using postman they are not restricted by this policy. Quoted from Cross-Origin XMLHttpRequest:

Regular web pages can use the XMLHttpRequest object to send and receive data from remote servers, but they’re limited by the same origin policy. Extensions aren’t so limited. An extension can talk to remote servers outside of its origin, as long as it first requests cross-origin permissions.


For C# web services – webapi

Please add the following code in your web.config file under <system.webServer> tag. This will work.

        <add name="Access-Control-Allow-Origin" value="*" />

Please make sure you are not doing any mistake in the Ajax call.


    url: '',
    headers: {
        'Content-Type': 'application/x-www-form-urlencoded'
    type: "POST", /* or type:"GET" or type:"PUT" */
    dataType: "json",
    data: {
    success: function (result) {
    error: function () {

Angular 4 issue, please refer to How to fix Angular 4 API call issues.


How to retrieve output parameter from stored procedure in Entity Framework


How to get output parameter in stored procedure from Entity Framework(CSEFOutputParameter)


This sample demonstrates how to use ObjectParameter instance to get the value of output parameter in Entity Framework.

Building the Sample

  1. Start Visual Studio 2012 and select File > Open > Project/Solution.
  2. Go to the directory in which you download the sample. Go to the directory named for   the sample, and double-click the Microsoft Visual Studio Solution (.sln) file.
  3. Attach the database file EFDemoDB.mdf under the folder _External_Dependencies to your SQL Server 2008R2 database instance.
  4. Modify the connection string in the App.config according to your SQL Server 2008R2 database instance name.
  5. Press F7 or use Build > Build Solution to build the sample.

Running the Sample

  1. Right click the solution and built it.
  2. Press F5 to run the project, a console window will appear.


3.Follow the prompt to input person information.

Using the Code

Stored Procedure

ALTER PROCEDURE [dbo].[InsertPerson]    
@Name varchar(50),    
@Description varchar(200),      
@ID int OUT    
INSERT INTO Person(Name,Description) VALUES(@Name,@Description)    

The code below demonstrates how to get the value of output parameter.

// Create a ObjectParameter instance to retrieve output parameter from stored procedure 
ObjectParameter Output = new ObjectParameter("ID", typeof(Int32)); 
context.InsertPerson(Name, Description, Output);   

Console.Write("ID: {0}", Output.Value); 

Model binding JSON POSTs in ASP.NET Core


I was catching up on the latest ASP.NET Community Standup the other day when a question popped up about Model Binding that I hadn’t previously picked up on (you can see the question around 46:30). It pointed out that in ASP.NET Core (the new name for ASP.NET 5), you can no longer simply post JSON data to an MVC controller and have it bound automatically, which you could previously do in ASP.NET 4/MVC 5.

In this post, I am going to show what to do if you are converting a project to ASP.NET Core and you discover your JSON POSTs aren’t working. I’ll demonstrate the differences between MVC 5 model binding and MVC Core model binding, highlighting the differences between the two, and how to setup your controllers for your project, depending on the data you expect.

TL;DR: Add the [FromBody] attribute to the parameter in your ASP.NET Core controller action

Where did my data go?

Imagine you have created a shiny new ASP.NET core project which you are using to rewrite an existing ASP.NET 4 app (only for sensible reasons of course!) You copy and paste your old WebApi controller in to your .NET Core Controller, clean up the namespaces, test out the GET action and all seems to be working well.

Note: In ASP.NET 4, although the MVC and WebApi pipelines behave very similarly, they are completely separate. Therefore you have separate ApiController and Controller classes for WebApi and Mvc respectively (and all the associated namespace confusion). In ASP.NET Core, the pipelines have all been merged and there is only the single Controller class.

As your GET request is working, you know the majority of your pipeline, for example routing, is probably configured correctly. You even submit a test form, which sends a POST to the controller and receives the JSON values it sent back. All looking good.

Posting x-www-url-formencoded content to ASP.NET Core controller

As the final piece of the puzzle, you test sending an AJAX POST with the data as JSON, and it all falls apart – you receive a 200 OK, but all the properties on your object are empty. But why?

Posting JSON content to ASP.NET Core controller

What is Model Binding?

Before we can go into details of what is happening here, we need to have a basic understanding of model binding. Model binding is the process whereby the MVC or WebApi pipeline takes the raw HTTP request and converts that into the arguments for an action method invocation on a controller.

So for example, consider the following WebApi controller and Person class:

public class PersonController : ApiController  
    public Person Index(Person person)
        return person;

public class Person  
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public int Age { get; set; }

We can see that there is a single action method on the controller, a POST action, which takes a single parameter – an instance of the Person class. The controller then just echoes that object out, back to the response.

So where does the Person parameter come from? Model binding to the rescue! There are a number of different places the model binders can look for data in order to hydrate the person object. The model binders are highly extensible, and allow custom implementations, but common bindings include:

  • Route values – navigating to a route such as {controller}/{action}/{id} will allow binding to an idparameter
  • Querystrings – If you have passed variables as querystring parameters such as ?FirstName=Andrew, then the FirstName parameter can be bound.
  • Body – If you send data in the body of the post, this can be bound to the Person object
  • Header – You can also bind to HTTP header values, though this is less common.

So you can see there are a number of ways to send data to the server and have the model binder automatically create the correct method parameter for you. Some require explcit configuration, while others you get for free. For example Route values and querystring parameters are always bound, and for complex types (i.e. not primitives like string or int) the body is also bound.

It is important to note that if the model binders fail to bind the parameters for some reason, they will not throw an error, instead you will receive a default object, with none of the properties set, which is the behaviour we showed earlier.

How it works in ASP.NET 4

To play with what’s going on here I created two projects, one using ASP.NET 4 and the other using the latest ASP.NET Core (so very nearly RC2). You can find them on github here and here.

In the ASP.NET WebApi project, there is a simple controller which takes a Person object and simply returns the object back as I showed in the previous section.

On a simple web page, we then make POSTs (using jQuery for convenience), sending requests either x-www-form-urlencoded (as you would get from a normal form POST) or as JSON.

 //form encoded data
 var dataType = 'application/x-www-form-urlencoded; charset=utf-8';
 var data = $('form').serialize();

 //JSON data
 var dataType = 'application/json; charset=utf-8';
 var data = {
    FirstName: 'Andrew',
    LastName: 'Lock',
    Age: 31

 console.log('Submitting form...');
    type: 'POST',
    url: '/Person/Index',
    dataType: 'json',
    contentType: dataType,
    data: data,
    success: function(result) {
        console.log('Data received: ');

This will create an HTTP request for the form encoded POST similar to (elided for brevity):

POST /api/Person/UnProtected HTTP/1.1  
Host: localhost:5000  
Accept: application/json, text/javascript, */*; q=0.01  
Content-Type: application/x-www-form-urlencoded; charset=UTF-8


and for the JSON post:

POST /api/Person/UnProtected HTTP/1.1  
Host: localhost:5000  
Accept: application/json, text/javascript, */*; q=0.01  
Content-Type: application/json; charset=UTF-8


Sending these two POSTs elicits the following console response:

Image of successful posts to ASP.NET 4 controller

In both cases the controller has bound to the body of the HTTP request, and the parameters we sent were returned back to us, without us having to do anything declarative. The model binders do all the magic for us. Note that although I’ve been working with a WebApi controller, the MVC controller model binders behave the same in this example, and would bind both POSTs.

The new way in ASP.NET Core

So, moving on to ASP.NET Core, we create a similar controller, using the same Person class as a parameter as before:

public class PersonController : Controller  
    public IActionResult Index(Person person){
        return Json(person);   

Using the same HTTP requests as previously, we see the following console output, where the x-www-url-formencoded POST is bound correctly, but the JSON POST is not.

x-www-url-formencoded post is bound correctly but JSON post is not

In order to bind the JSON correctly in ASP.NET Core, you must modify your action to include the attribute [FromBody] on the parameter. This tells the framework to use the content-type header of the request to decide which of the configured IInputFormatters to use for model binding.

By default, when you call AddMvc() in Startup.cs, a JSON formatterJsonInputFormatter, is automatically configured, but you can add additional formatters if you need to, for example to bind XML to an object.

With that in mind, our new controller looks as follows:

public class PersonController : Controller  
    public IActionResult Index([FromBody] Person person){
        return Json(person);   

And our JSON POST now works like magic again!

JSON binding working correctly with FromBody attribute

So just always include [FromBody]?

So if you were thinking you can just always use [FromBody] in your methods, hold your horses. Lets see what happens when you hit your new endpoint with a x-www-url-formencoded request:

Unsupported Media type using x-www-url-formencoded with FromBody attribute

Oh dear. In this case, we have specifically told the ModelBinder to bind the
body of the post, which is FirstName=Andrew&LastName=Lock&Age=31, using an IInputFormatter. Unfortunately, the JSON formatter is the only formatter we have and that doesn’t match our content type, so we get a 415 error response.

In order to specifically bind to the form parameters we can either remove the FromBody attribute or add the alternative FromForm attribute, both of which will allow our form data to be bound but again will prevent the JSON binding correctly.

But what if I need to bind both data types?

In some cases you may need to be able to bind both types of data to an action. In that case, you’re a little bit stuck, as it won’t be possible to have the same end point receive two different sets of data.

Instead you will need to create two different action methods which can specifically bind the data you need to send, and then delegate the processing call to a common method:

public class PersonController : Controller  
    //This action at /Person/Index can bind form data 
    public IActionResult Index(Person person){
        return DoSomething(person);   

    //This action at /Person/IndexFromBody can bind JSON 
    public IActionResult IndexFromBody([FromBody] Person person){
        return DoSomething(person);   

    private IActionResult DoSomething(Person person){
        // do something with the person here
        // ...

        return Json(person);

You may find it inconvenient to have to use two different routes for essentially the same action. Unfortunately, routes are obviously mapped to actions before model binding has occurred, so the model binder cannot be used as a discriminator. If you try to map the two above actions to the same route you will get an error saying Request matched multiple actions resulting in ambiguity. It may be possible to create a custom route to call the appropriate action based on header values, but in all likelihood that will just be more effort than it’s worth!

Why the change?

So why has this all changed? Wasn’t it simpler and easier the old way? Well, maybe, though there are a number of gotchas to watch out for, particularly when POSTing primitive types.

The main reason, according to Damian Edwards at the community standup, is for security reasons, in particular cross-site request forgery (CSRF) prevention. I will do a later post on anti-CSRF in ASP.NET Core, but in essence, when model binding can occur from multiple different sources, as it did in ASP.NET 4, the resulting stack is not secure by default. I confess I haven’t got my head around exactly why that is yet or how it could be exploited, but I presume it is related to identifying your anti-CSRF FormToken when you are getting your data from multiple sources.


In short, if your model binding isn’t working properly, make sure it’s trying to bind from the right part of your request and you have registered the appropriate formatters. If it’s JSON binding you’re doing, adding [FromBody] to your parameters should do the trick!


Web API 2 GET by query parameter


You always have to register a route in WebApi for your controller actions, this can be done with attribute routing or with conventions based routing.

Parameters passed in the query string for GET request don’t really have to be specified explicitly in either of the routing configuration methods.

The parameters you specify on your controller action get mapped to parameters sent in the query string of a GET request.

If you are using the default WebApi conventions based setup where the routes are configured something like this:

var config = new HttpConfiguration();
// some other config setup for web api
// route config
    name: "API Default",
    routeTemplate: "api/{controller}/{id}",
    defaults: new { id = RouteParameter.Optional }

Then a controller like this will work for you:

public class UsersController : ApiController {
   // this maps to a get requests to:
   // domain/api/users
   // and domain/api/users?id=someid
   // and domain/api/users?mail=somemail
   // and domain/api/users?pw=somepw
   // and domain/api/users?mail=somemail&amp;pw=somepw
   // and domain/api/users with any query string really
   public IHttpActionResult Get(string mail, string pw) {
      // should probably check mail and pw for empty strings and nulls
      var users = SomeStaticExampleService.FindByMailAndPw(mail, pw);
      return this.Json(users);

Alternatively you can use attribute routing and then call your controllers and action methods whatever you want. Configure your routes like this:

var config = new HttpConfiguration();
// some other config setup for web api
// route config

Then you can create a controller like this:

public class FooController : ApiController {
   // this maps to a get requests to:
   // domain/users
   // and domain/users?id=someid
   // and domain/users?mail=somemail
   // and domain/users?pw=somepw
   // and domain/users with any query string really
   public IHttpActionResult Bar(string mail, string pw) {
      // should probably check mail and pw for empty strings and nulls
      var users = SomeStaticExampleService.FindByMailAndPw(mail, pw);
      return this.Json(users);

Bear in mind though that with Attribute Routing you have to be careful not to create clashing routes otherwise WebApi won’t know which controller and action to route a request to when a route is mapped to multiple action methods.

I’ve used this.Json in these examples to return a http response with json content to match your wcf ResponseFormat = WebMessageFormat.Json. But you can of course just return a CLR type:

   public IEnumerable&lt;MyUser&gt; Bar(string mail, string pw) {
      // should probably check mail and pw for empty strings and nulls
      var users = SomeStaticExampleService.FindByMailAndPw(mail, pw);
      return users;

and let WebApi’s content negotiation handle the response message content type.


Error posting JSON to Web API 2 : The request entity’s media type ‘text/plain’ is not supported for this resource


You were sending the content-type of application/json in the body, rather than as a header. So your POST request was defaulting to text/plain. The RestClient extension has a separate place to enter the header.

If you ever have a question about what’s being sent over the wire, check the Network tab in your browser’s developer tools, or use a tool such as Fiddler to see the network traffic.

Inside POSTMAN, you only need to change the setting to application/json. Refer image below.



How do I enable HTTP PUT and DELETE for ASP.NET MVC in IIS?


Go to Handler Mappings in your IIS Manager. Find ExtensionlessUrlHandler-Integrated-4.0, double click it. Click Request Restrictions… button and on Verbs tab, add both DELETE and PUT. enter image description here

EDIT: Possible WebDav Publisher issue

You’ve mention on a deleted post you were running on a 2008 server right? Try removing webDav role, or disable it from your site config: on system.webServer -> modules section, remove WebDAVModule module:

    <remove name="WebDAVModule" />
    <remove name="WebDAV" />