Bonjour à tous,

Par un besoin coté de mon école, je dois développer notemment une application typée "événementielle", et me suis donc tourné vers Java dans ce but (j'avais déjà des notions, l'occasion de creuser un peu plus).

J'ai donc démarré une petite appli, qui communique avec un serveur mysql. J'ai réussi la connexion, là n'est pas le souci.

Non, mon souci c'est lors de la redistribution. Une fois l'application générée (compilée, en somme), et donc prête à être redistribuée, qu'est-ce qui empêche quelqu'un d'aller jeter un oeil dans le code du programme "décompilé", et ainsi avoir les identfiants ?
Ou encore mieux, de se servir de la connexion mysql pour exécuter des requêtes arbitraires ?

Cela me pose un petit souci coté sécurité en ce cas... Ais-je compris quelque chose de travers ?

Merci d'avance,


Lpu8er

Pour les identifiants, regarde du côté d'un "obfuscateur". De plus, par mesure de précaution, tu ne devrais jamais exécuter tes requêtes avec le root: créé un utilisateur avec des droits limités, et utilise le pour les requêtes.

Ensuite, je ne vois pas comment on pourrait injecter des requêtes dans la connexion... À moins que ton application ne sécurise pas ses entrées!

Même comme ça les identifiants seraient récupérables, en général le programme qui accède à la DB se trouve sur une machine sécurisée et on accède à ce programme via un client.

Citation : shakhal

Même comme ça les identifiants seraient récupérables, en général le programme qui accède à la DB se trouve sur une machine sécurisée et on accède à ce programme via un client.

En effet...

C'est un gros problème de Java (remarque, les langages .NET ont le même problème): le bytecode reste lisible par un humain...

Ouep...
Soit tu fais juste le client en Java, et un serveur PHP ou autre, soit tu crées un utilisateur aux droits limités.

C'est ce que je craignais.

Donc grosso modo, il faut que je présente une architecture du type:
- client en Java qui envoie des messages par socket, probablement, à un serveur sur un port bien défini
- service sur le serveur qui tourne en continu, écoutant ce port
Si j'ai bien compris ?

Pour l'utilisateur MySQL... Ce projet est normalement un "chat". J'aurais préféré le faire coté PHP/MySQL avec grosse dose AJAX, mais apparemment il ne faut pas pour le diplôme, mais bref.
Du coup, il faudrait que l'utilisateur ait les droits d'insertion pour les nouveaux messages, lecture pour toutes les tables, modification pour son compte utilisateur, suppression pour la maintenance des tables plus "temporaires"... En gros, utilisateur limité ou non, l'on pourra tout faire avec les identifiants.
Je vais donc me tourner vers la solution "appli client, service serveur".

