Recently, due to the requirements of the project, a desktop program developed by swing needs to be converted into an Applet and embedded in the web. The conversion work was completed quickly, but after being embedded in the web, a warning dialog box will pop up every time you visit the applet. The general meaning is that the applet contains untrusted code, prompting you whether to stop running. If you don't read the prompt carefully, it is easy to click Yes,

and the applet will not run.

By reading the prompt in the dialog box, all jars in the applet are signed. After visiting again, a warning dialog box appears. After reading again, it is found that the prompt says that the applet contains signed and unsigned codes (resources). We know that java's signature will only sign the class in the jar package, but not the resource files in it, which leads to why there will still be a warning

if it is signed. So I went to oracle official website to find the answer and found the following useful links:/javase/7/docs/technotes/guides/jweb/mixed _ code.html

This article mentioned two methods, which are aimed at users and developers (or deployers). End users can handle how applet

run mixed code by modifying java settings in the control panel. Another way for developers is to modify the manifest configuration in the jar package. You can control the running of applet in the browser by setting two properties, the Trusted-Only property < P > and the Trusted-Library property.

Trusted-Only is set for those applet or application that don't need untrusted controls, and Trusted-Only will not load untrusted classes or resources.

and the corresponding Trusted-Library is to allow applet or application to use those untrusted controls without popping up a warning dialog box. Trusted-Library will prevent trusted components from using untrusted components.

Through the above information, we have found a way to get rid of the dialog box, that is, modify the manifest files of all jar packages used by applet, add Trusted-Library attributes, and then sign them.

problem: in the above process, a problem is that a third-party jar has been signed. At this time, if you modify its manifest file and then sign it again, you will get an error and the signing will fail. At this time, you can delete the. DSA and. SF files in the META-INF directory, then manually delete the signature information in MANIFEST.MF and sign it again.

the format of the signature information in p>MANIFEST.MF is as follows:

name: resources/language/lang.xml

sha1-digest: vc76jnzoyhdh4je/OV+/gp92f9o =

This problem is solved.