I am trying to do an AJAX call to an external domain. After reading a little bit, I have realised that this cannot be done. And I was starting to dive into proxys solution, but then I've found info about "cross-site xmlhttprequest with CORS"
Then, from here I have understood that perhaps non-old browsers had already implemented a way to do it, as far as the target domain allowed it I guess.
So, within this obscurity, I have decided to check the HTTP headers that were being captured.
It is a GET petition
http://www.genome.jp/dbget-bin/www_bconv?dbkey=uniprot&acc=P11730
Using any broswer I get the web page that I want, but through the AJAX call I get an status of 0.
But, with the AJAX script and using the firefox add-on Live HTTP headers, I can see that everything seems to go all right
http://www.genome.jp/dbget-bin/www_bconv?dbkey=uniprot&acc=P62071
GET /dbget-bin/www_bconv?dbkey=uniprot&acc=P62071 HTTP/1.1
Host: www.genome.jp
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0.1) Gecko/20100101 Firefox/9.0.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Origin: null
HTTP/1.1 302 Found
Date: Sat, 28 Jan 2012 19:24:24 GMT
Server: Apache
Location: /dbget-bin/www_bget?mmu:66922
Content-Length: 0
Keep-Alive: timeout=60, max=1000
Connection: Keep-Alive
Content-Type: text/plain
So, there are 2 options:
1) it is working, but the code has some kind of error
2) It seems to be working, but actually AJAX cannot be done to an external domain. Why Live HTTP headers is capturing the good stuff? because the censorship is done afterwards.
What is the answer?
(javascript code)
<html>
<head>
<script type="text/javascript">
function loadXMLDoc()
{
var xmlhttp;
xmlhttp=new XMLHttpRequest();
xmlhttp.onreadystatechange=function()
{
alert(xmlhttp.readyState+' '+xmlhttp.status)
if (xmlhttp.readyState==4)
{
alert(xmlhttp.responseText);
}
}
if("withCredentials" in xmlhttp)
{
xmlhttp.open("GET","http://www.genome.jp/dbget-bin/www_bconv?dbkey=uniprot&acc=P11730",true);
xmlhttp.withCredentials = "true";
xmlhttp.onreadystatechange = handler;
xmlhttp.send();
}
}
</script>
</head>
<body>
EDIT: So it is like that to use CORS the extra header needs to be enabled on the web server. Then I assume it is option 2).
Interesting links
Ways to circumvent the same-origin policy
http://anyorigin.com/
http://enable-cors.org/
http://remysharp.com/2011/04/21/getting-cors-working/
Your assumptions are correct.
Contrary to popular belief, an XMLHttp request to an external domain can always be sent. But, javascript does not grant access to the response document.
This is due to the Same Origin Policy
The same origin policy prevents a document or script loaded from one origin from getting or setting properties of a document from another origin.
As you found out, if the server agrees to grant access by setting an according header, this restriction does not apply (provided the browser supports CORS too).
Related
I'm trying to configure caching with Cache-Control for a REST endpoint in my webapp, it works locally, but when I deploy on our production server the browser just won't cache the responses.
The endpoint is queried via a parametrized ajax request (as shown below).
Some relevant notes :
I use a cache buster parameter (_) that is a unix timestamp generated at page load. It doesn't change across ajax requests.
localhost is on HTTP whereas production is on HTTPS. The certificate is valid and there are no related errors.
Both Firefox 59.0.2 and Chrome 66.0.3359.139 exhibit this behavior, so I assume this is something in the configuration.
Localhost
Request URL: http://localhost:8080/webapp/rest/events?_=1525720266960&start=2018-04-29&end=2018-06-10
Request Method: GET
Status Code: 200 OK
Referrer Policy: no-referrer-when-downgrade
=== Request ===
Accept: application/json, text/javascript, */*; q=0.01
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Cookie: JSESSIONID=<token>
Host: localhost:8080
Referer: http://localhost:8080/webapp/
X-Requested-With: XMLHttpRequest
=== Response ===
Cache-Control: no-transform, max-age=300, private
Connection: keep-alive
Content-Length: 5935
Content-Type: application/json
Following requests (for the same parameters) are effectively loaded from cache with the only difference being : Status Code: 200 OK (from disk cache)
Which seems fine, since I don't want to revalidate. The resource should only be fetched again, without validation, once it has gone stale after the duration of max-age specified by Cache-Control.
Production
Request URL: https://www.example.org/webapp/rest/events?_=1525720216575&start=2018-04-29&end=2018-06-10
Request Method: GET
Status Code: 200 OK
Referrer Policy: no-referrer-when-downgrade
=== Request ===
Accept: application/json, text/javascript, */*; q=0.01
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Cookie: JSESSIONID=<token>
Host: www.example.org
Referer: https://www.example.org/webapp/
X-Requested-With: XMLHttpRequest
=== Response ===
Cache-Control: no-transform, max-age=300, private
Connection: close
Content-Length: 5935
Content-Type: application/json
In this case, the response is never loaded from cache afterwards.
I've stripped some headers that I thought superfluous (Server, X-Powered-By, User-Agent, Date).
Question
What prevents the reponses to be cached by the browser when talking to the production server ?
2 days later I try again and caching works properly. (I swear I'm not insane)
Same request, same headers, same response.
I suspect that it falls into some kind of heuristic that overrides the response Cache-Control.
It certainly has to do with the fact that this endpoint did not specify Cache-Control before, so the browser overlooks the header since the heuristic favored refetching instead of caching, it can't go wrong about being more cautious.
RFC2616
13.2.2 Heuristic Expiration
Since origin servers do not always provide explicit expiration times,
HTTP caches typically assign heuristic expiration times, employing
algorithms that use other header values (such as the Last-Modified
time) to estimate a plausible expiration time. The HTTP/1.1
specification does not provide specific algorithms, but does impose
worst-case constraints on their results. Since heuristic expiration
times might compromise semantic transparency, they ought to used
cautiously, and we encourage origin servers to provide explicit
expiration times as much as possible.
All in all, this is the best explanation I have.
While trying to redirect user to a URL, it works with GET requests but not with postback requests.
Through firebug's Network window, I can see the redirect response received by browser after the postback request (that should cause redirect) completes. The browser seemingly initiates a GET request for the redirect URL but doesn't actually successfully redirect. It remains there on the same page.
I use JSF server side. The initiated GET request is not received at all by the server. However initiated by the browser on server's demand. I guess problem is somewhere client side only
Can anyone please explain how to make redirect work successfully ? Let me know incase I should provide any more information.
Edit:
Request header for redirect:
GET /Px10Application/welcome.xhtml HTTP/1.1
Host: localhost:8080
User-Agent: Mozilla/5.0 (Windows NT 6.2; rv:20.0) Gecko/20100101 Firefox/20.0
Accept: application/xml, text/xml, */*; q=0.01
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Referer: http://localhost:8080/Px10Application/channelPages.xhtml?channelId=-3412&type=Group
X-Requested-With: XMLHttpRequest
Faces-Request: partial/ajax
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Cookie: hb8=wq::db6a8873-f1dc-4dcc-a784-4514ee9ef83b; JSESSIONID=d40337b14ad665f4ec02f102bb41; oam.Flash.RENDERMAP.TOKEN=-1258fu7hp9
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
Response header for redirect:
HTTP/1.1 200 OK
X-Powered-By: Servlet/3.0 JSP/2.2 (GlassFish Server Open Source Edition 3.1 Java/Sun Microsystems Inc./1.6)
Server: GlassFish Server Open Source Edition 3.1
Set-Cookie: oam.Flash.RENDERMAP.TOKEN=-1258fu7hp8; Path=/Px10Application
Pragma: no-cache
Cache-Control: no-cache
Expires: -1
Content-Type: text/xml;charset=UTF-8
Content-Length: 262
Date: Wed, 22 May 2013 17:18:56 GMT
X-Requested-With: XMLHttpRequest
Faces-Request: partial/ajax
You're thus attempting to send a redirect on a JSF ajax request using "plain vanilla" Servlet API's HttpServletResponse#sendRedirect(). This is not right. The XMLHttpRequest does not treat a 302 response as a new window.location, but just as a new ajax request. However as you're returning a complete plain vanilla HTML page as ajax response instead of a predefined XML document with instructions which HTML parts to update, the JSF ajax engine has no clues what to do with the response of the redirected ajax request. You end up with a JS error (didn't you see it in the JS console?) and no form of visual feedback if you don't have the jsf.ajax.onError() handler configured.
In order to instruct the JSF ajax engine to change the window.location, you need to return a special XML response. If you have used ExternalContext#redirect() instead, then it would have taken place fully transparently.
externalContext.redirect(redirectURL);
However, if you're not inside JSF context, e.g. in a servlet filter or so, and thus don't have the FacesContext at hands, then you should be manually creating and returning the special XML response.
if ("partial/ajax".equals(request.getHeader("Faces-Request"))) {
response.setContentType("text/xml");
response.getWriter()
.append("<?xml version=\"1.0\" encoding=\"UTF-8\"?>")
.printf("<partial-response><redirect url=\"%s\"></redirect></partial-response>", redirectURL);
} else {
response.sendRedirect(redirectURL);
}
If you happen to use JSF utility library OmniFaces, then you can also use Servlets#facesRedirect() for the job:
Servlets.facesRedirect(request, response, redirectURL);
See also:
Authorization redirect on session expiration does not work on submitting a JSF form, page stays the same
JSF Filter not redirecting After Initial Redirect
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
Say, there's a URL, http://www.example.com/#hello.
Will the #hello thing be sent to the web server or not, according to standards?
How do modern browsers act?
The answer to this question is similar to the answers for Retrieving anchor link in URL for ASP.NET.
Basically, according to the standard at RFC 1808 - Relative Uniform Resource Locators (see Section 2.4.1), it says:
"Note that the fragment identifier is not considered part of the URL."
As stephbu pointed out, "the anchor tag is never sent as part of the HTTP request by any browser. It is only interpreted locally within the browser".
The hash variables aren't sent to the web server at all.
For instance, a request to http://www.whatismyip.org/#test from Firefox sends the follow HTTP request packet
GET / HTTP/1.1
Host: www.whatismyip.org
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Cache-Control: max-age=0
You'll notice the # is nowhere to be found.
Pages you see using # as a form of navigation are doing so through javascript.
This parameter is accessible though the window.location.hash variable
The anchor part (after the #) is not sent to any $_SERVER variables in PHP. I don't know if there is a way of retrieving that piece of info from the URL or not (as far as I know, it's not possible). It's supposed to be used by the browser only to find a location in the page, which is why the page does not reload if you click on an anchor like so: hello
I have a virtual directory on IIS 5.1 with two aspx pages. Access to Page1 configured as "Integrated Windows Authentication" option turned on and anonymous access is disabled. Page2 available through anonymous access. On client side there is XmlHttpRequest object that can send requests that contains POST data to this pages.
At first I try to send request to Page1. Standard Windows Authentication dialog appears, I entering my credentials and Page1 succesfully receiving POST data.
After that I try to make the same POST request to Page2 that can be accessed anonymously. And in this case Request has header Content-Length=0, and no any data has been sended.
If to repeat request to Page1 - it successfully receiving POST data. The same code is working good in Firefox 3.5. Page2 can receive data even after sending request to Windows Authentication required Page1. What can be wrong? And maybe it is any workaround for this problem?
Thanks!
Sending data:
function sendRequest() {
var url = "http://tom/AuthTest/Default.aspx";
var data = "data";
reqSend(url, data);
}
function sendRequestToWinAuth() {
var url = "http://tom/AuthTest/DefaultWA.aspx";
var data = "newdata";
reqSend(url, data);
}
function reqSend(url, data) {
var xmlhttp = createRequestObject();
if (!xmlhttp) {
alert("Cannot create XMLHttpRequest object.");
return;
}
try {
xmlhttp.open("POST", url, false);
xmlhttp.send(data);
}
catch (ex) {
alert("Error: " + ex.message);
}
}
Request to Page1:
POST /AuthTest/DefaultWA.aspx HTTP/1.1
Accept: */*
Referer: http://tom/AuthTest/client/testauth.html
Accept-Language: ru
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
Host: tom
Content-Length: 7
Connection: Keep-Alive
Cache-Control: no-cache
Cookie: innovator_user=admin
Authorization: Negotiate TlRMTVNTUAADAAAAGAAYAF4AAAAYABgAdgAAAAoACgBIAAAABgAGAFIAAAAGAAYAWAAAAAAAAACOAAAABYKIogUBKAoAAAAPcwBjAGEAbgBkAHQAbwBtAFQATwBNAGUdQIkWMQ6PAAAAAAAAAAAAAAAAAAAAAAo3goJdI7RH9poJwnjypksH2F2pIzbEOQ==
newdata
Request to Page2:
POST /AuthTest/Default.aspx HTTP/1.1
Accept: */*
Referer: http://tom/AuthTest/client/testauth.html
Accept-Language: ru
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
Host: tom
Connection: Keep-Alive
Cache-Control: no-cache
Cookie: innovator_user=admin
Authorization: Negotiate TlRMTVNTUAABAAAAB4IIogAAAAAAAAAAAAAAAAAAAAAFASgKAAAADw==
Content-Length: 0
Seems i have found a way to keep pages requiring windows authentication and pages allowing anonymous access on one site.
There 2 ways to do it:
This behavior (bug) is only reproducing when using NTLM authentication. So to avoid it, we can setup a Kerberos authentication mode on IIS site. Here is a good detailed FAQ about IIS and Kerberos: http://www.adopenstatic.com/faq/
To tell a thruth I have tried to follow the first way, but really my IIS doesn't want to use Kerberos anyway. On other hand I try to check this situation on another machine - and was surprised - Kerberos authentication was used there by default. I have tried to found any difference in configurations - but not successfull. So there is the second way:
Using Windows Authentication mode on a directory or file in a separate directory. For example we have some structure like:
../Default.aspx
../auth/DefaultWinAuth.aspx
../auth/DefaultWinAuth2.aspx
We can set IWA (Integrated Windows Authentication) mode on 'auth' directory or DefaultWinAuth page. After that all files and subdirectories that are included in this folder or situated on the same level as 'DefaultWinAuth.aspx' page will not be able to receive POST data. But all other files and directories outside directory 'auth' will work fine.
I've had this exact problem, apparently its by design in IE, check out this link:
http://www.websina.com/bugzero/kb/browser-ie.html
Basically IE won't send POST data to an unauthenticated URL/page if you are currently on an authenticated URL/page. I didn't find a work-around, I had to do something else, but let me know if you do figure out a way. Cheers