conflict: Comment ça ?
Ce que je comprends par ce que tu viens de dire, ce serait un système:
Client Java qui fait l'appel de pages PHP distantes (avec paramètres GET, je vois pas mieux) sur un serveur, ces pages faisant echo de quelque chose (retour en XML, par exemple) traité par Java ?
Ce genre de systèmes est-il viable, ou ais-je mal compris ?
Existe-t'il des moyens en Java de faire appel à des pages distantes et d'en récupérer le retour (parce que lire et analyser du XML, je me doute qu'il y a) ?

Merci d'avance,


Lpu8er

tu peux éviter les socket en utilisant par exemple rmi ou des web services.

Sinon tu peux très bien faire une application uniquement serveur et le client sera un navigateur web, pour ça tu as les servlets/jsp (ou des framework si tu as le temps d'en apprendre un).

Ou encore que le serveur soit une application très minime qui ne serve qu'à t'envoyer les identifiants DB pour te connecter directement. (pas terrible mais si jamais tu as des contraintes de temps importante, faut faire avec les moyens du bord).

Citation : shakhal

Sinon tu peux très bien faire une application uniquement serveur et le client sera un navigateur web, pour ça tu as les servlets/jsp (ou des framework si tu as le temps d'en apprendre un).

Hmm... Chaud chaud les framework. C'est pas le temps le problème, c'est la proportion de temps. j'ai plusieurs projets à conduire, et je ne peux pas me permettre d'allouer bien plus de temps à l'un qu'aux autres. Client en navigateur web, les servlets je ne connais pas. J'irais jeter un oeil si la solution ci-dessous est pas possible ou pas viable.

Je reviens donc au système:
- appli client en java qui, à chaque action, fait appel à une page PHP coté serveur
- la page PHP fait les opérations avec la BDD, et écrit du XML
- le XML est lu en tant que retour par l'application client (puisque c'est le contenu de la page), et analysé pour afficher le tout coté client

Cela est-il viable, et/ou possible ?

Citation : shakhal

Ou encore que le serveur soit une application très minime qui ne serve qu'à t'envoyer les identifiants DB pour te connecter directement. (pas terrible mais si jamais tu as des contraintes de temps importante, faut faire avec les moyens du bord).

Non, cela pose un problème encore plus grand, car il suffirait qu'une personne fasse l'appel de la page pour avoir le identifiants.

Citation : shakhal

tu peux éviter les socket en utilisant par exemple rmi ou des web services.

C'est quoi les RMI concrètement ?

Citation : Lpu8er

Citation : shakhal

tu peux éviter les socket en utilisant par exemple rmi ou des web services.

C'est quoi les RMI concrètement ?

Remote Method Invocation. Version Java du Remote Procedure Call, ou RPC. Un bon exemple de RPC: COM (Component Object Model), sur lequel Windows est bâti.

En gros, ça te permet de représenter un serveur comme un objet, et les requêtes vers ce serveur comme des appels de méthodes.

Je tourne les coins ronds, mais c'est à peu près ça.

Si tu as peur pour une question de sécurité, tu peux effectivement te tourner vers les rmi

Citation : Pas de titre

C'est quoi les RMI concrètement ?

Les RMI te permettent de communiquer entre 2 PC (ou plus) sans avoir besoin d'internet (ni de serveur vu que sur le pc qui va te servir de serveur ). Tu utilise ton reseau local.

Ce qui te donne :

PC Client (IHV avec appel des methodes sur le serveur) <-------> PC Serveur (récupère les informations du client et fait les traitements dans la base)

Ça te permet d'avoir un client sans aucun code d'accès à ta DB

EDIT :
Ca permet surtout d'avoir une seule DB pour X client

Citation : Pas de titre

le bytecode reste lisible par un humain...

Les chaines de caractère codées en dur surtout. Mais rien ne t'empêche de coder une méthode d'encryptage

Citation : cryosore94

Si tu as peur pour une question de sécurité, tu peux effectivement te tourner vers les rmi

Citation : Pas de titre

C'est quoi les RMI concrètement ?

Les RMI te permettent de communiquer entre 2 PC (ou plus) sans avoir besoin d'internet (ni de serveur vu que sur le pc qui va te servir de serveur ). Tu utilise ton reseau local.

Hein?

Réseau local ou Internet, c'est la même chose. Et ce que tu décris n'est absolument pas différent de ce que les sockets permettent de faire.

Voir mon précédent message.

+1

Local ou internet, ca n'a rien a voir

Citation : Pas de titre

Réseau local ou Internet, c'est la même chose. Et ce que tu décris n'est absolument pas différent de ce que les sockets permettent de faire.

Citation : Pas de titre

Les RMI te permettent de communiquer entre 2 PC (ou plus) sans avoir besoin d'internet (ni de serveur vu que sur le pc qui va te servir de serveur ). Tu utilise ton reseau local.

Est ce que j'ai dis que c'était différent des socket dans mon post ? (d'ailleur je n'en parle même pas)

Citation : Pas de titre

Réseau local ou Internet, c'est la même chose.

Tout à fait. Excuse moi j'ai mal communiqué ce que je voulais dire.
Je voulais dire de la communication avec des objets distribués sur un serveur HTTP (EJB).
Toutes mes confuses

Citation : cryosore94

Tout à fait. Excuse moi j'ai mal communiqué ce que je voulais dire.
Je voulais dire de la communication avec des objets distribués sur un serveur HTTP (EJB).
Toutes mes confuses

J'ai bien peur que les serveurs http ne fassent pas conteneur d'ejb, faut une implémentation j2ee pour ça (jboss, websphere, glassfish...).

Citation : Pas de titre

'ai bien peur que les serveurs http ne fassent pas conteneur d'ejb, faut une implémentation j2ee pour ça (jboss, websphere, glassfish...).

tu as pas bientôt fini de me reprendre ?
+1 Pour les serveurs d'applications JBOSS, etc ...

Les réponses données me semblent appropriées mais je me pose juste une toute petite question.

Qu'est-ce-qui t'empêche de créer un utilisateur type "client" sur ta BDD qui n'a que des droits en lecture et insertion sur une seule table (celle contenant les phrases / timestamp du chat) ?

Ou alors ce n'est pas ta question et j'ai rien compris (ce qui est fort possible).

Sinon dans "javax.security" y'a pas des algos de chiffrement symétrique "tout fait" ?

Citation : Javier

Qu'est-ce-qui t'empêche de créer un utilisateur type "client" sur ta BDD qui n'a que des droits en lecture et insertion sur une seule table (celle contenant les phrases / timestamp du chat) ?

Et je fais comment du coup pour le type qui s'inscrit en tant que nouvel utilisateur ?
Pour la création/suppression de conversations ?

De plus même ainsi, si la personne a les identifiants, elle peut facilement faire un petit script d'insertion continu (1000 enregistrements à la seconde, ça se fait), provoquant ainsi au mieux un DoS temporaire (blocage sécuritaire), au pire une saturation de la base et un crash du serveur (donc DoS sur long terme)...

Pour l'algo de sécu, ça ne change rien.
Que j'écrive javax.scurity.crypt("pass") ou "pass", à la décompilo, l'effet sera le même. Je pars du postulat que le réseau est sécurisé.

Faire un client et un serveur le tout en Java me pose un souci. Ou plutôt, perd l'avantage du Client en Java et pages serveurs en PHP. Dans ce dernier cas, rien ne m'empêche de câbler une interface PHP dessus, permettant ainsi une utilisation événementielle "lourde" (installation coté utilisateur, JVM nécessaire mais grande interactivité) et une utilisation "quasi-statique" "légère" (pas d'installation, juste un navigateur, mais peu d'interactivité).
Du coup je pense plutôt m'orienter vers les requêtes HTTP. D'autant plus que les packages pour cela semblent déjà embarqués.

Et ça fait quoi un client en PHP et un serveur en java ou le contraire!!! Parce que Php est plus sécurisé que Java?!!!

nawrasarum: Non, je n'ai pas dit ça. Néanmoins:
- je connais bien mieux PHP que Java
- la structure qui va effectuer les opérations avec MySQL doit être sécurisé
- l'idéal est donc de savoir ce que l'on fait pour sécuriser au mieux

De plus, je pense qu'il est plus simple d'effectuer une requête HTTP basique avec retour XML depuis Java vers PHP, que d'effectuer une communication par sockets entre application Java client / serveur (socket ou via ces RMI qui me semble basés en partie sur les sockets, en passant).

En passant, PHP, Java, pour moi la même coté sécurité. Les failles, ça vient des développeurs principalement...

En fait s'il s'agit d'une application JEE, tu vas travailler selon une architecture 3 tiers, ainsi les couches seront séparées, la couche qui accède à la bd sera à part (DAO ou Bean Session).
L'application sera dans le serveur d'application, l'accès via http (ton navigateur). Bon je parle pas là de RMI (application distribuée) mais d'une application web(pas desktop).
Le serveur d'application n'est pas comme un serveur web à mes connaissances, il gère la sécurité. Jettes un coup d'oeil sur ce lien : Prévenir l'injection SQL avec Java

Citation : Lpu8er

De plus, je pense qu'il est plus simple d'effectuer une requête HTTP basique avec retour XML depuis Java vers PHP, que d'effectuer une communication par sockets entre application Java client / serveur (socket ou via ces RMI qui me semble basés en partie sur les sockets, en passant).

Requête HTTP avec retour XML? Ça ressemble à SOAP, ça.

Citation : Ice_Keese

Requête HTTP avec retour XML? Ça ressemble à SOAP, ça.

Les liens que j'ai trouvé sur le sujet font référence à des techniques que je trouve immondes (utilisation de feuilles excel comme interfaces de communication avec BDD Oracle) mais ça semble effectivement être globalement ça. Après, ça ressemble plus) du protocole qu'à une classe spécifique. dans mon cas, j'utiliserais PHP (donc moteur Apache coté serveur), donc pas vraiment de client à installer, si ce n'est à faire les fichiers PHP, ce qui est simplissime.

Autre détail énervant: je ne trouve que des articles sur comment, depuis PHP, faire appel à un service Java. Etonnant d'ailleurs, étant donné que je trouve les applis Java généralement bien plus riche coté interactivité que les applis PHP (mais bon, ce'st peut-être une opinion de noob en Java).

Pourtant ça me semble simple de faire une requête HTTP en Java.

Je pense que je vais tester avec cette méthode, voire la tête du retour pour savoir si c'est viable ou non.
Je laisse le sujet en non-résolu si cela ne fonctionne pas. En attendant, si vous avez des idées, n'hésitez pas, sachant que je vais également continuer à regarder coté services JBoss, EJB et coté SOAP, des fois que.

Merci encore à tous,


Lpu8er

Petit up pour ceux que cela intéressait: cela fonctionne super bien.

Il a fallu que je recrée le système de "sessions" en me basant sur des IPs et une communication très régulière entre le client et le serveur, afin d'envoyer une seule fois les identifiants de connexion de l'utilisateur.

Truc marrant: à chaque requête HTTP, le port s'incrémente. Oui, oui, vous avez bien lu, et ce même en recompilant.

En tout cas le retour est correct. Je suis quand même en train de regarder pour optimiser l'analyse XML, même si les performances semblent très bonnes.

Maintenant, le gros problème: passer le proxy de l'école pour accéder au serveur de l'école (oui, oui), vu que je vais devoir y faire la démo...
Parce que là, c'est coté protocole HTTP, à mon avis, qu'il faut que je renseigne les éléments nécessaires...