Problem mit .java.policy

Also, das war ja so: Erst hatte ich den Fehler „jarsigner error: java.lang.RuntimeException: keystore load: Keystore was tampered with, or password was incorrect“, den konnte ich durch einen anderen Aufruf von jarsigner beheben (keystore und Passwort als Parameter ergänzt), gefunden hab ich das in security - jarsigner error: java.lang.RuntimeException: keystore load: Keystore was tampered with, or password was incorrect - Stack Overflow

Danach kam dann der Fehler „Missing Application-Name manifest attribute for“ und den glaubte ich mit der Permissions Datei beheben zu können, gefunden habe ich das hier: java - How do I fix "missing Codebase, Permissions, and Application-Name manifest attribute" in my JNLP app? - Stack Overflow
Wenn ich ohne Permissions Datei versuchen soll bräuchte ich einen Tipp, wie ich den Fehler „Missing Application-Name manifest attribute for“ weg bekomme.

[QUOTE=L-ectron-X;91315]2. Gar nicht, es sei denn, du kaufst ein Zertifikat. Diese Option gibts nur noch für gekaufte Zertifikate, so weiß ich weiß.
Selbstsignierte Jar-Dateien sind eben von „Unbekannt“.[/quote]
Das ist mal wieder doof aber ok, die Wirtschaft muss ja laufen…

[QUOTE=L-ectron-X;91315]3. Keine Ahnung. Wie viele Klassen hast du denn in deinem Projekt? Es müssen alle signiert sein.
Hast du externe Jar-Dateien eingebunden? Die müssen auch signiert werden.[/quote]
Externe jar Dateien: nein.
Wieviele Klassen: Weiß ich nicht. Wie kann ich die Zahl ermitteln? Es gibt eine einzige Datei, die ich als Java Quellcode (localfile.java) und als kompilierte Version (localfile.class) vom Programmierer bekommen habe. Letztere verwende ich aktuell zusammen mit der Manifest Datei für das neu erzeugte jar. Aber das sieht man ja in meinem Ablauf.

Der Schieberegler in der Java Systemkonsole steht auf Mittel (weniger Sicherheit geht hier auf Windows 7 nicht) und meine Webseite steht unten auf der Ausnahmeliste. Laut des dortigen Textes müsste mein Applet also im doppelten Sinne nach Bestätigung der Sicherheitsprompts arbeiten. Tut es aber nicht. Wie kann ich dem Ding denn noch mehr Rechte geben?

Es braucht die Berechtigung, lokal Dateien schreiben zu dürfen. Ob das als erweitertes Recht bezeichnet wird weiß ich nicht, vermutlich schon. Wie gesagt, früher hat dafür ein Eintrag in der lokalen Datei .java.policy vollkommen ausgereicht, das hat super funktioniert. Und ob das Teil arbeitet sehe ich 1. an der Java Konsole, es schreibt nämlich immer Debug Ausgaben und 2. am Ergebnis, die zu schreibende Datei ist nicht vorhanden.

Frage: Kann das am Applet selbst auch noch liegen? Als das Ding erstellt wurde hat ja noch keiner an Signierung o.ä. gedacht. Es ist aus Oktober 2011!

*** Edit ***

OK, ich habe eben mal eine isolierte Testseite erstellt, weil ich eigentlich gern mal gemäß Error | OPNsense den appletviewer probieren wollte. Aber soweit kam ich garnicht, denn es kommt folgende Meldung:

Diese Meldung hab ich vorher nicht gesehen, weil das Applet normalerweise mit width=1 und height=1 eingebunden ist :frowning:

Was fange ich mit dieser Meldung an? Mir war schon nach Studium einiger anderer Tuts aufgefallen, dass mein Applet kein „package“ Kommando hat. Es fängt mit diesen Zeilen an:

import java.awt.*;
import java.awt.event.*;
/*import javax.swing.*;*/
import javax.swing.JApplet;
import java.net.*;
/*import sun.misc.BASE64Decoder;*/
import java.util.Arrays;
/*import java.util.prefs.Base64;*/

