I'm trying to make a request to an API. It works fine in postman, but not from the browser directly. I can't find any difference between the 2 except https://developer.chrome.com/extensions/xhr. But I don't understand why that would be a problem because the Access-Control-Allow-Origin is set to *.
Postman Preview:
GET /facebook/v1/api/v2.2/123585981029762/insights/page_impressions?period=day HTTP/1.1
Host: api.url.com
Authorization: Basic {BASIC AUTH HASH}
X-KO-ACCOUNT: 123585981029762
Cache-Control: no-cache
Postman Response Headers:
Access-Control-Allow-Origin → *
Cache-Control → private, no-cache, no-store, must-revalidate
Connection → keep-alive
Content-Length → 1000
Content-Type → application/json; charset=UTF-8
Date → Tue, 17 Mar 2015 21:51:17 GMT
ETag → "32a4e4fc7aeb25536a634c302505fb02e7efe9fb"
Expires → Sat, 01 Jan 2000 00:00:00 GMT
Facebook-API-Version → v2.2
Pragma → no-cache
X-FB-Debug → Y0OdHMjYO5KUIqcnnVNK4eWLZRiPSKUnsOAHZ3sf33qjVSanI2AoK/jpY9OhZUffGfX31Wo6IgUWMoXkZHZRKQ==
X-FB-Rev → 1645171
Javascript from Browser:
xmlhttp= new XMLHttpRequest(); xmlhttp.open("GET","https://api.url.com/facebook/v1/api/v2.2/123585981029762/insights/page_impressions?period=day",true);
xmlhttp.setRequestHeader("authorization",'Basic {BASIC AUTH HASH}');
xmlhttp.setRequestHeader("X-KO-ACCOUNT",'12358376954762');
xmlhttp.send();
Error Message (In Chrome):
No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'null' is therefore not allowed access. The response had HTTP status code 401.
Also, Chrome is showing an OPTIONS method instead of GET. (I know that's normal with a cross-browser error) But the Remote Address IP is different.
ANY help would be greatly appreciated!
Chrome is very serious about this, and even by setting the headers to '*' it will not let you perform a cross-domain request.
What you can do for development mode is add " disable-web-security" in your chrome shortcut (after the path, by right-clicking -> properties). Then close every instance of Chrome in task manager, and double click the shortcut. You will get a warning that you started your browser in that mode, but then it should work for local testing purposes.
Related
i am trying to send request from my localhost to ebay servers , i am using postman to do so.
the request is the same request which this ebay page send http://www.fees.ebay.com/feeweb/feecalculator
when you press on the calculate fees button .
the request should return json response, but i am unable to do that in my postman , please find my request bellow:
how ebay can identify that my response is not ajax request ?
POST /feeweb/calculate HTTP/1.1
Host: www.fees.ebay.com
X-Requested-With: XMLHttpRequest
Referer: http://www.fees.ebay.com/feeweb/feecalculator
Accept: */*
Content-Type: application/x-www-form-urlencoded
Connection: keep-alive
Cache-Control: no-cache
Content-Type: application/x-www-form-urlencoded
locale=en_US_MAIN&catlevel1=2984&dp_cat-level1=Baby&catlevel2=20394&dp_cat-level2=athing+%26+Grooming&catlevel3=113814&dp_cat-level3=Bath+Tubs&saleformat=saleformat&site_id=0&RlogId=t6e%2560cpfg%253C%253Dsm%257Eaf%2560qba%252840%253A702-15753cbd4ec-0xfe&dp_store=Basic&rb-discount=0&freeshipping=1&value_pack_info=Value+Pack+is+Gallery+Plus%2C+Listing+Designer%2C+and+Subtitle+packaged+together+for+a+discount.&store=1&n_reserveprice=0&n_finalsaleprice=100&finalsaleprice=%24100.00
EDIT :
here is the response headers :
Content-Encoding → gzip
Content-Length → 2312
Content-Type → text/html;charset=UTF-8
Date → Sat, 22 Oct 2016 15:10:25 GMT
ETag → 6faadcbec2626c16a5eb2715c89aa47f
Last-Modified → Sat, 22 Oct 2016 14:31:15 GMT
Server → Apache-Coyote/1.1
response body:
From collectibles to cars, buy and sell all kinds of items on eBay
Page Not Responding
The eBay page or feature you are attempting to access is not responding.
Please try the options below:
Try to access the feature directly from the eBay Home Page, instead of using a bookmark.
Wait a few minutes and try to access the feature again.
If you have waited ten to fifteen minutes and you still can't access your page:
Check our Announcement Board to see if the feature is currently unavailable.
If what you are looking for is unavailable, you may still be able to access other parts of the site from the eBay Home page
I have an AWS S3 bucket with the following CORS policy:
<?xml version="1.0" encoding="UTF-8"?>
<CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
<CORSRule>
<AllowedOrigin>*</AllowedOrigin>
<AllowedMethod>GET</AllowedMethod>
<AllowedHeader>*</AllowedHeader>
<ExposeHeader>Access-Control-Allow-Origin</ExposeHeader>
</CORSRule>
</CORSConfiguration>
In my app, I load a page of images from the bucket. The images appear on the page as expected. When I click on one of the images to open it in the Adobe Creative SDK, the SDK fails to load the image because it is blocked by CORS. The SDK takes the url of the image and loads it via AJAX. The SDK has an option to enable CORS and appears to be sending the proper Origin header (See screenshot), however AWS is not including the Access-Control-Allow-Origin-Header, causing the image to be blocked by CORS.
I've scoured every question on here about this subject and it seems like no one has a straight answer. There are dozens of questions on this subject that are unanswered, however in many of those cases it appears that the AJAX request isn't sending the Origin header or that the bucket isn't properly configured. In this case, neither of those are true, which is why this is not a duplicate.
As you can see in the screenshot, the request includes the Origin header, but the response does not include the Access-Control-Allow-Origin header. What I would like to know is:
1. Why isn't S3 sending the proper header if my bucket is properly configured?
2. Is it possible that when the Adobe Creative SDK requests the image via AJAX, the browser sees that the image is already cached and tried to serve the cached image (which doesn't have the Origin header) instead?
3. If #2 is the case, how can I forcibly add the Origin header to the image request? In the app, the image is the background of a div (css background-image property).
I created a test bucket, enabled CORS, and used your CORS rules.
Note that I am not convinced that <ExposeHeader>Access-Control-Allow-Origin</ExposeHeader> is necessary, but it should not do any harm by being present, so I've retained it.
The behavior I observe in testing is not consistent with what you are showing in your browser's request/response headers.
Using curl, I set the Origin: header to http://example.com. (Yes, that's actually what I set it to... this was not modified in the output below).
$ curl -v http://xxxxxxxxxxxx.s3.amazonaws.com/index.txt -H 'Origin: http://example.com'
* Hostname was NOT found in DNS cache
* Trying 54.231.98.120...
* Connected to xxxxxxxxxxxx.s3.amazonaws.com (54.231.98.120) port 80 (#0)
> GET /index.txt HTTP/1.1
> User-Agent: curl/7.35.0
> Host: xxxxxxxxxxxx
> Accept: */*
> Origin: http://example.com
>
< HTTP/1.1 200 OK
< x-amz-id-2: pF39K26ii42SzxSU2Dt0KT2z7+xmfyiP4yekp9s4DCYJo0jlRwCTDg6QO6f0HMIL4H9b640zq7U=
< x-amz-request-id: 3B18A563CFF4E485
< Date: Sat, 28 May 2016 21:49:21 GMT
< Access-Control-Allow-Origin: *
< Access-Control-Allow-Methods: GET
< Access-Control-Expose-Headers: Access-Control-Allow-Origin
< Vary: Origin, Access-Control-Request-Headers, Access-Control-Request-Method
< Cache-Control: no-cache
< Last-Modified: Sat, 28 May 2016 21:40:57 GMT
< ETag: "cd21a8c7268dc6af728d180f9a3a81d7"
< Accept-Ranges: bytes
< Content-Type: text/plain
< Content-Length: 71
* Server AmazonS3 is not blacklisted
< Server: AmazonS3
Why is this interesting?
S3, with CORS configured and a <CORSRule> matching your request, always returns the CORS response headers and a Vary: header (which means "If you vary one of the following headers in your request, I may vary something about my response.") The headers from the above output that I am referring to, specifically, are these.
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET
Access-Control-Expose-Headers: Access-Control-Allow-Origin
Vary: Origin, Access-Control-Request-Headers, Access-Control-Request-Method
There is only one exception I can find to this, which is when there is not a matching CORS rule. To demonstrate that, I first changed my CORS configuration to <AllowedOrigin>http://example.com</AllowedOrigin> and then repeated the request. Note that the response is almost identical, except that S3 uses the exact origin in the response, and adds Access-Control-Allow-Credentials.
< Access-Control-Allow-Origin: http://example.com
< Access-Control-Allow-Methods: GET
< Access-Control-Expose-Headers: Access-Control-Allow-Origin
< Access-Control-Allow-Credentials: true
< Vary: Origin, Access-Control-Request-Headers, Access-Control-Request-Method
...however, if I -- still using the more restrictive CORS rule that specifies a specific origin -- then send a request for Origin: example.org, which is an origin that is not mentioned in my CORS configuration and has no wildcard <AllowedOrigin> to match, S3 responds as though CORS was not configured at all.
< HTTP/1.1 200 OK
< x-amz-id-2: WJ0QmIZ6jTQYefFi8GjlDQkZKFHDX8/5cmejeulhG1ov3/NdoSXbsTKetYpxvXPML8aUnPNZ/ac=
< x-amz-request-id: 15A03D8B1E08A830
< Date: Sat, 28 May 2016 21:58:34 GMT
< Cache-Control: no-cache
...etc.
This takes me back to my initial conclusion that the request you've shown your browser making does not match the timing of when you configured the bucket for CORS, and may have been cached before your bucket's CORS settings were in the correct state, or before they matched those you've posted in the question.
If an Origin: header was present on that request, as the browser shows that it was, then S3 should have added the CORS response headers, whether or not the request was actually a cross-origin request.
Your next steps would be to try this with a new object at a new path that there is no possibility of being cached, or try the common browser cache-busting tactic of adding ?some-random=thing-here to the object's URL when making the request. Failing that, you should consider proving or disproving correct behavior by your bucket using a tool like curl that shows exactly what's happening in the request/response.
Issue:
We were having issue with one of the ajax request in webkit browsers ( Chrome, Firefox, and Safari).
scenarios working:
1. If we configure chrome/firefox with Fiddler and enable https decryption in fiddler it works as expected.
2. Works properly in internet explorer.
We were able to see response on page, but if you go to networking tab and check response it's null and request is not complete it's spinning. we were thinking it's more of webkit browser decoding issue.
Please share if you have any idea how to fix or what might be causing this issue, any input will be appreciated.
Raw HTTP Header
HTTP/1.1 200 OK
content-encoding: gzip
content-language: en-US
content-type: application/json;charset=UTF-8
date: Wed, 19 Aug 2015 18:38:23 GMT
p3p: CP="NON CUR OTPi OUR NOR UNI"
vary: X-Forwarded-Host
transfer-encoding: chunked
server-name: app2
cache-control: private, must-revalidate, max-age: 0
x-powered-by: Servlet/3.0
x-ua-compatible: IE=edge
strict-transport-security: max-age=31536000; includeSubDomains; preload
x-frame-options: SAMEORIGIN
expires: -1
The issue was server side, i was getting extra data in JSON response and data binding was not happening properly in chrome, firefox and safari.
Whereas IE is having loose binding policy i guess that's reason it was working in IE
I am not using the SBT, but making direct REST calls with Abdera to the current version of Connections on IBM SmartCloud. REST URL in question: https://apps.na.collabserv.com/search/serviceconfigs
Observations
When testing from my laptop (using Firefox and the REST client add-on,) this works as expected. I get back an ATOM feed.
When testing from a server (on a different network,) using the same method (Firefox + REST client,) I get back HTML that is a log-in page.
In addition, I get this same result when I call the URL from a Java program on the same server.
In all cases, I am using the same credentials with basic authentication.
Update: If I log into SmartCloud first, on a separate tab in Firefox on the server, then call the URL as before, from another tab, it works. I get the ATOM feed as desired. Naturally, this is unsuitable as a solution, but I present it as additional information that could lead to an actual solution.
Update: Further testing shows that the local (laptop) log-in exhibits the same behavior as the server. A form-based log-in is required from the same browser, then subsequent REST calls work.
Update: Here is a relevant simplified code snippet:
private static Abdera ABDERA = new Abdera();
private static AbderaClient ABDERA_CLIENT = new AbderaClient(ABDERA);
...
String host = "https://apps.na.collabserv.com";
ABDERA_CLIENT.addCredentials(host, AuthScope.ANY_REALM, "basic", new UsernamePasswordCredentials("user", "password"));
...
ClientResponse response = ABDERA_CLIENT.get("https://apps.na.collabserv.com/search/serviceconfigs");
Summary
It appears that something about the originating server or the call is causing SmartCloud to respond with a log-in page. Whereas, the same call and credentials from my laptop, work as expected.
Question
Where should I start to trouble-shoot this? How can I build the client credentials to allow programmatic log-in?
Response Headers
If it helps, here are the response headers that I get back in each case.
Unsuccessful
Status Code: 200 OK
Cache-Control: no-cache
Connection: keep-alive
Content-Encoding: gzip
Content-Length: 1850
Content-Type: text/html
Date: Tue, 08 Oct 2013 14:15:03 GMT
Pragma: no-cache
Server: WebSEAL/6.1.1.3 (Build 110428)
Set-Cookie: PD-H-SESSION-ID=4_0_IR4***masked***oRKlJI;secure; Path=/; HttpOnly BIGipServerE3A-WebSEAL-80-fe=2132806922.20480.0000;secure; path=/
Vary: Accept-Encoding
p3p: CP="NON CUR OTPi OUR NOR UNI"
Successful
Status Code: 200 OK
Cache-Control: public, max-age=86400, s-maxage=86400, no-cache=set-cookie, private, must-revalidate
Content-Encoding: gzip
Content-Language: en-US
Content-Length: 1164
Content-Type: application/atom+xml; charset=UTF-8
Date: Mon, 07 Oct 2013 17:21:12 GMT
Expires: Tue, 08 Oct 2013 17:21:12 GMT
Server: WebSphere Application Server/8.0
Vary: Accept-Encoding
p3p: CP="NON CUR OTPi OUR NOR UNI"
x-lconn-auth: true
x-powered-by: Servlet/3.0
#Grant is your login using SAML? I could see this redirect happening. also could be TFIM related... maybe you should grab the auth on a different page, store the cookies, and then try connecting to the endpoint above.
I'm getting some odd response back from shopify ajaxapi for jsonp.
If you cURL a Shopify ajax api location
http://storename.domain.com/cart.json?callback=handler
you will get a jsonp response. But something is breaking the same request in browsers.
It appears to be related to compression? Here are some responses from each browser when attempting to call the jsonp as documented.
Firefox: The page you are trying to view cannot be shown because it uses an invalid or unsupported form of compression.
Internet Explorer: Internet Explorer cannot display the webpage
Chrome/Safari/Webkit: Cannot decode raw data, or failed (chrome)
Attempted use via jquery:
$.getJSON('http://storename.domain.com/cart.json?callback=?', function(data) { ... });
// Results in a failed request, viewable network request panels of dev tools
Here is some output from cURL including response headers:
$ curl -i http://storename.domain.com/cart.json?callback=CALLBACK_FUNC
HTTP/1.1 200 OK
Server: nginx
Date: Tue, 18 Dec 2012 13:48:29 GMT
Content-Type: application/javascript; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
Status: 200 OK
ETag: cachable:864076445587123764313132415008994143575
Cache-Control: max-age=0, private, must-revalidate
X-Alternate-Cache-Key: cachable:11795444887523410552615529412743919200
X-Cache: hit, server
X-Request-Id: a0c33a55230fe42bce79b462f6fe450d
X-UA-Compatible: IE=Edge,chrome=1
Set-Cookie: _session_id=b6ace1d7b0dbedd37f7787d10e173131; path=/; HttpOnly
X-Runtime: 0.033811
P3P: CP="NOI DSP COR NID ADMa OPTa OUR NOR"
CALLBACK_FUNC({"token":null,"note":null,"attributes":{},"total_price":0,...})
Also related unanswered here:
https://stackoverflow.com/questions/13750841/shopify-ajax-api-jsonp-supported
Thanks