java.net.URL Access Exception

[MistaWizurd]

OMG, I'm so tired of trying to find this answer. I'll do my best to explain the issue. I have compiled, jarred and signed this browser applet:

import java.applet.Applet;
import java.net.URL;
import java.io.*;
 
public class WebPipe extends Applet {
 
    public String getText(String url)
    throws java.net.MalformedURLException, java.io.IOException
{
    URL resource = new URL(this.getDocumentBase( ), url);
    InputStream is = resource.openStream( );
    BufferedReader in = new BufferedReader(new InputStreamReader(is));
    StringBuilder text = new StringBuilder( );
    String line;
    while((line = in.readLine( )) != null) {
        text.append(line);
        text.append("\n");
    }
    in.close( );
    return text.toString( );
}
	public void init() {
            // Call f() in HTML page
     }
}

In the host page:

<applet id="WebPipe"
    code="WebPipe.class"
    archive="WebPipe.jar"
    style="width: 1px; height: 1px; float: left;"
    mayscript></applet>
<input type="button" onClick='alert(document.WebPipe.getText("http://myserver/test.txt"));'>

What I'm trying to accomplish is event driven data retrieval from a file on my server using the java applet as a "remote data connectivity driver" for JavaScript. I keep getting access denied. I'm not sure if its the browser or the server that is denying access but I can tell you the code works fine when called from the browser's body.onLoad event. I need to be able to post data and retrieve data with this "driver."

I suppose it really doesn't matter whether it is get or post, as long as I can pass parameters on the requested URL. Here is what the Javascript console reports after clicking the button:

uncaught exception: java.security.AccessControlException: access denied (java.net.SocketPermission 127.0.0.1:80 connect,resolve)

At this point exception handling is unimportant. the inability to get the content of the desired url is my problem.

[copeg]

If I understand correctly, you are trying to read a file on your server from an applet. If this is the case applet's are client side - just like javascript - so the server needs to allow the client access. Typically this is done by having a script or listener on the server which serves the requests, using query strings as parameters to vary the response to those requests.

[MistaWizurd]

Hmm... Makes no sense to me as to why a typical Webserver (I'm using Apache2 on UBUNTU x64) should deny read access to a public (world readable resource) file. Yet, this is not unfathomable. Thanks for your assistance. I will try writing a script to 'dump' the file in PHP.

[MistaWizurd]

Well, you were absolutely correct about my intent. However using a script, does not solve the issue. Same error using code:

<?php include("test.txt"); ?>

All of these files are in the root directory of the server. My apache log file doesn't say anything particulary interesting other than crossdomain.xml not found, but in reproducing the reported client error, the error does not re-manifest itself in the apache log.

[MistaWizurd]

I found a solution to the policy issue. I have not entirely tested this but the adaptation I have created using the classes and methods described here have seemingly solved my policy issues.

* edit: FALSE POSITIVE see post #6 for the real fix...
Java HTTP example - Reading and writing to an HTTP server | devdaily.com

Maybe I was just tired however this is what led me to the code:

you are trying to read a file on your server from an applet

Thanks a billion!

[MistaWizurd]

Wow, I didn't need to change the code at all. i found a crossdomain.xml file for java and placed it in my virtual host root directory. The crossdomain.xml 404 kept showing up in the access log. So I placed the crossdomain.xml file in the /var/www directory and all the problems have been solved. It is most interesting to note that sometimes, mainly when the code is first loaded into the browser, that the code works fine until the content of the requested file is changed or the browser is reloaded.. Seeing that this problem arose out of security features... i don't feel very secure!