[JAVA] Paramètre de stratégie pour exécuter des applets obsolètes Notes de combat

Même si Java 11 est sorti et que l'ère où les pommes ne peuvent pas être utilisées est arrivée, il existe toujours une demande pour les pommes Java pour réaliser de nouvelles fonctions. Il y a plusieurs raisons de vouloir utiliser une applet, mais la plupart sont "Je veux effectuer un traitement natif à partir de JavaScript". Dans de tels moments, je ne suis pas le seul à être toujours accro aux paramètres d'environnement liés à la sécurité. Je ne veux pas vraiment utiliser d'applets, mais j'ai dû faire des compromis et les utiliser, et le stress de passer du temps dans les paramètres d'environnement n'est pas écrasant. Puisqu'une telle expérience suffit une fois, je vais résumer les points addictifs que j'ai rencontrés ici afin de ne pas rencontrer une telle expérience à l'avenir.

mauvaise configuration de java.policy

Les pommes peuvent effectuer un traitement natif qui ne peut pas être effectué avec JavaScript. Ceux qui le pensent devraient être prudents. Même une applet ne peut pas s'exécuter sans aucune restriction, vous devez donc définir une exception de sécurité dans $ JRE_HOME / lib / security / java.policy. Si vous ne le faites pas, vous obtiendrez une exception d'exécution lorsque vous tenterez d'effectuer un traitement natif (comme l'écriture d'un fichier) à partir d'une applet.

Si vous voulez que cela fonctionne pour le moment, accordez toutes les autorisations java.security.AllPermission; à toutes les entrées.

grant {
	permission java.security.AllPermission;
}

Limité par codeBase

Si vous souhaitez définir uniquement pour une entrée spécifique, écrivez codeBase. La spécification change selon qu'elle est placée sur un lecteur local ou téléchargée à partir du Web et exécutée. Pour plus de détails, reportez-vous à la documentation officielle Java.

https://docs.oracle.com/javase/jp/8/docs/technotes/guides/security/PolicyFiles.html

Restreint par permission

Si vous ne voulez donner que des privilèges spécifiques, spécifiez permission java.security. ~ Nom de classe ~;. Pour plus de détails, reportez-vous à la documentation officielle Java.

https://docs.oracle.com/javase/jp/8/docs/technotes/guides/security/permissions.html

Lecture manquante de java.policy dans java.security

Si java.policy est décrit correctement mais que les paramètres ne sont pas reflétés, vérifiez si java.policy est lu en premier lieu. L'ordre de lecture est très important car java.policy divise la définition en plusieurs fichiers et écrase les paramètres dans l'ordre de lecture. Il existe une spécification policy.url.n pour lire java.policy dans $ JRE_HOME / lib / security / java.security, alors vérifiez ici. Par défaut, cela devrait ressembler à ceci:

policy.url.1=file:${java.home}/lib/security/java.policy
policy.url.2=file:${user.home}/.java.policy

Pour $ {java.home} et $ {user.home}, après avoir démarré l'applet, ouvrez la "console Java" pour vérifier les propriétés, ou créez un programme de confirmation pour vérifier.

System.out.println(System.getProperty("user.home"));

Pour d'autres détails sur «policy.url.n», reportez-vous au document officiel. https://docs.oracle.com/javase/jp/8/docs/technotes/guides/security/PolicyFiles.html#DefaultLocs

Code pour une exécution privilégiée

Si vous obtenez une exception d'autorisation alors que vous avez correctement défini java.policy, assurez-vous que l'applet Java est implémentée avec une exécution privilégiée à l'esprit. Le traitement qui devient une exception de sécurité ne peut être exécuté que si l'APIjava.security.AccessController # doPrivileged pour les blocs privilégiés est utilisée.

Dans un cas courant, je l'ai configuré pour fonctionner dans l'environnement de test (AllPermission est spécifié sans spécifier la base de code dans grant), mais c'est un modèle qui déplore qu'il ne fonctionne pas dans l'environnement de production. Puisqu'il semble qu'il a cessé de fonctionner simplement parce que java.policy a changé, il est mal compris que «java.policy est faux», mais l'implémentation de l'applet est en fait mauvaise.

public class SampleApplet extends Applet {
	public void hoge() {
		AccessController.doPrivileged(new PrivilegedAction<Object>() {
			@Override
			public Object run() {
				//Traitement nécessitant une autorisation
				//new Robot().createScreenCapture etc.
				return null;
			}
		});
	}
}

Le document officiel sur les blocs privilégiés est ↓↓ https://docs.oracle.com/javase/jp/8/docs/technotes/guides/security/doprivileged.html