This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
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?
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.
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
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
An IDE is no substitute for an Intelligent Developer.
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 ]