Private, protected ou public ? - Comment faire le meilleur choix ?

Bonjour à tous.

J'ai souvent des difficultés lors du choix de la portée des variables, et surtout des méthodes/fonctions.

D'après ce que je sais :
- private : la ressource est accessible seulement par les Eléments de la class dans laquelle elle est défini (et les class internes je crois),
- protected : elle accessible au niveau du du package
- public : elle est disponible et accessible depuis n'importe où (dans le système local ou par une application installée sur une distante ?)

Corrigez-moi, s'il y'a des erreurs.

J'ai en faite 2 questions dans ce contexte : La première est d'ordre générale, et la deuxième concerne un cas précis.

- Question 1 :
Je n'ai toujours pas compris la raison "réelle", "concèrete", "pratique", en production pour laquelle on doit utiliser une portée adéquate .
Clairement, je dirai : que risque-ton en "pratique", pas en "théorie", si on déclarait une variable comme public alors qu'elle devrait être private ?

Exemple :
une class utilisateurs, permetant l'enregistrmeent d'un nouveal utilisateur.
Elle contient les variables :
- nom, prenom, dateNaissance, pseudo et motDePasse.

La logique de sécurité java, est que toutes ces variables devraient être private, et il devrai y avoir au mininum une methode setter pour chacune d'elle, et peut-être un setteur (si on veut lire les infos de la personne, avec la même class).
les setter/getter seront surement en protected, sinon public.

Mais question est :
où est le danger, le "risque de sécurité" si on ne définit pas de setter/getter et que l'on déclarait nos variable en protected, voir même en public ?

D'après les arguments que j'ai souvent lu sur les forum, les cours ... :

Argument 1 :
Supposant que l'utilisateur user1 saisi ses données : "nom u1", "prenom u2", "01/01/1990", "user1", "123456...."
sachant que les variables contenant ces données ne sont pas private, un autre utilisateur (user2) malintentionné pourrai modifier les donnée du user1,par exemple son pseudo, son mot de passe, ... puisqu'il suffirait que cet user2 de modifier la valeur des variables.

Je ne comprends pas cet argument et je la trouve irréalisable puisque :
quand user1 (ou user2 se connecte) à notre application (installé sur notre serveur) depuis son navigateur web ou autre client (installé loin de notre serveur),
arrivé sur la page d'inscription, une instance (un objet) de la classe personne sera crée et stocké en mémoire RAM.

Ni user1, ni user2 ne connaissent l'adresse mémoire que le système d'exploitation de notre serveur va allouer à chacune de nos variables d'objet (associé à chaque utilisateur) !

Partant de là, alors je ne comprends pas comment user2 pourrait t-il avoir accès au contenu des variables d'objet instancié par notre serveur, pour user1, puisque tout est en mémoire RAM, côté serveur !)

Remarque : je ne demande pas la technique qu'il pourrai utiliser, mais je veux juste montrer que ça me parait irréalisable, d'où le but de la question 1 ( que risque t-on "concrètement" si on déclare une variable public aulieu de private ?).

De plus quand on dit que déclarer une variable en public, permettrait à n'importe qui de le modifier directement.
Oui mais, une variable private avec un setter, revient au même non ?
Donc si on évite que user2 modifie les infos de user1, en y accédant directement en faisant personne1.passWord="xxxxxx", qu'est ce qui l’empêcherai de faire : personne1.setPassWord("xxxxxx")



... Et même si je prenais le cas où user2 est remplacé par une application malveillante, disant un virus, malware, etc. et que cette application malveillance se trouve déjà sur notre serveur.
... Supposons que notre application java est déployée dans /home/compte1/apps/AppEnLigne/package1/ (inscriptionUtilisateur.class, autreClass.class, ...)
et que :
- cas 1/ le virus se trouve dans le dossier ... /package1/ (donc au même endroit que les fichiers de class inscriptionUtilisateur et autres),
- cas 2/ le virus se trouve à l’extérieur du dossier ... /package1/

