Ich schaue auf ein signiertes Applet, das stark von JavaScript aufgerufen wird. Offensichtlich sind die Threads, die aus JavaScript stammen, stärker sandboxed als alle Threads, die direkt aus Java heraus gestartet wurden. Wenn beispielsweise ein JavaScript-Thread das Applet aufruft und etwas protokolliert, das die Protokolldatei zum Rollen bringt, wird eine Sicherheitsausnahme ausgelöst. Jeder Thread, der direkt im Applet gestartet wird, ist von dieser Sicherheitsausnahme nicht betroffen. Die Lösung für log4j besteht darin, den asynchronen Appender zu verwenden.

Aber mit anderen Sicherheitsausnahmen (zum Beispiel der Verwendung von Apache Axis im signierten Applet, aber in einem JavaScript-Thread) gibt es keine offensichtliche Möglichkeit, einen asynchronen Thread zu haben. Angenommen, ich habe den folgenden Code, der funktioniert, wenn er von einem Java-Thread aufgerufen wird, und wenn er über JavaScript aufgerufen wird, schlägt er mit einer SecurityException fehl:

public void someMethodCalledFromJavaScript() {
  // Stuff that would throw a SecurityException
}

Ich sehe drei folgende Optionen, aber möglicherweise sind nicht alle gültig. Ignorieren Sie für diese Diskussion, ob die Ausführung synchron oder asynchron sein wird, da dies leicht zu handhaben ist. Es fällt mir schwer, die Details des Sicherheitsmodells zu verstehen. Hier sind meine drei möglichen Entscheidungen:

Starte einen neuen Thread (funktioniert dieser überhaupt?):

public void someMethodCalledFromJavaScript() {
  new Thread(new Runnable() {
    public void run() {
      // Stuff that would throw a SecurityException
    }
  }).start();
}

Hat das Applet einen Thread, der jederzeit einsatzbereit ist und über den JavaScript-Ursprungsthread ausgelöst wird (hier stark vereinfachter Code):

private volatile boolean doit = false;

// This code is running in a Thread, started @ Applet init time
public void alwaysWaiting() {
  while (true) {
    if (doit) {
      doit = false;
      // Stuff that would throw a SecurityException
    }
  }
}

public void someMethodCalledFromJavaScript() {
  doit = true;
}

Verwenden Sie AccessController.doPrivileged:

public void someMethodCalledFromJavaScript() {
  AccessController.doPrivileged(new PrivilegedAction() {
    public Object run() {
      // Stuff that would throw a SecurityException
      return null;
    }
  });
}

Nach dem, was ich gelesen habeAccessController.doPrivileged, Sie werden mit dem Schnittpunkt der aktuellen Sicherheits-Privilegien und der Privilegien der Sicherheitsdomäne des von Ihnen aufgerufenen Codes ausgeführt. Das ergibt für mich keinen Sinn, als ob du mit dem @ rennÜberschneidun einer niedrigen und einer hohen Sicherheitsdomäne haben Sie nur die niedrige Sicherheitsdomäne. Also verstehe ich etwas nicht.

Das spezifischeSecurityException Ich sehe, ist dies:

java.security.AccessControlException: access denied (java.lang.RuntimePermission accessDeclaredMembers)

aber natürlich bin ich neugierig auf den allgemeinen Fall, dass JavaScript ein signiertes Applet aufruft, und wie ich zulassen kann, dass ein mit JavaScript erstellter Thread mit den Privaten des signierten Applets ausgeführt wird, als wäre es ein Thread, der seinen Ursprung hat rein im Applet.

Welche Auswahlmöglichkeiten funktionieren sogar und welche sind besser als andere und warum.