This is another CORS question. I have a weird issue.
I have an old application. i have access to inetpub but not the source code (only dlls and web.config).
So, before i make any POST call, there is a preflight call that is happening and somehow , the server is now allowing options to happen.
How do i make this work with just web.config or iis changes?
interestingly, Get call works. only post doesnt work.
I have added the following in Web.config of the api
<add name="Access-Control-Allow-Origin" value="*" />
<add name="Access-Control-Allow-Methods" value="GET, POST, PUT, DELETE, OPTIONS" />
in my test application, when i try to call the api, i am sending the following in the request headers
OPTIONS http://OldWebApiurl HTTP/1.1
Host: http://Oldwebapi.host
Connection: keep-alive
Access-Control-Request-Method: POST
Origin: http://TestSite
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.87 Safari/537.36
Access-Control-Request-Headers: accept, content-type
Accept: */*
Referer: http://testsite/page
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8
How do i make this work with just web.config or iis changes?
I am afraid that this might not be possible with changes to those files only. For example if you are using ASP.NET Web API (which you seem to be using according to the tags used in your question) you might consult the following tutorial explaining the required changes you need to make to your source code in order to enable CORS.
So long story short, get the code of this web application from source control, add the config.EnableCors(); call to the bootstrapping section and decorate the controllers/actions that need to be accessible with CORS with the [EnableCors(...)] attribute. Then push back the changes you did in the source control, trigger a build and let the continuous delivery do the rest and deploy your changes to the target environment. Then you can enjoy CORS.
interestingly, Get call works. only post doesnt work.
That's perfectly normal, most common browsers simply do not make a pre-flight request for GET AJAX calls because those are considered safe - those are not supposed to modify any server side state so they are allowed.
Related
I am using React With Redux and I wrote a middleware that comes in handy when I do Ajax calls in Epics. For example, to do a GET request, I have this getJSON function.
import {ajax, AjaxResponse} from "rxjs/ajax";
const getJSON = (url: string, headers?: Object): Observable<AjaxResponse> =>
ajax({
method: "GET",
url,
responseType: "json",
headers,
withCredentials: true
});
Everything seem to work fine except that Ajax does not set the headers that contains the access token.
When I step through the code, the headers object looks like this,
{
Authorization: "Bearer ey-SOME-ACCESS-TOKEN"
}
As expected... But when I look through the network calls, it does not contain the specified header with its value.
Parsed:
Accept: */*
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Access-Control-Request-Headers: authorization
Access-Control-Request-Method: GET
Connection: keep-alive
Host: localhost:1337
Origin: http://localhost:3000
Source:
OPTIONS /api/test HTTP/1.1
Host: localhost:1337
Connection: keep-alive
Access-Control-Request-Method: GET
Origin: http://localhost:3000
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36
Access-Control-Request-Headers: authorization
Accept: */*
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
NOTE: Please don't mark this as duplicate. I know there are similar questions on SO, but none of them seem to work for me.
After 3 days of pulling my hairs and banging my head on the walls, I finally figure out what is the problem, but still not sure why/how. Apparently due to CORS, there is always OPTION request is made before the actual POST or GET request. Which I already knew and kinda make sense. What does not make sense to me is why the heck it does not contain the headers. If anyone can explain this to me will be eligible for the bounty on this question.
I had to made changes in my back-end to handle OPTION requests, and it seems to work for now. I can't spend more time of this.
Not sure if it's late enough, but might be useful for future readers.
You should configure your server not to expect for authorization header in OPTIONS request.
The Bearer token is used for the POST/GET/DELETE/... confirmation of identity. The OPTIONS is just a preflight to see if the current HOST is allowed to get the data back.
It's important to say that browsers most of the time remove the custom headers from the OPTIONS request, moving them into the Access-Control-Request-Headers (it's happening in your case).
Please, take a look on the official documentation here:
https://www.w3.org/TR/cors/#cross-origin-request-with-preflight-0
There are a lot of questions on this subject, but I still can't seem to resolve my issue.
I have a game that I'm trying to get working with HTML 5 in Chrome. Link here.
The game is written using libgdx and I'm posting json data from my app engine hosted back end. I've done quite a bit of reading and I think I understand the issue with cross domain access, I also think I understand how to resolve it but can't.
The full error is
XMLHttpRequest cannot load http://1-1-51.wordbuzzweb.appspot.com/Login. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://wordbuzzhtml5.appspot.com' is therefore not allowed access.
As you can see, this says No 'Access-Control-Allow-Origin' header is present on the requested resource.. But if I look at the headers for the requested resource, they are as follows.
Date: Thu, 18 Jun 2015 21:59:34 GMT
Content-Encoding: gzip
Server: Google Frontend
Vary: Accept-Encoding
Access-Control-Allow-Methods: GET, POST
Content-Type: application/json
Access-Control-Allow-Origin: *
Alternate-Protocol: 80:quic,p=0
Cache-Control: private
Access-Control-Allow-Headers: Content-Type
Content-Length: 127
As you can see, there is an Access-Control-Allow-Origin header included.
If someone could please tell me what I'm doing wrong, that'd be appreciated.
The request header is as follows using the POST method.
Host: 192.168.254.1:8081
Pragma: no-cache
Cache-Control: no-cache
Origin: http://localhost:8080/
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.52 Safari/537.36
Accept: */*
Referer: http://localhost:8080/html/
Accept-Language: en-GB,en;q=0.8
Content-Length: 25
Content-Type: application/json
Since you are getting some headers back in the response, that's a good indication that the request IS reaching the server, however, the fact that it isn't hitting your server route points to the problem being the request being made doesn't match any of your routes. The request is likely an OPTIONS request rather than a POST request, which commonly happens when you make a CORS request from the browser that isn't a "simple request".
The solution would be to either make it a "simple request", or to have your server respond to OPTIONS requests. It's far easier to just make your server respond to OPTIONS requests, because sometimes even "simple requests" still send OPTIONS requests.
I am developing an iOS application utilizing the Ionic framework with Cordova and have run into a bit of a snag in my dev cycle. While running on my local dev web server, any RESTful call happening from the $http service is failing with a 401 Not Authorized error even though I am passing the Authorization header. Interestingly enough, the call works fine once I build the app and deploy onto the iOS Emulator.
FWIW, the api calls are to an Atlassian Confluence api.
CORS doesn't seem to be the issue as that has been configured, tested and working on non-authenticated calls.
Here is the very basic call that is failing within the browser but working on the emulator when using the same headers:
$http.defaults.headers.common['Accept'] = 'application/json';
$http.defaults.headers.common.Authorization = 'Basic xxxxxxxxxxxxxx';
$http.get('https://www.example.com/rest/prototype/1/search/site?type=blogpost&spaceKey=TESTSPACE&os_authType=basic')
.success(function (data, status) {
this.serviceData = data;
})
.error(function (data, status) {
console.log(status, data.result);
});
I am sending two custom headers: Accept: application/json and Authorization: Basic *** If I run the application in Chrome with the above service configuration, I see the following Request Headers. There is an added Access-Control-Request-Headers that mentions the Accept and Authorization headers, but those headers are not there. I see the following Request Headers going across the wire:
Accept:*/*
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en;q=0.8,nl;q=0.6
Access-Control-Request-Headers:accept, authorization <!---- This is added but there is no Authorization Header
Access-Control-Request-Method:GET
Cache-Control:no-cache
Connection:keep-alive
Host:www.example.com
Origin:https://local.example-client.com
Pragma:no-cache
Referer:https://local.example-client.com/
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.94 Safari/537.36
If I make the same call with the Authorization Header using the Advanced Rest Client Chrome extension, it works correctly.
Accept:application/json <!----------- This one is */* when called from $http
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en;q=0.8,nl;q=0.6
Authorization:Basic *** REMOVED *** <!----------- This one is missing when called from $http
Cache-Control:no-cache
Connection:keep-alive
Cookie: *** REMOVED ***
Host:www.example.com
Pragma:no-cache
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.94 Safari/537.36
One thing to note is that if I remove the Authorization header line (below), then the Accept header now appears:
//$http.defaults.headers.common.Authorization = 'Basic ************************';
Can anyone provide me any insight on what I may be missing here?
It's probably a problem with your CORS configuration. Authenticated requests require very specific configuration to work properly with CORS.
Make sure you're
Returning the Access-Control-Allow-Headers header to allow those headers
Returning the exact origin in Access-Control-Allow-Origin (not "*")
Setting withCredentials to true on the XHR (in Angular this can be set in the defaults just like the headers)
(I'm not entirely sure if the "Authorization" header is considered a "credential" if you set it by hand so the last two may or may not be required.)
The reason it works under Cordova is because Cordova doesn't implement origin restrictions for XHRs (they would be a bit pointless since your app doesn't have anything "local" to communicate with)
I've got a problem with an Ajax request in my web project. Most of the time it works just fine but sometimes there is simply no request from the client (it does not show in wireshark), FireBug just shows the request marked red.
Project looks like the following:
Java Backend with JSPs, Client is using the Firefox Browser
The request is done via prototypejs using the Ajax Updater function. I can debug the request preparation via firebug until the Ajax Update function fires the request but then no request is listed in my wireshark output (although all other request are listed just fine).
So I have a (sometimes) vanished Ajax request with no error and no clue where to look :( Any help would be much appreciated.
Request:
[...]/ajax/gruppe/loadTreeList.do?ajax=true&tstamp=645&context=GRUPPE&level=0&itemid=0
RequestHeader:
Accept text/javascript, text/html, application/xml, text/xml, /
Accept-Encoding gzip, deflate
Accept-Language de-de,de;q=0.8,en-us;q=0.5,en;q=0.3
Connection keep-alive
Cookie JSESSIONID=326D8AEAAFD254760CEC8D050734807E
Host localhost:8080
Referer [...]/domain/druck/gruppe.do
User-Agent Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20100101 Firefox/17.0
X-Prototype-Version 1.7.1
X-Requested-With XMLHttpRequest
There is no response.
I'm calling a server site on our internal server. This domain looks like this:
http://server.domain:12345/x.html
Now, with IE this works just fine, I'm getting the data. (My problem there is that IE caches the website after the first call forever, but never mind).
Now, if I'm trying to do exactly the same in Firefox, it won't work, the same in Google Chrome.
Firebug says this:
Answer-Header
Connection Keep-Alive
Content-Length 109
Content-Type text/html; charset=UTF-8
Keep-Alive timeout=5000
Server AbWeb Version SRSG 1.34
Set-Cookie sessionkey=80da7dfe-1c9c-4460-9592-3ce55cecb379
Request-Header
Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7
Accept-Encoding gzip, deflate
Accept-Language de-de,de;q=0.8,en-us;q=0.5,en;q=0.3
Connection keep-alive
Host server.domain:12345
Origin http://otherserver.domain
Referer http://otherserver.domain/test/
User-Agent Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20100101 Firefox/5.0
Chrome says this:
X XMLHttpRequest cannot load http://server.domain:12345/x.html. Origin http://otherservere.domain is not allowed by Access-Control-Allow-Origin.
server.domain:12345/x.html
X Failed to load resource
It seems you perform cross-domain JavaScript calls. The target server must set the Access-Control-Allow-Origin HTTP header. In your case the server http://server.domain must set a header like:
Access-Control-Allow-Origin: http://otherserver.domain
I do not know why it works for IE, it may have to do with your security domains as your just working in the intranet.
See another example:
Jquery form doesn't show submission message on web server but it shows submission message on local host