public class localfile extends JApplet{```

Wie bekomme ich denn die Fehlermeldung "ClassNotFound" weg?
Ich glaube, wir nähern uns dem Ziel langsam :)

Zähle die .class-Dateien…

Denkbar. Es kann aber auch an der JRE-Version liegen. Welche JRE-Version und welchen Browser benutzt du? 32- oder 64 Bit? Die 64-Bit-Version macht Probleme in einem 32-Bit Browser.
Genauso gut kann es sein, dass das Applet nicht korrekt in die Webseite eingebunden wurde.

Ist 1

C:>java -version
java version „1.7.0_51“
Java™ SE Runtime Environment (build 1.7.0_51-b13)
Java HotSpot™ 64-Bit Server VM (build 24.51-b03, mixed mode)

Ist das die 64Bit Version? Oder ist die unterste Bezeichnung was anderes?

Mit Browser Firefox 28.0 auf Win 7 64Bit Pro.
Aber Firefox ist glaube ich 32 Bit, oder? Also müsste ich das 32Bit JRE auch noch installieren oder lieber nicht?

Im IE11 tut sich weder in der 64Bit noch in der 32Bit Version etwas.
Es steht nur:

Schauen, ob es startet…

Es geht nichtmal das Kästchen für das Applet auf. Garnichts.
Ist auch nicht richtig, oder?

Das ist meine Testseite, die den Fehler im Firefox hervorruft und im IE11 garnichts tut außer „Schauen, ob es startet…“ anzuzeigen:

<!DOCTYPE html>
<html>
	<head>
		<title>Testseite Java Applet localfile</title>
		<meta http-equiv="content-type" content="text/html;charset=UTF-8">
	</head>

	<body>
		<div>Schauen, ob es startet...</div>

		<object codebase="/develop" archive="localfile.jar" classid="java:localfile.class" codetype="application/java-vm" width="1000" height="100" border="1">
			<param name="numFiles" value="1">
			<param name="FileContent1" value="xyz">
			<param name="FileName1" value="d:	est.txt">
			<param name="ReturnURL" value="http://fritz.box">
			<param name="SuccessParameters" value="erg=J">
			<param name="FailureParameters" value="erg=N">
		</object>

	</body>
</html>

Sehr unsicher bin ich mir beim Attribu classid. Den hab ich nur abgeschrieben aus irgendeinem Tut. Vorher hatte ich das ja immer mit dem Tag eingebunden. Ich weiß nicht, was jetzt richtig ist. Die alte Variante mit funktioniert auch nicht. Applet tut seine Arbeit auch nicht.

Du kannst die 32-Bit-Version der JRE mal nachinstallieren und im Appletviewer testen.
Beim Object-Tag bin ich mir gerade nicht sicher. Ich habe kürzlich 3 Varianten gesehen. Welche davon die Richtige ist, kann ich nicht sagen. Da muss ich mich auch erst mal schlau machen.

Versuche mitte noch mal das Applet-Tag, auch wenn es veraltet ist. Wenn auch nur zum Testen.
Der Firefox blockt Applets seit einigen Versionen komplett. Da musst du dann auch mal die Einstellungen durchforsten.

Edit
Den DOCTYPE darfst du dann aber nicht auf HTML5 setzen, das unterstützt das Applet-Tag gar nicht mehr.

Edit
Kann ich aber nicht bestätigen. Bei mir laufen Applets auch in HTML5-Seiten mit dem Applet-Tag.

Wenn ich das Applet mit <object codebase="/develop" archive="localfile.jar" classid="java:localfile.class" codetype="application/java-vm" width="1000" height="100" border="1"> aufrufe kommt:

Warnung: F³r -Tag ist ein „code“-Attribut erforderlich.

Wenn ich das Attribut code=„localfile.class“ ergänze kommt:

Laden: Klasse localfile.class nicht gefunden.

Das wäre super nett von dir. Ich experimentiere parallel auch rum.

Hab ein paar Versuche gemacht aber der Firefox verhält sich gleich, egal ob applet oder object, immer wie in #21 gezeigt.
Und der IE (egal ob 32 oder 64Bit) auch, der startet aber zusätzlich wenigstens noch die Javakonsole, das hab ich in den Java Einstellungen so festgelegt.

Der Firefox blockt Applets seit einigen Versionen komplett. Da musst du dann auch mal die Einstellungen durchforsten.

OK, da ich das Applet aber ohnehin in einem iFrame lade könnte ich durchaus den DOCTYPE anpassen, falls das das ganze zum Laufen bringt. Hab unten mal eine Variante getestet, ist die korrekt? Oder lieber die strict Variante?

Hier meine vorläufigen Erkenntnisse:

Konfig                     Firefox     IE11 32Bit    IE11 64Bit    Appletviewer
=============================================================================================
JRE 64Bit <applet>           E3          E6            E6             E4
JRE 64Bit <object>           E1          E3            E3             E5


-----------
Ergebnisse:

E1 = 1000x100 Rahmen wird gezeigt, bei Klick auf "Fehler. Klicken Sie hier, um weitere Informationen zu erhalten" erscheint Popup mit "ClassNotFoundException localfile.jar"
E2 = wie E1 aber es startet wenigstens das Java Symbol im Systray und die Java Konsole öffnet sich (hab ich bei mir so eingestellt)
E3 = Zeigt nur den Text aus der Testdatei "Schauen, ob es startet" ansonsten keinerlei Regung bezüglich Java, auch kein Rahmen zu sehen, keine Fehlermeldung, nichts in der Entwicklerkonsole (F12)
E4 = Appletkasten geht auf, darin steht "Starten: Applet nicht initialisiert", in der DOS-Box:
     Laden: Klasse localfile.class nicht gefunden.
     java.lang.ClassNotFoundException: localfile.jar
        at sun.applet.AppletClassLoader.findClass(AppletClassLoader.java:219)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
        at sun.applet.AppletClassLoader.loadClass(AppletClassLoader.java:152)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
        at sun.applet.AppletClassLoader.loadCode(AppletClassLoader.java:633)
        at sun.applet.AppletPanel.createApplet(AppletPanel.java:793)
        at sun.applet.AppletPanel.runLoader(AppletPanel.java:722)
        at sun.applet.AppletPanel.run(AppletPanel.java:379)
        at java.lang.Thread.run(Thread.java:744)
E5 = Warnung: F³r <object>-Tag ist ein "code"-Attribut erforderlich.
E6 = Zeigt den Text aus der Testdatei "Schauen, ob es startet" und startet die Java Konsole, Java Applet wird jedoch nicht gestartet

Die Applet Variante:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
	<head>
		<title>Testseite Java Applet localfile</title>
		<meta http-equiv="content-type" content="text/html;charset=UTF-8">
	</head>

	<body>
		<div>Schauen, ob es startet...</div>

		<applet width="1" height="1" code="localfile.class" codebase="/develop">
			<param name="numFiles" value="1">
			<param name="FileContent1" value="xyz">
			<param name="FileName1" value="d:	est.txt">
			<param name="ReturnURL" value="http://fritz.box">
			<param name="SuccessParameters" value="erg=J">
			<param name="FailureParameters" value="erg=N">
		</applet>

	</body>
</html>

Die object Variante ist noch wie in Beitrag #23.

Einmal muss ich noch nachhaken, nachdem ich deinen Applet-Tag gesehen habe. Das Applet ist doch in eine Jar-Datei gepackt und signiert worden. Dann musst du auch das archive-Attribut benutzen. Ansonsten wird das Applet nicht als signiert angesehen oder die einzelne class-.Datei wird nicht gefunden.

Außerdem benutzt du das codebase-Attribut. Liegt das Applet also in einem Verzeichnis “develop” unterhalb von deiner HTML-Datei?

OK, das bringt eine neue Ergebnisart hervor:

Konfig                     Firefox     IE11 32Bit    IE11 64Bit    Appletviewer
===============================================================================
JRE 64Bit <applet>           E7          E7            E7             E4

E7 = Erstes Sicherheits-Popup geht auf, danach tut sich trotz Klick auf "Ausführen" nichts mehr, kein Rahmen des Applets zu sehen

Nach Korrekturen sieht die Seite jetzt so aus:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
	<head>
		<title>Testseite Java Applet localfile</title>
		<meta http-equiv="content-type" content="text/html;charset=UTF-8">
	</head>

	<body>
		<div>Schauen, ob es startet...</div>

		<applet width="1" height="1" code="localfile.class" archive="localfile.jar">
			<param name="numFiles" value="1">
			<param name="FileContent1" value="xyz">
			<param name="FileName1" value="d:	est.txt">
			<param name="ReturnURL" value="http://fritz.box">
			<param name="SuccessParameters" value="erg=J">
			<param name="FailureParameters" value="erg=N">
		</applet>

	</body>
</html>

Nicht ganz, beides liegt im selben Verzeichnis. Hab das codebase mal rausgenommen, Ergebnis siehe oben, E7.

Hast du Ausgaben in der Java-Console?
Wie sieht es aus, wenn du das Ganze mit dem Appletviewer startest?

Nein

Siehe E4

E4 = Appletkasten geht auf, darin steht "Starten: Applet nicht initialisiert", in der DOS-Box:
     Laden: Klasse localfile.class nicht gefunden.
     java.lang.ClassNotFoundException: localfile.jar
        at sun.applet.AppletClassLoader.findClass(AppletClassLoader.java:219)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
        at sun.applet.AppletClassLoader.loadClass(AppletClassLoader.java:152)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
        at sun.applet.AppletClassLoader.loadCode(AppletClassLoader.java:633)
        at sun.applet.AppletPanel.createApplet(AppletPanel.java:793)
        at sun.applet.AppletPanel.runLoader(AppletPanel.java:722)
        at sun.applet.AppletPanel.run(AppletPanel.java:379)
        at java.lang.Thread.run(Thread.java:744)

Da hat sich aber nach der Benutzung des archive-Attribut im applet-Tag nichts verändert. Hier passt einfach nichts zusammen.
Kannst du mir die Klasse mal zusenden, ich würde das gerne mal selbst probieren.

Wo darf ich das denn hinschicken? Hier im Forum kann man an PN’s keine Attachments hängen wenn ich nichts übersehen habe.

Alles klar, habe deine Mail erhalten.
Ich musste nach 2-3 Tests feststellen, dass die Sicherheitsmaßnahmen für Applets drastisch verändert wurden. Im Manifest sind nun noch weitere, bisher im Wiki nicht dokumentierte, Einträge notwendig, um das Applet zum Laufen zu bringen.
Da ist also auf jeden Fall auch noch mal eine Überarbeitung des Wikis meinerseits notwendig. Da muss ich nochmal die aktuellen Dokus lesen.
Ich kümmere mich darum und informiere dich hier über die Fortschritte. In den nächsten Tagen solltest du ein lauffähiges Applet erhalten.

Du bist super, vielen Dank für deine Hilfe!
Bin sehr gespannt.

Sooo. Im Wiki sind nun ein neuer und zwei aktualisierte Beiträge zum Thema Applets, signieren und einbinden veröffentlicht, die Applets nach Java 7 Update 51 behandeln.
Ich habe alles selbst ausprobiert. So wie es dort geschrieben steht, sollte es funktionieren. In den nächsten Tagen kommen noch einige Bilder und Ergänzungen hinzu. Dann ist die Sache rund und nahezu vollständig.

Falls jemand da noch Fehler findet oder Probleme beim Signieren und Einbinden hat, kann er gerne seine Fragen loswerden.

Moin,

neben den dort beschriebenen Möglichkeiten besteht noch die Möglichkeit des Aufbaues einer eigenen Public Key Infrastruktur (PKI). Insbesondere firmenintern skaliert das besser, da nur das firmeneigene Wurzelzertifikat auf die Firmenrechner ausgerollt werden muss. Dabei kann Java auch so angepasst werden, das bei bedarf nur noch der eigenen Zertifizierungsstelle vertraut wird.

Auch während der Entwicklung kann das nützlich sein, da das Verhalten genau dem eines kommerziellen Zertifikates entspricht.

Das Vorgehen wäre beispielsweise:

  1. Die Zertifizierungsstelle aufsetzen (OpenSSL muss installiert sein)
  • Dateien und Verzeichnisse anlegen:
X:\>mkdir CA
X:\>cd CA
X:\CA>mkdir certs
X:\CA>touch index
X:\CA>echo 01 > serial
  • openssl.conf anlegen und anpassen:
[ ca ]
default_ca      		= ca_default


[ ca_default ]
dir             		= X:/CA
private_key     		= $dir/ca.key
certificate     		= $dir/ca.pem
database        		= $dir/index
serial				= $dir/serial
new_certs_dir			= $dir/certs/
default_days    		= 1095
default_crl_days        	= 365
default_md      		= sha512
policy          		= policy
x509_extensions 		= v3_usr


[ policy ]    
commonName              	= supplied     
     


[ req ]
distinguished_name      	= req_distinguished_name


[ req_distinguished_name ]
commonName                      = Common Name (eg, YOUR name)


[ v3_ca ]
subjectKeyIdentifier 		= hash
authorityKeyIdentifier 		= keyid:always, issuer:always
basicConstraints 		= CA:true
crlDistributionPoints		= URI:http://mschorn.net/crl.pem


[ v3_usr ]
subjectKeyIdentifier 		= hash
authorityKeyIdentifier 		= keyid:always, issuer:always
basicConstraints 		= CA:false
nsCertType  			= server, client, email
keyUsage 			= nonRepudiation, digitalSignature, keyEncipherment
crlDistributionPoints		= URI:http://mschorn.net/crl.pem


[ v3_code_sign ]
subjectKeyIdentifier 		= hash
authorityKeyIdentifier 		= keyid:always, issuer:always
basicConstraints 		= CA:false
nsCertType  			= client, email, objsign
keyUsage 			= digitalSignature
extendedKeyUsage 		= codeSigning, msCodeInd, msCodeCom
crlDistributionPoints		= URI:http://mschorn.net/crl.pem
  • Schlüssel und Wurzelzertifikat der CA erzeugen:
X:\CA>openssl req -config openssl.conf -extensions v3_ca -x509 -days 3650 -newkey rsa:4096 -keyout ca.key -out ca.pem
Generating a 4096 bit RSA private key
[..]
writing new private key to 'ca.key'
Enter PEM pass phrase: catest
Verifying - Enter PEM pass phrase: catest
[..]
Common Name (eg, YOUR name) []:Foobar Enterprise CA
  • eine leere Widerrufsliste (CRL) erzeugen:
X:\CA>openssl ca -config openssl.conf -gencrl -out crl.pem
Using configuration from openssl.conf
Enter pass phrase for X:/CA/ca.key: catest

Diese CRL muss an der in der openssl.conf angegebenen Adresse veröffentlicht werden, sonnst wirft Java später eine Warnung.

  • das Wurzelzertifikats PEM zum CER umwandeln:
X:\CA>openssl x509 -in ca.pem -outform der -out ca.cer
  • das Wurzelzertifikat in die Java cacerts importieren:
X:\CA>keytool -import -keystore "C:\Program Files\Java\jre8\lib\security\cacerts " -trustcacerts -alias foobarenterprise -file ca.cer
Enter keystore password: changeit
Owner: CN=Foobar Enterprise CA
[..]
Trust this certificate? [no]:  yes
Certificate was added to keystore

Das Java Default Passwort für die cacerts lautet: changeit. Um die cacerts verändern zu dürfen, muss der Befehl mit Administratorrechten ausgeführt werden. Je nach Nutzerkreis kann entweder die ca.cer oder direkt die cacerts ausgerollt werden. Die cacerts kann bei bedarf ausgemistet werden, so das nur noch der eigenen Zertifizierungsstelle vertraut wird.

Wenn Java mehrmals installiert ist, sollte die cacerts von jeder Installation angepasst werden (z.B. bei 32 Bit / 64 Bit).

  1. Das eigentliche Code Sign Zertifikat erstellen:
  • Schlüssel und Zertifikatrequest erstellen:
X:\CA>openssl req -config openssl.conf -new -newkey rsa:2048 -keyout foobar.key -out foobar.csr
Generating a 2048 bit RSA private key
[..]
Enter PEM pass phrase: mypass
Verifying - Enter PEM pass phrase: mypass
[..]
Common Name (eg, YOUR name) []:Foobar Development
  • das Zertifikatrequest signieren:
X:\CA>openssl ca -config openssl.conf -extensions v3_code_sign -in foobar.csr -out foobar.pem
Using configuration from openssl.conf
Enter pass phrase for X:/CA/ca.key: catest
[..]
Sign the certificate? [y/n]:y
[..]
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated
  • Schlüssel und Zertifikat zu einer P12 Datei vereinigen:
X:\CA>openssl pkcs12 -export -out foobar.p12 -inkey foobar.key -in foobar.pem -certfile ca.pem
Enter pass phrase for foobar.key: mypass
Enter Export Password: mypass
Verifying - Enter Export Password: mypass
  • P12 zu einem JKS umwandeln:
X:\CA>keytool -importkeystore -srckeystore foobar.p12 -srcstoretype PKCS12 -alias 1 -destkeystore foobar.jks -destalias foobar
Enter destination keystore password: testtest
Re-enter new password: testtest
Enter source keystore password: mypass
  1. Das Applet:
  • minimales Beispiel:

import java.awt.BorderLayout;


@SuppressWarnings("serial")
public class HelloWorld extends JApplet {

    public HelloWorld() {

        getContentPane().add(new JLabel("Hello World!"), BorderLayout.NORTH);

    }

}```

- bauen und signieren mit Maven:

<?xml version="1.0" encoding="UTF-8"?>


4.0.0
foobar
applet
0.0.1-SNAPSHOT

<properties>
	<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>

<build>

