Comment protéger une variable (sécurité) [JAVA] - Java - Programmation
Marsh Posté le 24-08-2004 à 15:38:56
tout ce que tu pourrais dans ce sens là sera faisable à l'envers aussi puisqu'a priori tu enverras de toutes façons le pass en clair à la base, donc un bête debug permettra de chopper le pass.
Marsh Posté le 24-08-2004 à 15:48:23
C moche ca !
J'espérait que java permettait de faire un tour de magie du genre il encapsule la variable dans je ne sais quoi, et qu'il soit le seul à pouvoir en connaitre le contenu.
je revais un peu, mais java m'a tellement surpris jusqu'à présent...
Sinon, si je ne met pas le mot de passe dans une variable, et que je l'écris à chaque requette, ya une chance que ca empeche les gens de le trouver ?
Marsh Posté le 24-08-2004 à 15:49:33
euh ça sera quand même une variable
Marsh Posté le 24-08-2004 à 15:49:42
tuxbleu a écrit : |
à ton avis ?
Marsh Posté le 24-08-2004 à 15:50:32
ReplyMarsh Posté le 24-08-2004 à 15:53:35
benou a écrit : à ton avis ? |
ben ah mon avis non
Citation : ta base est sur le poste de l'utilisateur ? |
non, elle est a distance pour tout le monde. Alors quand on crée un compte ou une partie, quand on rejoint, etc.. , il fo faire des requettes d'écriture.
Marsh Posté le 24-08-2004 à 15:57:52
tuxbleu a écrit : non, elle est a distance pour tout le monde. Alors quand on crée un compte ou une partie, quand on rejoint, etc.. , il fo faire des requettes d'écriture. |
ben il est là ton problême de sécurité : un programme client ne doit jamais accéder directement à la base si les données contenue dans la base sont sensibles.
Il faut passer par un programme hebergé sur le serveur qui sera chargé de gérer les droits d'accès d'un utilisateur (identifié par son propre login/mot de passe, par exemple) aux données de la base => l'appli cliente fait des demandes à l'appli serveur, qui vérifie si le client a le droit d'accéder à ces données et si oui fait les accès en base correspondant et renvoie les données à l'application cliente.
mais ca te fait faire pas mal de modif à ton appli
Marsh Posté le 24-08-2004 à 15:59:12
la j'ai deux possibilités :
1)je diffuse le jeu comme ca, mais la base de données va morfler tres vite.
2)Je renonce à le diffuser, mais ca serait des semaines de travail foutues en l'air
Ou alors, un petit géni du java de hfr me sort de ce bourbier...
Marsh Posté le 24-08-2004 à 16:00:59
ReplyMarsh Posté le 24-08-2004 à 16:03:21
benou a écrit : ben il est là ton problême de sécurité : un programme client ne doit jamais accéder directement à la base si les données contenue dans la base sont sensibles. |
Tout le but de notre projet à l'origine était que malgrès que nous n'avions pas de serveur, nous voulions faire un jeu qui soit jouable par tout le monde, avec des connections par login/mdp.
Ces tables sont indispensable car il faut au moins stocker les parties qui ont été créer pour que d'autres puissent les rejoindres
Marsh Posté le 24-08-2004 à 16:07:43
tuxbleu a écrit : Tout le but de notre projet à l'origine était que malgrès que nous n'avions pas de serveur, nous voulions faire un jeu qui soit jouable par tout le monde, avec des connections par login/mdp. |
Ta bdd va être stockée où si vous n'avez pas de serveurs ?
Marsh Posté le 24-08-2004 à 16:10:15
WhatDe a écrit : Ta bdd va être stockée où si vous n'avez pas de serveurs ? |
on a trouvé un hébergeur qui accepte les requettes à distance.
La le jeu il fonctionne, on est qu'un petit grouoe a voir les sources et à s'en servir. Mais on se tate pour le diffuser. Si on trouve pas de soluce, c mort...
Marsh Posté le 24-08-2004 à 16:24:00
Le principe de fonctionnement du jeu, c'est :
kan tu crée une partie, tu en deviens serveur, et ta partie s'inscrit sur un etable de notre bdd.
Quand un autre joueur se connecte, il voit la liste des partie, et peut choisir d'en rejoindre une. La les informations de la partie lui sont transmise, il essaie de se connecter a toi, et vous avez des lors un chat pour discuter. lorsque vous etes assez nombreux, la partie commence.
Marsh Posté le 24-08-2004 à 16:31:09
bah qques petits scripts php... c'est plus simple à heberger que de trouver un hebergeur (fou) qui accepte les requetes externes...
Marsh Posté le 24-08-2004 à 16:57:52
Je ne vois pas le probleme si ton L/P MySQL ne fait que lire et ecrire sur une table de base donnée tu n'a pas forcement besoin de le proteger, si "des pti malin" comme tu dis voulais se co a ton mysqld bah ils pourraient au pire lire la liste des serveur ( on s'en fou un peu ) soit ecrire X nouvelles parties fictives
( chose qui pouvait etre rendu possible en rejouant une session de connexion de ton client a ce serveur X fois )
Donc je pense ici que c'est plus un probleme au niveau de la limitation des droits dans ton utilisateur mysql.
Marsh Posté le 25-08-2004 à 10:27:48
savory a écrit : Je ne vois pas le probleme si ton L/P MySQL ne fait que lire et ecrire sur une table de base donnée tu n'a pas forcement besoin de le proteger, si "des pti malin" comme tu dis voulais se co a ton mysqld bah ils pourraient au pire lire la liste des serveur ( on s'en fou un peu ) soit ecrire X nouvelles parties fictives |
Il peux aussi changer les mdp des autres joueurs, supprimer des comptes, modifier les scores, détruire les tables... S'il ne s'agissait que des parties, ca serait franchement pas trop grave, il pourrais kom tu dis ajouter des parties fictives, ou supprimer des parties en attentes...ca serait genant, mais sans plus. car une fois la partie commencée, la bdd ne sert plus.
Citation : bah qques petits scripts php... c'est plus simple à heberger que de trouver un hebergeur (fou) qui accepte les requetes externes... |
eu ben j'ai essayé d'executer une requette php qui est sur un espace free depuis mon jeu, ce script php faisant une requette vers des bdd qui sont chez free, et je me suis fé jetté...(j'ai pas le droit de faire des requettes vers des bdd depuis moin compte free apparemment )
Marsh Posté le 25-08-2004 à 10:31:08
tuxbleu a écrit : Il peux aussi changer les mdp des autres joueurs, supprimer des comptes, modifier les scores, détruire les tables... S'il ne s'agissait que des parties, ca serait franchement pas trop grave, il pourrais kom tu dis ajouter des parties fictives, ou supprimer des parties en attentes...ca serait genant, mais sans plus. car une fois la partie commencée, la bdd ne sert plus.
|
Sépare les bdd parties et les sensibles !
Sinon je crois que tu vas encore chercher une solution longtemps
Marsh Posté le 25-08-2004 à 10:37:12
WhatDe a écrit : Sépare les bdd parties et les sensibles ! |
mouis, mais kan un type cré un compte, faut bien ajouter une ligne dans la bdd joueur avec ses caractéristique . fo que j'arive un trouver un espace web ou je puisse faire des requette sur mes bdd...
Marsh Posté le 25-08-2004 à 10:44:58
Il peut créer son compte en dehors du jeu via un browser non ?
Marsh Posté le 25-08-2004 à 10:46:29
Pourquoi tu te prends la tête ? 3 scripts PHP pour gérer les droits et faire les requetes, le tout heberge n'importe où, et ton appli cliente envoie ses requetes sous forme de requetes HTTP...
Marsh Posté le 25-08-2004 à 11:06:53
R3g a écrit : Pourquoi tu te prends la tête ? 3 scripts PHP pour gérer les droits et faire les requetes, le tout heberge n'importe où, et ton appli cliente envoie ses requetes sous forme de requetes HTTP... |
Tu veux dire un truc du genre :
-j'écris mes requettes sur une page php qui effectue des requettes en fonction des variables qu'elle a dans l'url,
-et depuis mon mon appli java, j'exécute cette url ?
Je peux récupérer des objets depuis une requette http ?
Marsh Posté le 25-08-2004 à 11:12:26
tuxbleu a écrit : Tu veux dire un truc du genre : |
Ca depend de ce que tu appelle récupérer des objets. Tu peux facilement envoyer les attributs d'un objet en paramètres de ta requete HTTP.
Marsh Posté le 25-08-2004 à 11:16:30
tuxbleu a écrit : mouis, mais kan un type cré un compte, faut bien ajouter une ligne dans la bdd joueur avec ses caractéristique |
t'as qu'à ouvrir une BDD chez free ... pkoi tu t'embêtes ?
Marsh Posté le 25-08-2004 à 11:20:16
R3g a écrit : Ca depend de ce que tu appelle récupérer des objets. Tu peux facilement envoyer les attributs d'un objet en paramètres de ta requete HTTP. |
j'ai parfois besoin de récupérer le résultat de mes requettes. (information sur les autres joueurs de la partie entre autre).
Et j'ai aussi besoin de savoir si une requette s'est bien passé (par exemple, pour l'identification login/mdp).
Marsh Posté le 25-08-2004 à 11:24:12
tuxbleu a écrit : j'ai parfois besoin de récupérer le résultat de mes requettes. (information sur les autres joueurs de la partie entre autre). |
Ben le script PHP renvoie une page HTML (peut-être que ca peut renvoyer autre chose, j'ai jamais fais de php) ; tu planque les résultats dedans et ton programme client n'a plus qu'à lire et à reconstruire les objets qui vont bien.
En fait tu dois pouvoir faire du XML avec ton script php, t'as plus qu'à parser côté client.
Marsh Posté le 25-08-2004 à 11:37:43
R3g a écrit : Ben le script PHP renvoie une page HTML (peut-être que ca peut renvoyer autre chose, j'ai jamais fais de php) ; tu planque les résultats dedans et ton programme client n'a plus qu'à lire et à reconstruire les objets qui vont bien. |
Eh mais tu sais que t'es pas con !
Ca convient au reste de l'équipe, tu viens de trouver la solution à notre problème
merci.
Marsh Posté le 25-08-2004 à 11:38:39
R3g a écrit : Ben le script PHP renvoie une page HTML (peut-être que ca peut renvoyer autre chose, j'ai jamais fais de php) ; tu planque les résultats dedans et ton programme client n'a plus qu'à lire et à reconstruire les objets qui vont bien. |
tu peux générer n'importe quoi avec du php ... comme avec n'importe quel techno de scripting serveur (asp, jsp, etc ...). Mais c'est plus adapté pour renvoyer du texte bien sûr ...
dans ton cas, l'idéal serait que ton php se base sur les paramètres de l'url pour savoir quoi faire (quelle requête faire en base) et retourne le résultat sous forme XML. c'est une sorte de web service fait maison
Marsh Posté le 25-08-2004 à 11:39:05
tuxbleu a écrit : Eh mais tu sais que t'es pas con ! |
c'est ce qu'on te dis de faire depuis le début
Marsh Posté le 25-08-2004 à 11:40:33
benou a écrit : c'est ce qu'on te dis de faire depuis le début |
Tu sais, il fo me parler comme un neuneu à moi, je comprend pas vite. Et puis le coup du fichier xml, ca me parait pas mal...
Marsh Posté le 25-08-2004 à 11:41:29
tuxbleu a écrit : Eh mais tu sais que t'es pas con ! |
oui
Marsh Posté le 25-08-2004 à 11:41:32
mé toi aussi tu es tres fort, vous etes tous des tueurs
pas de jalou comme ca
Marsh Posté le 25-08-2004 à 11:47:23
tuxbleu a écrit : mé toi aussi tu es tres fort, vous etes tous des tueurs |
mais nan c'est pas ça, c'est juste que ca veut dire que t'avais rien compris à ce qu'on avait dit depuis le début
Le fait d'utiliser du xml ou un format texte à la con, ca change vraiment pas grand chose ...
Marsh Posté le 25-08-2004 à 12:03:41
benou a écrit : mais nan c'est pas ça, c'est juste que ca veut dire que t'avais rien compris à ce qu'on avait dit depuis le début |
ct juste que je voyais pas comment récupérer le résultat des requettes php .J'avé pas capté que je pouvais les mettres ds un fichier.
Et puis je voulais essayer de trouver autre chose que de passer par une page php qui fait les requettes. Mais je dois bien me résoudre à faire comme ca.
Marsh Posté le 25-08-2004 à 12:07:11
tuxbleu a écrit : ct juste que je voyais pas comment récupérer le résultat des requettes php |
Note bien qu'on a jamais parlé de mettre quoique ce soit dans un fichier hein... ton script php va renvoyer sa réponse par le réseau, le xml tu va le lire dans une socket..
Marsh Posté le 25-08-2004 à 12:24:15
R3g a écrit : Ben le script PHP renvoie une page HTML (peut-être que ca peut renvoyer autre chose, j'ai jamais fais de php) ; tu planque les résultats dedans et ton programme client n'a plus qu'à lire et à reconstruire les objets qui vont bien. |
ben ouais, xml-rpc est tout indiqué..
bien que dans son cas, je soupçonne qu'une seule ligne de resultat en texte simple suffirait
Marsh Posté le 25-08-2004 à 16:28:31
the real moins moins a écrit : ben ouais, xml-rpc est tout indiqué.. |
une seule ligne suffura pas, fau charger des informations sur les autres joueurs de la partie, style pseudo, numéro de photo, etc...
Citation : Note bien qu'on a jamais parlé de mettre quoique ce soit dans un fichier hein... ton script php va renvoyer sa réponse par le réseau, le xml tu va le lire dans une socket.. |
je croyais qu'il fallait que le script php génère un fichier xml en y mettant le resultat de sa requette. Ya moyen de récupérer directement le résultat d'une requette ? (sans passer par un fichier ?)
Marsh Posté le 25-08-2004 à 17:02:13
Tu recupere le stream d'un URLConnection et tu le balance en doc root dans ton parser DOM.
Si le xml est bien formaté pas de pb
Marsh Posté le 26-08-2004 à 08:59:55
savory a écrit : Tu recupere le stream d'un URLConnection et tu le balance en doc root dans ton parser DOM. |
bon, ben je vais me pencher la dessus...
Marsh Posté le 24-08-2004 à 15:36:24
Bonjour
J'ai crée un jeu avec des potes, qui à besoin de faire des requettes à une base de données. J'ai donc dans mon code une variable qui contient le mot de passe pour y acceder.
Comment je peux empecher les utilisateurs du jeu de récupérer le mot de passe depuis les fichiers classe ? On m'as dit qu'il était simple de récupérer le code à partir des fichiers classes. Et j'ai bien entendu pas envie que n'importe qui accède à ces bases de données.
Une méthode de la classe String qui cripterais un String lors de la compilation serait idéal, mais je rêve un peu peut-etre...
merci de vos aide.