Dans les deux cas, le virus est lancé avec les droits d'exécution de nos fichiers de class contenu dans ..../package1/.
Donc il peut par exemple lancer la commande :
java ..../package1/inscriptionUtilisateur.class, sans probleme.

Même dans ces 2 cas, je pense qu'en lançant la class d'inscription, tout ce qu'il pourra faire, c'est ajouter des comptes inutile.
Et les objets de la class inscritionUtulisateur.class qui seront instanciés (à la la demande du virus) seront tout à fait séparés, différents de celui instancié à la demande de user1 (même-ci les demandes du virus et de user1 se font simultanément).

Là aussi, je ne voit pas non plus où est le risque d'insécurité "concrète" qui justifierai l'utilisation d'une portée private ou protected et non public ?

3eme cas de figure,
supposons que ce virus peut lire le contenu de la mémoire RAM (pour x raisons, faille de sécurité sur le serveur, etc),
Même dans ce cas, sincèrement, je ne vois toujours pas comment il pourrait trouver les adresses mémoires des ressources (variables) liées à la session de user1 ou autre user d'ailleurs , vu l'immensité de la mémoire RAM, la complexité des algorithme d’allocation (aléatoire) des adresses mémoire, etc !

Et, même-ci malgré l'aspect aléatoire d'allocation d'adresse mémoire, le virus finissait par les trouver et à modifier leur contenu, cela ne relèverait pas (à moins que je me trompe) de la responsabilité (faiblesse) du code java (notamment au niveau de la portée) mais je pense que cela devrait être imputé au système d'exploitation et/ou faille au niveau d'un autre éléments du système.






----- 2eme Argument évoquée dans le forum, pour justifier l'utilisation d'une portée adéquate. ----

Je me souviens avoir lu que imposer l’utilisateur passer par les getters / setteur était nécessaire pour ses raisons (de sécurité, ou je dirai plutôt de conformité des données) :

- contrôle du formatage, la validité de données, avant affectation vers la variables responsable. exemple : une date, nu numéro de téléphone, un code postale, ... doivent respecter un certain nombres de contraintes.

Sur ce point de vu, je suis d'accord mais appeler cela "sécurité" des données me parait pas approprié car peu induire en erreur (confusion).
Je pense que c'est plutôt de la "sûreté" (fiabilité, intégrité ou qualité) des données, mais pas sécurité". Encore une fois, merci de me corriger si je me trompe, car je ne suis que vieux débutant.



----- Fin du premier problème : question d'ordre générale sur la portée des variables / méthodes ------


Pour le deuxième problème, plus concret, je prefère créer un nouveau sujet, tout mélanger.

Citation:

---

EDIT : C'est par ici : c1 est-il sécurisé ? private Cla c1 = new Cla() -- sachant que setter et getter dans Cla sont public

---

Merci de m'avoir lu et pour vos reponses.

A bientôt

Salut,

Citation:

---

Envoyé par ngmsky

D'après ce que je sais :
- private : la ressource est accessible seulement par les Eléments de la class dans laquelle elle est défini (et les class internes je crois),
- protected : elle accessible au niveau du du package
- public : elle est disponible et accessible depuis n'importe où (dans le système local ou par une application installée sur une distante ?)

Corrigez-moi, s'il y'a des erreurs.

---

protected : aussi accessible pour les classes qui étendent la classe qui les déclare.
tu oublies aussi la portée dite "package", qui n'a pas de mot associé, et qui définit une portée limitée au package. Par exemple :

Code:

---

1 2 3 4 5

package toto; public class Machin { int truc; void method() {} }

---

la variable truc et la méthode method() sont accessibles depuis toutes les classes du package toto.

Ensuite la portée n'a rien à voir avec la sécurité ou l'accès distant (externe inter-application ou réseau). Elle permet de garantir l'intégrité de l'état d'une classe. Et par conséquence de fiabiliser son fonctionnement, donc le fonctionnement de l'API, et donc du programme complet.

