Why Content-Length is 0 while sending POST request with XMLHttpRequest object? - windows

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

Related

Redirect from a Servlet filter, when an AJAX request is made [duplicate]

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

Exchange 2003 OWA galfind only returning HTML response

I've got a routine that queries galfind and for most situations it returns the expected XML response after issuing a basic GET. I'm trying it out now on an older (Exchange 2003) server and the galfind GET will only return the HTML search form. The query response data returns correctly along with the form content but it'd be nice to get it in XML format. So two related questions:
Does OWA in Exchange 2003 support XML responses for galfind?
If so, how does one either modify the HTTP request or configure the server to retrieve the XML formatted response from a galfind query?
Here's an example GET request I've been playing with:
GET
http://mail.mydomain.com/exchange/administrator#mydomain.com/?cmd=galfind&dn=C
HTTP/1.1 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0.1) Gecko/20100101 Firefox/8.0.1
Accept: text/xml
Authorization: Basic
Host: mail.mydomain.com
Adding "MSIE 6.0" to the User-Agent seems to allow you to toggle over to an XML formatted response, e.g.
GET
http://mail.mydomain.com/exchange/administrator#mydomain.com/?cmd=galfind&dn=C
HTTP/1.1 User-Agent: Mozilla/5.0 (MSIE 6.0; Windows NT 6.1; WOW64; rv:8.0.1)
Gecko/20100101 Firefox/8.0.1
Accept: text/xml
Authorization: Basic
Host: mail.mydomain.com

(firefox 9) javascript ajax to an external domain, status 0 but LiveHTTP Headers capture the correct answers (!?)

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).

AJAX call to internal server works in IE but not in other browsers

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

How is it possible a 404 response just only in IE8?

I have an Spring application (with Spring Security and Spring MVC) deployed in a Tomcat server. The application works perfecty in Firefox, Chrome, Opera and IE9.
I have a weird problem with IE8. The login screen loads, and (as I can see in server logs) the session is open when username and password are provided. Once the user is logged, and the browser is redirected to the main page, a 404 error is returned by the server.
As IE8 developer tools doesn't have a net panel, I have used Fiddler to monitor http connections. I thought that it could be happening that it was doing a wrong request during page loading but it was the main page request wich is responsing with 404.
How is it possible that the server responses with 404 to the main page request just only in IE8?
Thank you.
Edited:
Those are the request header for IE8 and Firefox respectively:
GET /myWebApp/ HTTP/1.1
Accept: application/x-ms-application, image/jpeg, application/xaml+xml, image/gif, image/pjpeg, application/x-ms-xbap, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*
Accept-Language: es-ES
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Win64; x64; Trident/4.0; .NET CLR 2.0.50727; SLCC2; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; Tablet PC 2.0; .NET4.0C; .NET4.0E)
UA-CPU: AMD64
Accept-Encoding: gzip, deflate
Host: dev.mydomain.com
Connection: Keep-Alive
Cookie: JSESSIONID=ABA1382304002F894ABDFCC2442FA5F8; SPRING_SECURITY_REMEMBER_ME_COOKIE=NGUxMTZlOTY3OGM0OTgxNDY4NDczOTlkOjEzMjQ1ODMwMzU0MDI6OWZiYzdhYjY1ODY2Mzc3YmI0Yzc5YTMzMWI5NDhjNTg
--
GET /myWebApp/ HTTP/1.1
Host: dev.mydomain.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20100101 Firefox/8.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: es-es,chrome://global/locale/intl.properties;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Cookie: JSESSIONID=7FD3B02252E2FCBC9BE7249AFD84F541; SPRING_SECURITY_REMEMBER_ME_COOKIE=NGUxMmYxMTgzMmRjZTM0NzYyMWVjOWEwOjEzMjQ1ODMwMTA1MTU6MzFiYzU4OGQ4NTMwN2Y3M2I4YmQzN2M0NzY2MzcwZjI
Knowing that the problem was about "Accept" I have revised the MVC Controller classes mappings and I have finaly found the issue. Somehow this was the way that the main page was mapped in MVC so it didn't work whith the IE8 header attribute:
#RequestMapping( value = "/", headers = "Accept=text/*" )
I have learned a hard lesson today. ;-)

Resources