0

En raison de contraintes de conception, le projet sur lequel je travaille actuellement ne nous permettra pas d'écrire certains paramètres de configuration dans un fichier texte tel que les fichiers de propriétés (principalement en raison de contraintes de sécurité).Conception de configuration non accessible

Est-il possible de cacher ces paramètres de configuration pour qu'ils soient simplement accessibles aux programmeurs de code. Un simple objet Java est jusqu'à présent ma seule idée.

En outre, il convient de noter que les valeurs codées en dur ne sont pas une bonne solution pour nous, étant donné que de nombreuses «sous-applications» requièrent leur propre configuration. À ce stade, considérez une sorte de groupe de ressources, mais cela aura toujours le problème original.

EDIT: Je suis tombé sur Jasypt comme here proposé, néanmoins je pense que pour mon cas sauver ce dans une sorte de fichier obfuscation est suffisant car il est tout ce que nous devons pour faire l'arrêt de l'utilisateur altérer la configuration des dossiers.

+1

La sécurité à travers l'obscurité est toujours une mauvaise idée, si c'est ce que vous entendez par «dissimuler». Vos valeurs cachées seront révélées, avec du temps et des efforts. Si tel est le cas, nous avons probablement besoin de plus d'informations sur l'architecture, afin de voir si quelque chose de mieux est possible. Vous pouvez lire plus ici: https://stackoverflow.com/questions/533965/why-is-security-through-obscurity-a-bad-idea – jackgu1988

+0

Eh bien c'est une sorte de sécurité par l'obscurité. Donc, l'affaire est que nous avons un serveur qui agit comme et moteur pour d'autres applications. Afin de déployer l'application, nous devons écrire un ensemble de configurations. Ensuite, le code est déployé dans un fichier war sur nos serveurs clients. La situation est que parfois ou les clients o entourant nos clients altèrent cette configuration ouverte et causent beaucoup de maux de tête. C'est pourquoi nous voulons que la configuration soit obscure une fois l'application déployée. – jfzr

+0

Ok, je vois. Le problème est que si quelqu'un veut, donner un sens à un fichier obfusqué est toujours possible. En fait, si quelque chose est entre les mains d'un utilisateur, il peut être fissuré. Il n'y a pas de sécurité parfaite, mais l'obfuscation est loin d'être une bonne sécurité. Je vous suggérerais de vérifier si les fichiers de guerre peuvent être générés en fonction d'une certaine configuration (se débarrasser de tout le code non pertinent), plutôt que de fonctionner selon une certaine configuration, si cela a du sens. – jackgu1988

Répondre

0

utilisation environment variables:

String value = System.getEnv(myKey); 

qui sont définies à l'OS via export foo=bar (* nix) ou SET foo=bar (fenêtres), ou des propriétés du système:

String value = System.getProperty(myKey); 

qui sont définies sur la commande java ligne, par exemple java -DmyKey=myValue ...

+0

Pas vraiment une bonne idée, car il permettra de réduire la portabilité de mon code et la configuration est toujours facilement accessible. – jfzr