Prenons :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43

public class Machin {   private int truc; private String bidule; private Image image; private List<String> list; protected final PropertyChangeSupport propertyChangeSupport;   public Machin() { propertyChangeSupport=new PropertyChangerSupport(this); list=Collections.emptyList(); }   public void setTruc(int val) { int old = truc; truc=val; propertyChangeSupport.firePropertyChange("truc", old, truc); }   public void setBidule(String val) { Objects.requiredNonNull(val,"Valeur null non autorisée"); val=val.trim(); if ( val.isEmpty() ) throw new IllegalArgumentException("Valeur vide ou uniquement whitespace non authorisé"); int old = bidule; bidule=val.toUpperCase(); propertyChangeSupport.firePropertyChange("bidule", old, bidule); }   public void setLines(Path path) throw IOException { List<String> old = list; list = Collections.unmodiableList(Files.readAllLines(path)); propertyChangeSupport.firePropertyChange("lines", old, list); }   public void setImage(URL url) throw IOException { Image old = image; image = ImageIO.read(url); propertyChangeSupport.firePropertyChange("image", old, image); }   /*...*/   }

---

La méthode setTruc permet de garantir qu'on envoie bien l'événement de changement de valeur. Cela pourrait n'importe quel autre traitement nécessaire à faire, mise en cache, mise à jour d'une autre variable, chargement de resource etc. Ou contrôle, traitement particulier sur la variable comme sur la variable comme pour setBidule.
La plupart du temps, on écrit du code que d'autres vont utiliser : ils n'ont pas à lire le code de la classe pour savoir comment ils doivent faire pour s'assurer que l'instance reste intègre par rapport à ce qu'elle est censée faire.

D'autre part, le fait d'avoir des variables private et d'avoir des accesseurs et des mutateurs ferme le code de la classe (personne ne peut aller bidouiller les variables sans se soucier des conséquences sur le fonctionnement) mais ouvre les extensions possibles (on peut étendre la classe et redéfinir une méthode : on ne pourra pas bypasser un fonctionnement en accèdant directement à la variable).

Enfin, il y a aussi les problématiques dues au multiprocess, qui nécessite parfois de verrouiller plusieurs variables le temps de changer d'état.

Bonjour et merci pour ta reponse.

Citation:

---

Envoyé par joel.drigo

protected : aussi accessible pour les classes qui étendent la classe qui les déclare.

---

Ah oui, ça je ne me souvenais plus.

Citation:

---

Envoyé par joel.drigo

tu oublies aussi la portée dite "package", qui n'a pas de mot associé, et qui définit une portée limitée au package. Par exemple :

Code:

---

1 2 3 4 5

package toto; public class Machin { int truc; void method() {} }

---

la variable truc et la méthode method() sont accessibles depuis toutes les classes du package toto.

---

Donc portée non déclarée, signifie portée niveau package (par défaut), c'est bien ça ?
je croyais qu'il fallait toujours utiliser protected devant le nom d'une ressource (variable, méthodes, class, ... ) pour qu'elle soit accessible uniquement au niveau du package.

Je retiens donc que : le faite d'organiser ou de repartir les class (d'un même projet) dans plusieurs packages différentes, revenait donc à les donner une portée au niveau package, puisque chacune d'elle devraient obligatoirement commencer par l'instruction : package nomDuPackage ; // => portée package.
... Sauf si l'on utilise private ou public le nom d'une ressource.

Citation:

---

Envoyé par joel.drigo

Ensuite la portée n'a rien à voir avec la sécurité ou l'accès distant (externe inter-application ou réseau). Elle permet de garantir l'intégrité de l'état d'une classe. Et par conséquence de fiabiliser son fonctionnement, donc le fonctionnement de l'API, et donc du programme complet.

---

