configuration source de données dans l'application autonome lors de l'utilisation Hibernate

Question

Je me demande, où nous stockons la config de base de données dans l'application autonome.Le client est directement connecté à la base de données (je sais que ce n'est pas une bonne idée, mais je ne suis pas autorisé à créer un serveur ou ouvrir un nouveau port pour RMI)

Je ne veux certainement pas ouvrir l'utilisateur fichier Hibernate config xml et obtenir tous les détails (nom d'utilisateur de la base de données & mot de passe etc).

Answer 1

Si votre application client va avoir besoin des détails à la fin, ils seront toujours accessibles à l'utilisateur d'une manière ou d'une autre. Le mieux que vous pouvez faire ici est l'obfuscation des détails. Vous pouvez simplement les encoder en base64 et les stocker dans un fichier de propriétés (pas hibernate.properties), puis les charger vous-même avant d'obtenir une fabrique de sessions. Pour charger les propriétés de configuration, vous pouvez utiliser la classe Configuration.

Si vous cherchez à déjouer un client un peu plus averti, vous pouvez également le crypter et stocker la clé comme champ statique dans votre code. Cela ne le rend pas sûr, mais il est possible que vos clients ne soient pas assez aptes à décompiler la source et à voir par eux-mêmes comment vous décryptez ces choses. N'oubliez pas de consolider la sécurité côté serveur. (Assurez-vous que le compte DB a des privilèges minimaux!) En outre, refuser des services distants mais autoriser un accès direct à la base de données ne me semble pas être une politique très sensée.

Answer 2

Heureusement, vous avez un serveur de répertoire (tout serveur d'application J2EE le fera), puis ouvrez une source de données et utilisez le jndi-lookup de Spring pour le récupérer. A défaut, comme @wds, il s'agit d'informations d'identification cryptées ou d'une invite même à créer des comptes restreints pour chaque utilisateur de la base de données. Je n'ai pas de problème avec l'accès à la base de données côté client - ça a bien fonctionné pendant des années avant l'arrivée de SOA - assurez-vous que les comptes utilisateurs ont seulement des permissions limitées - sélectionnez l'accès uniquement pour les tables -ups à travers des vues (à nouveau avec les autorisations nécessaires) et exécuter sur les procédures requises.