This week's book giveaway is in the OCPJP forum. We're giving away four copies of OCA/OCP Java SE 7 Programmer I & II Study Guide and have Kathy Sierra & Bert Bates on-line! See this thread for details.
at java.security.AccessControlContext.checkPermission(Unknown Source)
I understand fundamentally, that we have a permission problem in the sandbox (JRE running in the browser), and as a solution 1) we can modify the java.policy file to add permissions to execute this code; or perhaps solution 2) is to "sign" the applet. 3) Other solution?
Question to you is, what do you think the best approach would be for us and the least hassle for the public who would be using our applet; and do you have a cook book example of "signing" applets. One other consideration would be that we don't want to pay a bunch of $ to verisign for Cert Authority, if that is needed for signing (not sure)... Perhaps you can comment on that too.
The two solutions you mentioned are the only ones; no other workarounds exist.
Signing the applet would mean the least inconvenience for the general public - altering the local security policy is likely to be beyond the capability of a general audience. This may be different if your target audience is not the "general web user", though.
You don't need to buy a certificate - you can create one yourself. The consequence would be that the user is asked whether he wants to trust "Joel Thompson" instead of being asked to trust someone claiming to be "Joel Thompson" whose identity has been verified by Verisign. Whether that makes a difference for your audience is for you to decide.
Try following to sign your Applet How To Create a Signed Applet 1.Package the applet into a JAR file. The applet must be in a JAR file before a certificate can be attached to it. Use the jar JDK utility. If the applet was previously referenced with the help of a codebase attribute in <applet> tag, replace the codebase attribute with the archive attribute. The value of the archive attribute is a URL of a JAR file. To use the 'jar' command, open an MS-DOS window and navigate to the directory where your classes are stored. Notice that this assumes you have already set up a Path on your machine which allows you to use Java SDK commands from anywhere. The instructions for setting up your Path correctly are contained in chapter 2 of the Murach textbook. On my machine for this example, I navigate in the DOS window to C:\My Documents\Baruch\4150\Day14\EmailApplet\classes> Then I use a jar command which specifies the options, output file name and the files to include: >jar cfv EmailApplet.jar User.class UserIO.class UserEmailPanel.class EmailApplet.class (You have to write this all in one line; there is a break above only for the purposes of the Word document layout.) Make sure you preserve case when you list these files, or Java won't be able to find them when it opens the .jar archive. Once you have created the jar file, you can look at its contents by using 'tf' options: >jar tf EmailApplet.jar This will show you the metafiles created for the jar, and the files you added to it. If you run your HTML file now, you will get a security exception (look in the Java console), and the read/write operations will not be carried out. You need to sign it. But before you can sign it, you need a key. 2.Create a public/private key pair. The command for this is keytool -genkey keytool is another SDK utility. It will prompt you for a password to your keystore. The keystore is a file that contains your public/private key-pairs, and the public-keys of others with whom you exchange information. See the documentation in the above link. Don't forget your password! You'll need it again. You can use any of the options listed in the keytool documentation, but generally all you need is: keytool -genkey -alias <yourAlias> If you don't specify an alias, it will make a key for you called 'mykey'. This will also work fine.
3.Create a certificate for the key you created in the previous step. keytool -selfcert -alias <yourAlias> Again, keytool will prompt you for a keystore password and remaining parameters. This certificate is now self-signed by you, meaning that it has not been validated by any third party. This is suitable for demo purposes, and may be acceptable to yourself and those who know you because if there is any doubt that the certificate is really yours they can always call you up and ask you for the digest to verify that it is really you and not some impostor that created the certificate. However, if this applet were to be widely distributed, and you wanted it to be accepted by those who do not know you personally, you would certainly want to pay a modest fee to obtain a certificate that is validated by a trusted certificate authority. The procedure for this is straightforward, but beyond the scope of this simple tutorial. Finally, you can see the certificates available in your keystore by using the following command: keytool -list 4.Run jarsigner associate this certificate with the JAR file that contains your applet. You will need to give the name of the public key of the certificate you just created. This creates a digest for each file in your JAR and signs them with your private key. These digests or hashes, the public key, and the certificate will all be included in the "WEB-INF" directory of the JAR. For my demo, I wanted to make several jars, some signed, some not, and some with signatures, some without, so I needed to use the -signedjar option. If you don't use this option, then the .jar file you are signing will be overwritten with the signed version. After the options, you complete your command line with the name of the file being signed and the alias of the key you want to sign it with. So for example, at one point I used: jarsigner -signedjar EmailApplet2.jar EmailApplet.jar mykey You can then check to see that the applet is signed by using the -verify option. It's a good idea also to add the -verbose option, so you can see all the details: jarsigner -verbose -verify EmailApplet2.jar Your applet is now signed. The next time you or someone else downloads it in it's page the browser will present a dialog box displaying the credentials you just created for it and asking the user permission to run it. If he/she chooses not to, the applet will throw the same AccessControlException that we saw in the Java Console window the first time we tried to run it in our browser. The difference is that now the user gets to make an informed decision as to whether or not they trust your applet to not harm his/her system. You will only need to generate the public/private key-pair once, but you may want to automate the steps that create and sign the JAR file, because you will need to repeat those every time you modify anything in your code. Remember to update your HTML ARCHIVE command to point to the right .jar file, so that your web page tries to load the applet that is actually signed. Be careful how you specify the destination for the file to be written in your Java IO class. If you only use the file name, the file will be written at the user 'home', which in the case of my machine is the Desktop.
-------------------------- Good Luck ---------------------------------