Ah, voilà enfin, ce que j'ai toujours cherché à comprendre. Là c'est vraiment bien claire qu'associer le mot "sécurité" au choix de la portée des ressource java est de l'abus de langage et peu induire largement en erreur.
On pourra par exemple croire que le faite d'avoir fais les meilleur choix de portée, nettement les plus restrictive, en maximise la "sécurité" de son application contre les attaques des pirates informatiques.
Ce manque de clarté et cette confusion induite par l'utilisation du "sécurité" pour parler de la "portée", m'a souvent dérangé et m’empêche parfois de d’avancer.
Maintenant c'est résolu. Merci à toi.

Citation:

---

Envoyé par joel.drigo

D'autre part, le fait d'avoir des variables private et d'avoir des accesseurs et des mutateurs ferme le code de la classe (personne ne peut aller bidouiller les variables sans se soucier des conséquences sur le fonctionnement) mais ouvre les extensions possibles (on peut étendre la classe et redéfinir une méthode : on ne pourra pas bypasser un fonctionnement en accèdant directement à la variable).

---

personne ne peut aller ...
et
... on ne pourra pas bypasser

Ici, le sujet (personne et on), de qui parlez-vous ? de quelle personne parlez-vous ?
1/ d'un pirate informatique (action volontaire ?),
2/ du développeur du programme java, lui-même, (cad action par erreur de programmation, d’algorithme ? )
3/ du syteme d'exploitation (par bug ou comportement)

C'est ce genre de langage qui mettais aussi en confusion (quand au rôle/but du choix la portée).

Citation:

---

Envoyé par joel.drigo

Enfin, il y a aussi les problématiques dues au multiprocess, qui nécessite parfois de verrouiller plusieurs variables le temps de changer d'état.

---

Un ami m'en a parlé brièvement. Connaîtrais-tu un bon cours/tuos qui explique bien le choix de la portée dans ce contexe (multiprocess) ?

Citation:

---

Envoyé par ngmsky

Donc portée non déclarée, signifie portée niveau package (par défaut), c'est bien ça ?

---

Oui.

Citation:

---

Envoyé par ngmsky

Je retiens donc que : le faite d'organiser ou de repartir les class (d'un même projet) dans plusieurs packages différentes, revenait donc à les donner une portée au niveau package, puisque chacune d'elle devraient obligatoirement commencer par l'instruction : package nomDuPackage ; // => portée package.
... Sauf si l'on utilise private ou public le nom d'une ressource.

---

La déclaration du package ne défnit pas la portée en elle-même. Elle sert juste à organiser les classes. La portée par défaut (sans mot clef) définit une portée d'attribut ou méthode dite package (Pour préciser, tu le sais sûrement toto.machin est un package et toto.machin.truc est un autre package (donc portée limitée au package signifie toutes les classes dans le même package, mais pas étenue aux "sous-package").
Le mot ressource est en revanche inadapté dans ce contexte : les ressources ne sont pas concernées par la portée. Les ressources, ce sont par exemple les fichiers images, de configuration, de localisation, ou des ressources externes, etc. La portée concerne uniquement les variables (attribut ou variables locales) et les méthodes.

Citation:

---

Envoyé par ngmsky

Ah, voilà enfin, ce que j'ai toujours cherché à comprendre. Là c'est vraiment bien claire qu'associer le mot "sécurité" au choix de la portée des ressource java est de l'abus de langage et peu induire largement en erreur.

---

La confusion vient probablement du fait que la sécurité en général couvre :

