xxxxx@xxxxx   points out that Java Web Start and the Java Plug-In do not obey the crossdomain.xml directives that have emerged as a new standard for allowing certain web services to be accessed from unsigned code:

"Currently unsigned applications and applets cannot access any resources outside of the domain they were loaded from.  This is great for security but makes certain types of applications difficult or impossible to write, such as mashups with the many cool webservices available from Google, Yahoo, etc.   All of our competitors (Flash, Silverlight, and AJAX) have support for this.  They handle it in one of two ways:

* Hijack the remote code loading mechanism to provide data. AJAX does this with JSON, which is a form of Javascript. This works because javascript can load additional javascript remotely but cannot load XML or other data files. Encoding data as Javascript hashtables works around this security limitation.  This is not feasible for Java since it would require on the fly compilation on the server and some nasty class loader tricks.

* Allow safe access to webservices using the crossdomain.xml files.  This is what Flash and Silverlight do.  In brief, if the client app requests a webservice on another domain the Flash environment will first check for some magic xml files on that domain to see if cross site access to particular resources is allowed.  If the webservice doesn't allow it then the request is denied.  This is what Java should support.


Silverlight 1 did not have support for cross domain scripting, but in Silverlight 2, they have decided to just reuse the crossdomain.xml system from Flash rather than reinventing the wheel. We should do the same since it would allow usnigned Java applications and applets to access existing webservices safely without requiring those webservices to be modified in any way.

General info on cross domain xml files:
    http://crossdomainxml.org/

 customer 's docs on cross domain xml files.
    http://kb. customer .com/selfservice/viewContent.do?externalId=tn_14213&sliceId=2

 customer 's docs on cross domain xml files
    http://msdn2. customer .com/en-us/library/cc197955(VS.95).aspx "
Posted Date : 2008-03-17 18:45:01.0

Fixing this will also fix some longstanding problems with the National Weather Service applets:

  http://www.nws.noaa.gov/wwa_loop12.php
  http://www.nws.noaa.gov/wwa_loop24.php

because these applets attempt to contact http://www.weather.gov/ , which has a crossdomain.xml file.
Posted Date : 2008-03-19 23:37:56.0

N/A

Adobe's Flash and now Microsoft's Silverlight use a mechanism called
"cross-domain XML" to allow code to access web services. The server
provides a file named "/crossdomain.xml" with something like the
following contents:

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
   <allow-access-from domain="*" />
</cross-domain-policy>

which advertises to clients that they are allowed to connect to it.

Java does not currently pay attention to the presence of these policy
files. This prevents unsigned Java code from accessing existing web
services that are available to competing technologies.

Added support to the security managers used by Java Web Start and the
Java Plug-In to handle the most basic form of the above file. Only if
the file advertises access from all domains is access granted to it.
It was necessary to record all of the IP addresses associated with the
server and implicitly grant access to them due to how the permission
checks are done at various points in the Java SE networking stack.

It turns out that the NOAA weather applets, which have been failing
with a SecurityException for some time, suddenly start working with
this fix since the alternate host from which they previously
incorrectly downloaded images, www.weather.gov, has a root
crossdomain.xml file granting access.

Note that this change is under review from   xxxxx@xxxxx   of
the security team, and some changes might be needed in follow-on bugs
based on his review comments. However, in general there seems to be no
objection to enabling this functionality.
Posted Date : 2008-04-01 01:24:45.0

this is extremely necessary