	<finalName>applet</finalName>

	<plugins>
		<plugin>
			<groupId>org.apache.maven.plugins</groupId>
			<artifactId>maven-compiler-plugin</artifactId>
			<version>3.1</version>
			<configuration>
				<source>1.7</source>
				<target>1.7</target>
			</configuration>
		</plugin>

		<plugin>
			<groupId>org.apache.maven.plugins</groupId>
			<artifactId>maven-jar-plugin</artifactId>
			<version>2.4</version>
			<configuration>
				<archive>
					<addMavenDescriptor>false</addMavenDescriptor>
					<manifest>
						<addDefaultImplementationEntries>true</addDefaultImplementationEntries>
					</manifest>
					<manifestEntries>
						<Sealed>true</Sealed>
						<Permissions>sandbox</Permissions>
						<Codebase>*</Codebase>
					</manifestEntries>
				</archive>
			</configuration>
		</plugin>

		<plugin>
			<groupId>org.apache.maven.plugins</groupId>
			<artifactId>maven-jarsigner-plugin</artifactId>
			<version>1.3.2</version>
			<executions>
				<execution>
					<id>sign</id>
					<phase>package</phase>
					<goals>
						<goal>sign</goal>
					</goals>
				</execution>
			</executions>
		</plugin>

	</plugins>

</build>
```
  • settings.xml:
<?xml version="1.0" encoding="UTF-8"?>
<settings xmlns="http://maven.apache.org/settings/1.0.0"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd">

	<profiles>
		<profile>

			<id>foobar</id>

			<properties>
				<jarsigner.keystore>X:/CA/foobar.jks</jarsigner.keystore>
				<jarsigner.alias>foobar</jarsigner.alias>
				<jarsigner.storepass>testtest</jarsigner.storepass>
				<jarsigner.keypass>mypass</jarsigner.keypass>
			</properties>


		</profile>
	</profiles>

	<activeProfiles>
		<activeProfile>foobar</activeProfile>
	</activeProfiles>

</settings>
mvn install
  • die HTML Datei:
<!DOCTYPE html>
<html lang="en">
<head><title>Hello World</title></head>
<body>

    <script src="https://www.java.com/js/deployJava.js"></script>
    <script> 
        var attributes = { code:'will.be.ignored',  width:300, height:300} ; 
        var parameters = { jnlp_href: 'applet.jnlp'} ; 
        deployJava.runApplet(attributes, parameters, '1.7'); 
    </script>
    
</body>
</html>
  • die zugehörige JNLP:
<?xml version="1.0" encoding="UTF-8"?>
<jnlp href="applet.jnlp">
	<information>
		<title>HelloWorld</title>
		<vendor>Foobar</vendor>
	</information>
	<update check="always" policy="always"/>
	<resources>
		<java version="1.7+" href="http://java.sun.com/products/autodl/j2se" initial-heap-size="64m" max-heap-size="128m"/>
		<jar href="applet.jar" main="true"/>
	</resources>
	<applet-desc 
		name="HelloWorld" 
		main-class="foobar.HelloWorld"
		width="300"
        height="300">
	</applet-desc>
</jnlp>
  • vor dem Start des Applet erscheint derselbe Dialog wie bei einem kommerziellen Zertifikat:

So läuft das Applet ganz normal innerhalb der Sandbox. Damit es ohne Sandbox läuft, muss das Permissions Attribute im Manifest geändert werden und die JNLP um ein

  <security>
      <all-permissions/>
  </security>

ergänzt werden.

Viele Grüße
Fancy

Super! Danach habe ich noch gesucht.
Kannst du das noch ins Wiki einbauen, oder darf ich das so dorthin übernehmen?

Das kannst Du gerne dorthin übernehmen. Gut wäre es, wenn Du dabei auch noch die urls von mir (das mschorn.net) auf was neutraleres von z.B. byte-welt.net ändern könntest.

Viele Grüße
Fancy

Klar, kann ich machen.

@Fancy : Ich bräuchte noch ein wenig Unterstützung.
Ich habe unter Linux deine Anleitung nahezu komplett nachvollzogen. Allerdings hänge ich nun bei dem Teil, bei dem es um Maven geht. Ich habe mit Maven noch nicht gearbeitet.
-Wo müssen die Dateien abgelegt werden? (Bauen und signieren (welchen Namen muss die Datei erhalten?), settings.xml)
-Brauche ich maven oder maven2 ?
-In welchem Verzeichnis muss ich beim Aufruf von mvn install stehen?

Unter Windows wird der Befehl touch nicht erkannt…

-Wo müssen die Dateien abgelegt werden?

Folgende Ordnerstruktur sollte passen:

MeinAppletProjekt (Oder ein beliebiger anderer Name)
-> src
--> main
---> java
----> foobar
-----> HelloWorld.java
-> pom.xml

Die pom.xml ist die Datei unter dem Punkt „- bauen und signieren mit Maven:“
Die settings.xml Datei liegt hier: ${user.home}/.m2/settings.xml
Den Befehl mvn install führt du im „MeinAppletProjekt“-Ordner aus wo die pom.xml Datei liegt.

Bei der Maven Version würde ich hier rauf zurückgreifen: Maven – Download Apache Maven da die Version im Repo veraltet ist.

Unter Windows wird der Befehl touch nicht erkannt…

Versuch unter Windows mal folgendes: type NUL > index
Das sollte eine leere Datei erstellen.