• l'intégrité des systèmes d'informations (le fait que les données d'une base de données ne soient pas corrompues ou partielles par exemple)
• la fiabilité des systèmes d'informations (la redondance par exemple)
• la pérénité des systèmes d'informations (les sauvegardes)
• la confidentialité (sécurité d'accès...)
• etc

Si des logiciels intègrent des systèmes de sécurisation, ils ne sont pas complètement et pas forcément pris en compte par la syntaxe du langage lui-même. Mais certains langages ou type de langages (fonctionnels par exemple) peuvent intégrer des fonctionnalités permettent de garantir la sécurité des informations traitées. Mais si les variables et objets servent à traiter des informations au sein des programmes, ce ne sont pas directement des informations.

Citation:

---

Envoyé par ngmsky

On pourra par exemple croire que le faite d'avoir fais les meilleur choix de portée, nettement les plus restrictive, en maximise la "sécurité" de son application contre les attaques des pirates informatiques.

---

La sécurité ne concerne pas seulement la problématique de piratage, mais également les problématiques liées aux pannes (matériels et logiciels), et les problématiques d'erreurs humaines (un utilisateur qui supprimerait par erreur des informations par exemple). Et la portée ne change rien à l'affaire.
On peut avoir toutes les variables publiques et empêcher que les informations soient détruites ou volées. Et on peut avoir que des variables privées dans un programme, sans connexion sécurisée et utiliser un débogueur pour récupérer toutes les valeurs traitées, ou utiliser les classes de l'API pour détruire les données en base. Il n'y a donc strictement aucun rapport entre portée de variables et sécurisation.

Citation:

---

Envoyé par ngmsky

Ici, le sujet (personne et on), de qui parlez-vous ? de quelle personne parlez-vous ?

---

La plupart du temps les classes qu'on écrit sont utilisées par d'autre. Ils existent bien sûr des programmeurs qui sont seuls dans leur garage et ne font que diffuser des applications fermées. Mais le plus grand nombre des developpeurs travaillent dans une entreprise et leur classe peut être utilisée par des centaines de personnes. Ils doivent donc garantir que les autres pussent utiliser leurs classes de manière transparent, sans avoir à se soucier du fonctionnement interne, sans avoir à prendre des précautions particulières (c'est pour ça qu'il faut par exemple éviter au maximum les états intermédiaires dans les classes. Les developpeurs d'API, même s'ils sont seuls, doivent également le faire.

Citation:

---

Envoyé par ngmsky

Un ami m'en a parlé brièvement. Connaîtrais-tu un bon cours/tuos qui explique bien le choix de la portée dans ce contexe (multiprocess) ?

---

Le choix de la portée dans ce contexte est évident : on ne doit pas permettre à l'utilisateur externe de la classe d'accèder à l'un des éléments qui contituent un groupe intègre d'éléments, en dehors d'un bloc qui garantit l'intégrité de l'état de la classe, ou alors la classe n'est pas thread-safe. Il est nécessaire donc que la portée soit private, sinon l'utilisateur (je parle d'objet ici, pas de personne) risque soit de lire une valeur qui n'est pas encore cohérente avec une autre qu'on aurait déjà modifiée. En revanche, la portée private n'est pas suffisante : il faut mettre en place un système qui évite que 2 threads accèdent aux variables dans les méthodes elle-mêmes lorsqu'elles sont dans un état intermédiaire et/ou incohérent (synchronisation, verrous, volatile et classes dédiées (voir package java.util.concurrent).

Bonjour,

Citation:

---

Envoyé par joel.drigo

La confusion vient probablement du fait que la sécurité en général couvre :
l'intégrité des systèmes d'informations (le fait que les données d'une base de données ne soient pas corrompues ou partielles par exemple)
la fiabilité des systèmes d'informations (la redondance par exemple)
la pérénité des systèmes d'informations (les sauvegardes)
la confidentialité (sécurité d'accès...)
etc

---

Merci pour cette précision et cette vision globale de la sécurité. On bien que parler de "sécurité" sans préciser le contexte, peut être source de confusion et par conséquent de perte de temps, de mise en place de procédures complément inutiles, ...
Il serait souhaitable que la communauté de développeur ou éditeurs de cours/tutos/articles java intègre cette précision lorsqu’ils parlent de la sécurité dans le cadre de la portabilité. En tout cas, j'ai constaté que je n’était pas le seul à être dans cette confusion, car mon ami qui a pourtant un très bon niveau en java, ne crois pas à vos conclusion sur ce sujet et insiste que la portée définit le niveau de sécurité contre le piratage d'une application.

Je réalise à quel point il est important de veuillez sur la qualité de la communication et des expressions utilisées dans les livres, tutoriels, etc sinon, les conséquences peuvent être plus ou moins graves.

Un sondage sur ce que pensent les développeurs java, sur l'impact de la portée des variables/méthodes ou class java dans la sécurité (piratage, intrusion, logiciels malveillants) d'un programme java, nous donnerait surement une idée sur cette erreur de communication (mauvaise idée reçue, confusion entre sécurité de l'application java et intégrité des données).


En tout cas, merci encore pour ton assistance.

Citation:

---

Envoyé par ngmsky

j'ai constaté que je n’était pas le seul à être dans cette confusion, car mon ami qui a pourtant un très bon niveau en java, ne crois pas à vos conclusion sur ce sujet et insiste que la portée définit le niveau de sécurité contre le piratage d'une application.

---

C'est une parfaite illusion. La plupart de la gestion de la sécurité se fait déjà en amont des programmes, par le protocole d'accès, par l'os, par le réseau, par l'architecture (accès par services au lieu de JDBC par exemple) etc, et en aval, dans les systèmes d'informations. On peut mettre en place des mesures de sécurisation dans le code (gestion de rôle utilisateur par exemple). La portée des variables, méthodes et classes, limitent les possibilités directes du développeur, c'est tout. Et encore, il y a d'autres moyens (pattern proxy par exemple).
Et il ne faut pas oublier qu'aucune mesure de protection n'est parfaite : qui voudra la contourner pourra avec plus ou moins d'efforts. Le but de toute mesure de sécurité n'est que d'augmenter ces efforts. Plus l'effort est important par rapport à sa rentabilité, plus l'application est sécurisée. C'est tout. Je ne vois pas ce que la portée a à faire ou ne pas faire dans cette affaire.

Citation:

---

Envoyé par ngmsky

Un ami m'en a parlé brièvement. Connaîtrais-tu un bon cours/tuos qui explique bien le choix de la portée dans ce contexe (multiprocess) ?

---

Dès que tu parles de parallélisme, mettre une variable en public/protected est une invitation à des soucis (Sauf si tu as mis la variable en synchronized directement). Du coup, private est quasiment la seule solution correcte pour éviter les soucis lorsqu'on gére une structure de données pour un context parallèle.

Citation:

---

Envoyé par fearyourself

Dès que tu parles de parallélisme, mettre une variable en public/protected est une invitation à des soucis (Sauf si tu as mis la variable en synchronized directement). Du coup, private est quasiment la seule solution correcte pour éviter les soucis lorsqu'on gére une structure de données pour un context parallèle.

---

Bonjour, et merci pour cette information importante.

Citation:

---

Envoyé par ngmsky

En tout cas, j'ai constaté que je n’était pas le seul à être dans cette confusion, car mon ami qui a pourtant un très bon niveau en java, ne crois pas à vos conclusion sur ce sujet et insiste que la portée définit le niveau de sécurité contre le piratage d'une application.

---

Désolé de répondre sur un post résolu mais je suis surpris que personne n'ai fait la remarque: il se trouve que votre ami à tord et qu'il devrait peut-être réévaluer son niveau en Java. Lorsque joel.drigo indique que la portée ne définit pas le niveau de sécurité de l'appli face au piratage ce n'est pas un avis personnel mais quelque chose de démontrable: il est possible via l'introspection de changer la portée de n'importe quelle variable ou méthode (ou presque. Java 8 impose quelques exceptions sur les parties propriétaires de l'API) et donc d'invoquer du code qui n'est normalement pas invocable. Si c'était une protection contre le piratage elle ne tiendrait pas 10 s.