• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

URL.openstream method to local filesystem from applet (Too many things can go wrong with this)

 
Greenhorn
Posts: 16
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am trying to use the URL.openStream() method on the local filesystem from an applet, to no avail. Here are the particulars (so far):

java code:
URL url = new URL('file:\\\C:\Users\...\file.txt');
url.openStream();

receives the error "Bad crossdomain.xml: access denied ("java.io.FilePermission" "C:\Users\...\file.txt" "read")"

Here is the pertinent part of my .java.policy file (located in the user home directory):
grant codeBase "file:C:/Users/.../" {
permission java.io.FilePermission "C:\\Users\\...\\file.txt", "read" ;
};

Here is my crossdomain.xml file contents (located in the directory of the .html file containing the Java applet):
<!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
<?xml version="1.0"?>
<cross-domain-policy>
<!-- <site-control permitted-cross-domain-policies="by-content-type"/> -->
<allow-access-from domain="file:C:\\Users\\...\\" secure="true"/>
</cross-domain-policy>

Or possibly should the crossdomain.xml file be in the user home directory?

Slash or back-slash, too many possibilities. Please help me straighten this out. Thanks in advance.
 
Sheriff
Posts: 22783
131
Eclipse IDE Spring VI Editor Chrome Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Applets don't allow much access at all, and definitely very little to the local file system. Otherwise I could just write a little applet that would read your files and send their contents to me whenever you visit the page I've put my applet on, without you even knowing.

There is a way around this, but it requires you to sign your applets. Your users must then accept the signature (I don't know if there are ways to automatically accept trusted signatures). If they don't then your applet still can't do a thing on their machines.
 
John La
Greenhorn
Posts: 16
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks, but this isn't my first rodeo. I've self-signed the applet. These types of things used to be easier, prior to the crossdomain.xml security "enhancements".

I'm familiar with the Java applet security constraints, what "lit my frustration" is I'm not sure I understand why crossdomain.xml is being referenced for security of the local filesystem.

Again, any help anyone can provide is appreciated.
 
Marshal
Posts: 28193
95
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If you know how to use a java.policy file for an applet then you're the first person I've seen admit to that on this forum. I've seen lots of people asking about it but nobody answering their questions. I would have thought it would be unnecessary for a signed applet, but then I admit I've never tried to use java.policy for applets.

Anyway I would suggest that if you're fighting applet security for a URL then you should start with ordinary file access, i.e. via a File object or a FileInputStream. If you can't get that to work in a signed applet then there's no point in trying the more complicated thing, accessing the file via a URL.

As for the cross-domain policy: It looks like you're trying to download a policy from your host which says you can access a file from the local file system. This smells like a security breach to me. Imagine a website downloading some Javascript into your browser. Now imagine that website having a cross-domain policy which says it's all right for the Javascript to access files from the local file system. That would breach the local system's security, wouldn't it?

Also: A backslash character is never valid in a URL. It's always a space character which is used as separator, no matter where the file resides or what operating system is supporting the applet.
 
John La
Greenhorn
Posts: 16
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for your help. If its of any consequence, I'm using JRE 1.8.0_11.

I have switched the back-slashes in the URL to forward-slashes, and obtain the same result. You're right, this is probably "more" correct.

In one scenario, I'm interested in running solely on my client, and using the URL class methods (i.e. I trust myself). Perhaps this is an appearance by a bug. On an earlier version of Java (1.5.0, or 1.6.0 perhaps?), I was successfully using the .java.policy file as it's intended. I'll try the File methods instead.

In an Internet-connected scenario, I'm concerned about exposing my local IP in the "globally available" crossdomain.xml. This centers around the way my ISP has implemented the web-site filesystem I use.

Thanks again.
 
Bartender
Posts: 3323
86
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Is your grant codebase value set to the location of the applet code?
 
reply
    Bookmark Topic Watch Topic
  • New Topic