*
The moose likes Applets and the fly likes applet security is a big pain Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Applets
Bookmark "applet security is a big pain" Watch "applet security is a big pain" New topic
Author

applet security is a big pain

Barry Andrews
Ranch Hand

Joined: Sep 05, 2000
Posts: 523

Hi,
I have an applet, and all I want to do is access a file from an HTTP server. All I need to do is read from it, but of course I get the AccessControlException. Why is this? Why do I need to go through this entire jar signing crap just to have read access to a server that anybody and everybody has access to? Does anyone know of a way to get around this without having to go through the entire jar signing process and paying for a certificate?

many thanks,
Barry
Linda Jones
Ranch Hand

Joined: Aug 17, 2002
Posts: 57
Could you not treat the file as a URL?
Linda
Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15299
    
    6

You are right. Applet security is a pain. But below are simple instructions on signing a jar file with a self made cert so you don't have to buy one. I do this for our companies internal intranet.
Signing JAR Files with a Test Certificate
Here are the steps needed to sign a JAR file with a test certificate:
Make sure that you have a JDK 1.2 or JDK 1.3 keytool and jarsigner in your path (located in the J2SE SDK bin directory).
Create a new key in a new keystore as follows:
keytool -genkey -keystore myKeystore -alias myself
You will get prompted for a information about the new key, such as password, name, etc. This will create the myKeystore file on disk.
Then, create a self-signed test certificate as follows:
keytool -selfcert -alias myself -keystore myKeystore
This will prompt for the password. Generating the certificate takes a few minutes.
Check to make sure that everything is ok. To list the contents of the keystore, use the command:
keytool -list -keystore myKeystore
It should list something like:
Keystore type: jks
Keystore provider: SUN
Your keystore contains 1 entry:
myself, Tue Jan 23 19:29:32 PST 2001, keyEntry,
Certificate fingerprint (MD5):
C2:E9:BF:F9 3 F:4C:8F:3C:5F:22:9E:AF:0B:42:9D
Finally, sign the JAR file with the test certificate as follows:
jarsigner -keystore myKeystore test.jar myself
Repeat this step on all of your JAR files.
Please note that a self-signed test certificate should only be used for internal testing, since it does not provide any guarantees about the identity of the user and therefore cannot be trusted. A trust-worthy certificate can be obtained from a certificate authority, such as VeriSign, and should be used when the application is put into production.
After you have done that, everything should work for you.


GenRocket - Experts at Building Test Data
Scott Lynch
Greenhorn

Joined: Dec 12, 2001
Posts: 19
Hmm.. I tried that method verbatim and I'm getting the following error:
java.security.cert.CertificateException: Unable to verify the certificate with root CA
at sun.plugin.security.TrustDecider.isAllPermissionGranted(Unknown Source)
at sun.plugin.security.PluginClassLoader.getPermissions(Unknown Source)
at java.security.SecureClassLoader.getProtectionDomain(SecureClassLoader.java:157)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:106)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:243)
at java.net.URLClassLoader.access$100(URLClassLoader.java:51)
at java.net.URLClassLoader$1.run(URLClassLoader.java:190)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:183)
at sun.applet.AppletClassLoader.findClass(AppletClassLoader.java:126)
at sun.plugin.security.PluginClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(ClassLoader.java:294)
at sun.applet.AppletClassLoader.loadClass(AppletClassLoader.java:109)
at java.lang.ClassLoader.loadClass(ClassLoader.java:250)
at sun.applet.AppletClassLoader.loadCode(AppletClassLoader.java:491)
at sun.applet.AppletPanel.createApplet(AppletPanel.java:582)
at sun.plugin.AppletViewer.createApplet(Unknown Source)
at sun.applet.AppletPanel.runLoader(AppletPanel.java:511)
at sun.applet.AppletPanel.run(AppletPanel.java:289)
at java.lang.Thread.run(Thread.java:479)

This is using JRE 1.3.1_07, Java plugin 1.3.1_01, IE 6.0.


"It is not a good idea generally to annoy a computer cracker, but it is a very bad idea to annoy a group of computer crackers bent on impressing each other."<br />- Robert X. Cringely
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15957
    
  19

Applet security is a big pain. However Code Red, Nimda and SQL Slammer are all bigger pains.
However, you've made a common fundamental error here. So it's time to repeat my mantra:
A web server is not a file server
A web server is not a file server
A web server is not a file server
It's easy to make this mistake, since the default action for most web servers is to return a datastream from a file whose name corresponds to the name and structure of the reequesting URL, but nevertheless
A web server is not a file server


Customer surveys are for companies who didn't pay proper attention to begin with.
Barry Andrews
Ranch Hand

Joined: Sep 05, 2000
Posts: 523

A web server is not a file server

Is there some point to be made here?
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15957
    
  19

Yup. File servers use completely different network connections and protocols than web servers. Web servers are responsible for dissecting URLs from HTTP requests and figuring out what to do with them. In many cases, that simply means to take the part of the URL that follows the hostname, concatenate some directory structure to it and copy that file back to the client over HTTP. In others, such as JSPs, it means that the URL is to be passed to a designated Java class for processing. This is completely programmable and determined by how I've configured the server. I could just as easily say that requests ending with "htm" were to be handled by the JSP processor.
It also means that even basic HTML isn't as simple as you might think. The server can be told to return a different web page depending on whether your browser prefers English, Urdu or Latvian.
The differences are even more apparent when you try and store to the webserver. Unlike a file server, where you can simply push out a copy via the DOS copy command, on a webserver you have to request that the server accept what you're planning to send. And the web server makes the ultimate decision whether or not to accept the file and where the file will be stored and even under what name and format that file will be stored (it might even end up as data in a database).
You also can't map a network drive ID to a web server like you can a file server.
Of course, since a given machine CAN be running both web and LAN servers concurrently, it can APPEAR that the two share functionality, but it's all appearances. Which server actually handles the work is determined by the access mechanism you use.
Also, when you attempt to work over the Internet, the differences become more noticable. In many cases, firewalls will block LAN server traffic. A LAN server open to the Internet is a catastrophe waiting to be hacked.
Finally, though you can "log in" to web apps, the actual processes and mechanisms are quite different than LAN server logins.
So really, A web server is not a file server.
[ February 28, 2003: Message edited by: Tim Holloway ]
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
 
subject: applet security is a big pain
 
Similar Threads
Writing a file from an Applet
applet socketpermissions
'signing' and 'grant'
Applet security - is signing all you need?
Applet works fine in my Eclipse IDE, but doesn't work outside of Eclipse