Closed Bug 229711 Opened 21 years ago Closed 19 years ago

Access denied using XmlHttpRequest and document.domain property

Categories

(Core :: XML, defect)

Product:
Core
Component:
XML
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 290100

People

(Reporter: bumblebe, Assigned: hjtoi-bugzilla)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; es-ES; rv:1.5) Gecko/20031007
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; es-ES; rv:1.5) Gecko/20031007

When using the XmlHttpRequest.open() method with the javascript document.domain
property set, this method returns an access denied error. 

Reproducible: Always

Steps to Reproduce:
1. In the html page, set the document.domain property to the desired value
2. Instantiate a XmlHttpRequest object and call his open() and send() method
3. 

Actual Results:  
Uncaught exception : access denied calling XMLHttpRequest.open method

Expected Results:  
after the open() and send() methods, the expected result is to retrive xml data
from the server, without errors ( or at least, without access denied errors )

A simple example code might be like this : an empty page with an onload event,
which calls a servlet with a request xml and expect a result xml. We are using
sarissa.js in order to be able to use the .xml property of the resulting xml object.

If we remove the document.domain line, all works fine. If we leave this line, it
only works on IE.  It is suposed it will fail on all systems, not only on
windows platform.

Notice this is a JSP , although it has no java code at all, but it is useful to
set the document.domain property from the server.


<%@ page contentType="text/html;charset=iso-8859-1" %>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<HEAD>
<TITLE> New Document </TITLE>
<script type="text/javascript" src="sarissa.js"></script>
<script type="text/javascript">
	
	document.domain = "san.gva.es";

	function envia(info) {

		var xmlHTTP = null;
		var tempxml = null;

		xmlHTTP =  new XMLHttpRequest();
		
		
		xmlHTTP.open("POST","http://localhost.san.gva.es/myServlet", false);	
		xmlHTTP.setRequestHeader("Content-Type", "text/xml; charset=utf-8");
		xmlHTTP.send(info);

		tempxml = xmlHTTP.responseXML;			
		return tempxml;	

	}

	function aFirstTry() {
		
		var llamada ="";
		llamada += "<OPERATION>";		
		llamada += "<OPERINFO COMP='myComp' CLASS='myClass' OPER='myJavaOper'>";		
		llamada += "</OPERINFO></OPERATION>";

		var datos = envia(llamada);
		alert(datos.xml);
	}

</script>
</HEAD>

<BODY onload="aFirstTry()">

</BODY>
</HTML>
Im not sure if I understood correctly, but do you try to open XmlHttpRequest
from one domain to other?
By default it this possible request only same domain as is the page with the script.
See http://www.mozilla.org/xmlextras/
Miguel, what's the domain of the page that has the code in comment 0?
It's the first time I write into the bugzilla, so I hope my new comment will be 
visible.  I'm doing all locally on my machine. I have a local Tomcat running 
from a JBuilder project. I have to set the document.domain property of my html 
pages with "san.gva.es" because it is the domain of the other web application I 
have to communicate with. When I enter my application, I use the URL : 
http://localhost.san.gva.es ( which is the Tomcat running on my computer , and 
I have this machine name on my hosts file ) , so in theory, there would be no 
domain problems at all. In fact, it runs ok with IE. 
The other web application I have to communicate with , it's not locally on my 
machine. It's in another server but using the same domain and port number.
caillon, what's up here?
I will try to show my scenario the best way I can. Consider a main page called
mainpage.jsp, which runs locally on my computer , with the url :
http://localhost.san.gva.es/mainpage.jsp. This writes an HTML file which sets
the document.domain property to "san.gva.es" and has two links, A and B. Link A
opens an HTML page located on some server in the domain san.gva.es, for example
someserver.san.gva.es/main.html , that when closed it access the opener window
and sets some variable to some value, for example :  window.opener.somevariable
= somevalue , so , as the two pages have the same document.domain, there is no
problem at all. Values can be passed through the two windows.  We make no use of
the XmlHttpRequest on the link named A. Now, consider link B, which calls some
servlet function in my localhost using the XmlHttpRequest object. Here's the
problem : the object throws an access denied error, and I'm accessing my own
computer. I'm not calling a remote host. My mainpage.jsp calls a servlet running
on my machine with http://localhost.san.gva.es/servlet/myServlet.  Why this
fails ? As soon as I remove the document.domain statement, all runs fine. With
IE6+ there are no problems at all. Is this a bug or not ?
>> You cannot fool Mozilla's security mechanism by setting some document.domain <<

You need to research into assigning access privileges for a script. These are
called signed scripts. Java is the same way. You cannot connect an Applet's
Socket to another domain without changing Java security privileges.

IE has bad security on this issue it seems.

This should be an invalid bug.
I have the same problem

main site running on x.domain.com
frame running om y.domain.com 

.. forces me to set document.domain = "domain.com";

XMLHttpRequest() should make it's request to the host of whatever frame it's 
hosted on (either x.domain.com or y.domain.com in this example).

Problem is that XMLHttpRequest() allways makes the request to "http://" + 
document.domain + relativeUrl; (http://domain.com/whatever.cgi)

Good for mozilla that alot of users are running this browser.. bad for us, 
siteowners ;).. Only solution for us was to invest in heavy-iron hardware 
to "http-switch"  users and have all elements of the site running under one 
domain (and leave document.domain to it's default).. pretty expensive just to 
support Mozilla I'd say ;)
is XmlHttpRequest in any standards specifications?

"not yet"
I solved the problem by adding some lines to prefs.js on my mozilla profile, 
but it is not the desired solution :

user_pref
("capability.principal.codebase.p0.granted", "capability.policy.default.XMLHttpR
equest.open UniversalBrowserRead");
user_pref("capability.principal.codebase.p0.id", "http://mi.domain.com");
As far as I understand this, it works when communicating between frames on
x.domain.com and y.domain.com if both set document.domain to domain.com. Since
it works with frames one would expect it to work with XMLHttpRequests
Status: UNCONFIRMED → NEW
Ever confirmed: true
Duping to hopefully more active bug (at least the assignee is more active)

*** This bug has been marked as a duplicate of 290100 ***
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.