lecture d'une variable

On 2006-12-20, Jean-Francois Ortolo wrote:

particulièrement pour l'unicité des sondages par prise en compte de
l'adresse IP.

Et quand il y a deux cent personnes derriere une seule adresse IP ?
Ou quand l'adresse IP change presque à chaque requete ?

--

S'il est plus expressif, cela veut-il dire qu'il existe des algorithmes
implémentables en lisp qui ne peuvent pas l'être avec Sed ?
Par Dieu, non. Par toi ou moi, oui.

- PB - fr.comp.os.unix -

John GALLET wrote:

Si appel au script sans identificateur de session == celui enregistré
dans la base de données => ouverture nouvelle session avec
identificateur numérique = qqchose genre: md5sum(microtime()), puis
appel de la fonction donnant le menu principal d'administration.

Je n'ai pas compris la première ligne : pourquoi donne-t-on un accès quand
on compare une donnée NON RECUE avec une donnée en base ? Le "sans" doit
être une faute de frappe.

Si appel au script avec identificateur de session == l'un de ceux
enregistrés dans la base, alors exécution normale.

Ah bah non, c'était volontaire. Donc je n'ai pas compris la logique
d'attribution du token.

Je vous prie de m'excuser de ma formulation un peu rapide.

Le "sans" concerne l'égalité "==" qui la suit, un peu comme une
négation logique.

Le problème étant d'empêcher un intrus extérieur de lancer ce script
avec ce paramètre de branchement vers la fonction, ( donc avec un faux
paramètre, puisque non produit par le script lui-même ), on fait en
sorte de "suivre" les accès à ce script, par une session ( par user
évidemment, mais il n'y a théoriquement que l'administrateur qui a le
login/password d'accès ). Cette session comporte simplement une variable
de session numérique ou alphabétique complexe. Par exemple: la valeur
de microtime()

Première possibilité: Au début du script, la session démarre, si
cette variable de session n'existe pas ou n'a pas une valeur existante
dans la base de données, c'est que c'est le premier appel à ce script:
Donc cette variable complexe de session est générée, mise dans la base
de données, et la fonction de branchement est la première, c'est-à-dire
celle du menu d'administration.

Evidemment, la valeur de la variable gérant le branchement aux
fonctions, est transmise à chaque fois en mode POST, après modification
dans la fonction précédente et/ou dans le début du script en fonction du
branchement ultérieur et/ou du contenu des données transmises en POST au
script.

Deuxième possibilité: Si au début du script, après le démarrage de la
session, la variable numérique ou alphabétique complexe existe et figure
dans la base de données, c'est que cet appel à ce script, provient bien
de ce même script, et donc il est possible de faire confiance aux
données transmises en POST lors de cet appel, puisque la session ne peut
pas, pratiquement, être usurpée ( théoriquement ).

Dans ce cas, le traitement des données transmises en POST est
effectué dans le début du script ( enregistrement dans la base de
données par exemple ), puis éventuellement la variable gérant le
branchement aux fonctions, est modifiée en fonction des données
transmises en POST au script. En effet, ce n'est qu'au moment où on
prend connaissance des choix précédents de l'administrateur, que l'on
saura quelle prochaine fonction appeler. la fonction correcte est
appelée par le script, puis les choix sont faits par l'utilisateur sur
l'interface web de cette fonction, puis son formulaire POST est lancé,
et ainsi de suite, jusqu'à ce que l'ensemble du traitement opéré par le
script, suivant les besoins de l'utilisateur, ait été fait. Donc la
dernière prise en compte des choix de l'administrateur sera faite, puis
l'exécution du script sera terminée.

Il faut dans l'étape préalable d'analyse fonctionnelle, que je
précise bien la logique d'évolution entre les différentes fonctions,
suivant les choix de l'administrateur, et la trasmission des données
saisies par l'administrateur. ( Quelles données pour quelles
fonctionnalités, etc.. )

Celà, je pense l'avoir déjà mis au point, dans une première approche
fonctionnelle, que j'ai mise dans un fichier readme.txt

Je sais, ce n'est pas le rôle d'un fichier readme.txt, mais bon... ;)

Merci de me donner votre avis sur le degré de sécurité,
particulièrement pour l'unicité des sondages par prise en compte de
l'adresse IP.

En étant bien conscient que ceci retirera des votes normaux, pour ce
besoin, l'IP est une solution acceptable. On pourrait avoir un système de
time out de quelques heures/jours pour la liste des "ip votantes".

Bon.

Mais si l'on mémorise les adresses IP ayant voté, avec disons un
timestamp, et que l'on efface les adresses IP après un délai, les mêmes
personne vont pouvoir revoter ?

Je ne vois pas quel intérêt présente ce dispositif.

Merci beaucoup beaucoup de vos conseils.

Bien à vous.
Respectueusement.

Aïe, aïe, mes pieds. ;)

Jean-François Ortolo

--
Visitez mon site gratuit donnant des Statistiques
et des Historiques Graphiques sur les Courses de Chevaux:
http://www.ortolojf-courses.com

Re,

Comme d'habitude, les fautes d'inattention dans la conception, c'est
mortel...

Ca arrive à tout le monde. Le plus compliqué, c'est de faire simple.

DansMesBras(tm) !-)

Re,

Je vous prie de m'excuser de ma formulation un peu rapide.
Sans problèmes, le elcteur n'était peut-être pas très réveillé non plus...

Le problème étant d'empêcher un intrus extérieur de lancer ce script
avec ce paramètre de branchement vers la fonction, ( donc avec un faux
paramètre, puisque non produit par le script lui-même ),

Ca c'est facile, ca tient en une seule ligne :
exit("F*CK YOU");

sorte de "suivre" les accès à ce script, par une session ( par user
évidemment, mais il n'y a théoriquement que l'administrateur qui a le
login/password d'accès ). Cette session comporte simplement une variable
de session numérique ou alphabétique complexe. Par exemple: la valeur
de microtime()
Oui mais non.

1) on ne donne pas de ressource, quelle qu'elle soit, à quiconque n'a pas
à accéder à cette page. Rien, nada, bernique.
2) quand on fait un backoffice, on fait toujours une répartition semblable
à ceci :

RACINE/frontal.php
RACINE/private/config.php avec .htaccess DENY FROM ALL
RACINE/administration/ avec .htaccess login/pass commun à tous les admins
RACINE/administration/privateadmin/ressources_adm.php avec .htaccess DENY
FROM ALL

Les fichiers au niveau de frontal.php sont ceux qui sont susceptibles de
recevoir d'être appelés par http GET/POST de la partie visible par la
terre entière.

Les fichiers dans private/ sont appelés par require( ) et require_once()
par les script publics. PERSONNE n'a à les appeler directement, donc on
interdit tout accès http par un .htaccess DENY FROM ALL. Si on n'a pas
apache, leut première ligne commence par :
if(!defined('MY_SECU12345')) exit();
et on définit la constante dans les scripts publics.

La même architecture est disponible pour la partie d'admnistration. Un
premier .htaccess protège l'accès aux scripts uniquement pour empêcher
toutes les attaques automatisées par robots. S'il y a plusieurs admins,
ils peuvent ici partager un seul login/pass dans le .htaccess, et ensuite
l'application gère son propre système d'accès.

Première possibilité: Au début du script, la session démarre, si
cette variable de session n'existe pas ou n'a pas une valeur existante
dans la base de données, c'est que c'est le premier appel à ce script:
Oui. Mais est-ce bien raisonnable d'ouvrir une session anonyme dans la

partie administration à quelqu'un qu'on ne connait pas ? Non.
Donc si on ne reçoit pas de variable de session ou si elle est invalide
c'est directement :

require('privateadmin/print_login_form.html');
exit();

Et fin de la discussion.

Donc cette variable complexe de session est générée, mise dans la base
de données, et la fonction de branchement est la première, c'est-à-dire
celle du menu d'administration.

Mais de quel droit ?! Pourquoi aurait-on une quelconque velléité
d'exécuter du code sans savoir à qui on a affaire dans la partie ADMIN ?

Deuxième possibilité: Si au début du script, après le démarrage de la
session, la variable numérique ou alphabétique complexe existe et figure
dans la base de données, c'est que cet appel à ce script, provient bien
de ce même script,

La requête est légitime. Il est ici normal d'exécuter du code.

et donc il est possible de faire confiance aux
données transmises en POST lors de cet appel,

Non, ça jamais. La requête peut donner lieu à exécution de code parce
qu'elle est légitime (le token d'identification est valide) mais les
données reçues du monde extérieur ne peuvent JAMAIS êter considérées comme
dignes de confiance, ne serait-ce qu'à cause des fautes de frappe : si je
tape 1 0 (espace en trop) dans une zone de quantité parce que, comme
d'hab, j'ai pas encore enlevé les moufles et le café est trop chaud, la
requête SQL va faire une drôle de gueule.

Dans ce cas, le traitement des données transmises en POST est
effectué dans le début du script ( enregistrement dans la base de
données par exemple ), puis éventuellement la variable gérant le
branchement aux fonctions, est modifiée en fonction des données
transmises en POST au script. En effet, ce n'est qu'au moment où on
prend connaissance des choix précédents de l'administrateur, que l'on
saura quelle prochaine fonction appeler.

Euh... L'oeuf ou la poule ? Reprenons. Quand on appelle une
fonction/méthode il faut bien à un moment ou à un autre vérifier qu'on a
toutes nos billes pourle faire, et qu'il ne manque pas de données
obligatoires pour ce faire. Or ceci dépend de chaque traitement. Donc il
faut commencer par récupérer, d'une manière ou d'une autre, peu importe,
l'action à exécuter, et c'est elle la racine de l'arbre d'appel : selon
l'action à exécuter, on vérifie si on a bien toutes les informations
nécessaires pour le traitement (reçues directement, ou stockées ailleurs,
en session au sens large, en base, sur la lune, etc.).

suivant les choix de l'administrateur, et la trasmission des données
saisies par l'administrateur. ( Quelles données pour quelles
fonctionnalités, etc.. )
Ca tombe bien, cf ci-dessus.

Mais si l'on mémorise les adresses IP ayant voté, avec disons un
timestamp, et que l'on efface les adresses IP après un délai, les mêmes
personne vont pouvoir revoter ?

Oui, mais ça ce sera le cas de toutes façons : la majeure partie de la
population ne possède pas des IP fixes... Si je me connecte par wanamou le
matin puis l'après midi, je n'aurai pas la même IP. Et ne parlons pas des
utilisateurs derrière des proxys (le cas le plus connu est AOL) qui
changent d'IP à chaque requête (sur une page qui a 10 images, on peut voir
11 adresses IP différentes...)

Je ne vois pas quel intérêt présente ce dispositif.
Uniquement empêcher quelqu'un de s'exciter sur le bouton refresh. Pas

plus, pas moins. Et encore, marchera pas pour les utilisateurs d'AOL.

a++;
JG

Bonjour Monsieur

Je suis désolé de ne pas avoir répondu plus tôt, j'étais en vacances
de Noël chez mon père, dans un coin pas trop perdu du pays basque... ;)

Voir mes réponses ci-dessous.

Jean-François Ortolo

John GALLET wrote:

Le problème étant d'empêcher un intrus extérieur de lancer ce script
avec ce paramètre de branchement vers la fonction, ( donc avec un faux
paramètre, puisque non produit par le script lui-même ),

N'oublions pas, que tout le répertoire où se trouve la partie
administration, est sécurisé par login/password dans les fichiers
.htaccess et .htpasswd

Théoriquement donc, personne ne devrait pouvoir avoir accès à ce
répertoire, directement de l'extérieur.

Cependant, le fait de suivre les appels au *même* script
d'administration par une session avec une variable complexe (
microtime() au moment de l'ouverture de la session, nous garantit même
dans ce cas ( login/password volés ), que le script d'admin ne peut
s'exécuter, que conformément à sa programmation.

sorte de "suivre" les accès à ce script, par une session ( par user
évidemment, mais il n'y a théoriquement que l'administrateur qui a le
login/password d'accès ). Cette session comporte simplement une variable
de session numérique ou alphabétique complexe. Par exemple: la valeur
de microtime()

Oui mais non.
1) on ne donne pas de ressource, quelle qu'elle soit, à quiconque n'a pas
à accéder à cette page. Rien, nada, bernique.

Quelle ressource ?

Si c'est le résultat de microtime(), elle peut être visible comme
cookie temporaire, si la session se fait par cookie. Evidemment, si le
visiteur n'est pas l'administrateur et a volé le login/password, il
s'aperçoit à la rigueur, qu'il y a une session, et que la variable de
session, ressemble à une valeur de microtime(). Mais que voulez-vous
qu'il en retire ultérieurement ? Il ne peut pas deviner aucune valeur
ultérieure de microtime(), qui a une résolution de une micro-seconde, et
de toute façon, il a déjà volé le login/password, alors...

En fait, je reconnais que la protection par session, ne servirait à
rien, puisque toute la sécurité du script d'admin, tient à sa protection
par login/password.

Donc cette variable complexe de session est générée, mise dans la base
de données, et la fonction de branchement est la première, c'est-à-dire
celle du menu d'administration.

Mais de quel droit ?! Pourquoi aurait-on une quelconque velléité
d'exécuter du code sans savoir à qui on a affaire dans la partie ADMIN ?

L'accès au répertoire d'admin, est protégé par login/password.

Deuxième possibilité: Si au début du script, après le démarrage de la
session, la variable numérique ou alphabétique complexe existe et figure
dans la base de données, c'est que cet appel à ce script, provient bien
de ce même script,

La requête est légitime. Il est ici normal d'exécuter du code.

et donc il est possible de faire confiance aux
données transmises en POST lors de cet appel,

Non, ça jamais. La requête peut donner lieu à exécution de code parce
qu'elle est légitime (le token d'identification est valide) mais les
données reçues du monde extérieur ne peuvent JAMAIS êter considérées comme
dignes de confiance, ne serait-ce qu'à cause des fautes de frappe : si je
tape 1 0 (espace en trop) dans une zone de quantité parce que, comme
d'hab, j'ai pas encore enlevé les moufles et le café est trop chaud, la
requête SQL va faire une drôle de gueule.

Ce ne sont pas des données reçues de l'extérieur. En effet, le fait
que la variable de session ait authentifié l'accès au script par POST,
indique que cet appel POST, provient du script lui-même.

Donc, il est possible de faire confiance à ces données reçues en
POST, puisqu'elles viennent du script lui-même, et que chaque appels
POST précédents à ce script, aient été authentifiés par la variable de
session.

Côté verrouillage exclusif d'accès, c'est évident qu'au début de
l'ajout d'un nouveau sondage ( c'est un cas particulier ), j'incrémente
le numéro d'indice du sondage. Ce numéro d'indice, servira de paramètre
à la fonction appelant l'interface du sondage, dans le script public
servant à l'affichage du sondage.

Cependant, il me paraît nécéssaire d'authentifier l'appel POST au
deuxième script public, enregistrant les données POST du script public
d'affichage, de la façon que j'ai indiquée, par une variable de session,
qui n'est ni devinable, ni simulable.

Donc, au total: Pas de mécanisme d'authentification par session dans
le script d'administration, mais mécanisme d'authentification par
session, dans les scripts publics.

En effet, le seul script existant dans le répertoire
d'administration, est le script d'administration, et de toute façon,
l'accès à ce répertoire est protégé par un login/password.

Si le monsieur malhonnête et méchant, a mon login/password, il peut
de toute façon, faire ce qu'il veut de ma base de données.

Il me semblerait plus sécuritaire, de logguer les accès à ce
répertoire, pour être informé du vol de login/password, histoire de le
changer.

Si le méchant hacker, qui m'en veut particulièrement, a simplement
modifié ma base de données d'une façon imprévisible, il me serait à
priori dificile de m'en apercevoir, si effectivement il appelé le script
d'admin avec des variables POST trafiquées. Pour parer à cette
éventualité, il faudrait donc quand même, faire une authentification par
session, même dans le script d'admin ( en plus des scripts publics ).

A charge pour moi de faire un programme pour détecter les
incohérences dans ma bdd, suite à ce type d'intrusion ( exécution
normale du script d'admin, mais modification de la bdd. ) Dans le cas de
l'exécution normale, ce type de programme serait beaucoup plus facile à
faire.

Dans ce cas, le traitement des données transmises en POST est
effectué dans le début du script ( enregistrement dans la base de
données par exemple ), puis éventuellement la variable gérant le
branchement aux fonctions, est modifiée en fonction des données
transmises en POST au script. En effet, ce n'est qu'au moment où on
prend connaissance des choix précédents de l'administrateur, que l'on
saura quelle prochaine fonction appeler.

Euh... L'oeuf ou la poule ? Reprenons. Quand on appelle une
fonction/méthode il faut bien à un moment ou à un autre vérifier qu'on a
toutes nos billes pourle faire, et qu'il ne manque pas de données
obligatoires pour ce faire. Or ceci dépend de chaque traitement. Donc il
faut commencer par récupérer, d'une manière ou d'une autre, peu importe,
l'action à exécuter, et c'est elle la racine de l'arbre d'appel : selon
l'action à exécuter, on vérifie si on a bien toutes les informations
nécessaires pour le traitement (reçues directement, ou stockées ailleurs,
en session au sens large, en base, sur la lune, etc.).

C'est sûr, que je peux faire une vérification de la cohérence des
variables POST reçues, entre elles. Je ne pense pas qu'il y ait besoin
de pousser la sécurité, jusqu'à faire une concordance entre des
variables de session dédiées, et certaines vaiables POST reçues. C'est
de l'ordre du possible, mais le mécanisme de session, pour les deux
scripts publics, me paraît suffisamment sécurisé, pour ne pas avoir à
m'embarasser de proécédés supplémentaires de sécurité, que la cohérence
des variables POST, entre elles.

Pour ce qui est du script d'admin, toute sa sécurité repose sur le
secret du login/password.

Eventuellement, rien ne m'empêche, de supprimer du serveur ce script
d'admin, une fois que l'ensemble de la gestion des sondages, ait été
fait, et de le remettre quand j'en ai besoin. Je sais bien, c'est
foireux... ;)

Par ailleurs, rien ne m'empêche, pour la variable POST de switching
entre les fonctions, d'utiliser des valeurs complexes, difficiles à
deviner, et qui ne seront de toute façon pas vues du visiteur, les
données étant en mode POST.

Mais si l'on mémorise les adresses IP ayant voté, avec disons un
timestamp, et que l'on efface les adresses IP après un délai, les mêmes
personne vont pouvoir revoter ?

Oui, mais ça ce sera le cas de toutes façons : la majeure partie de la
population ne possède pas des IP fixes... Si je me connecte par wanamou le
matin puis l'après midi, je n'aurai pas la même IP. Et ne parlons pas des
utilisateurs derrière des proxys (le cas le plus connu est AOL) qui
changent d'IP à chaque requête (sur une page qui a 10 images, on peut voir
11 adresses IP différentes...)

Je ne vois pas quel intérêt présente ce dispositif.

Uniquement empêcher quelqu'un de s'exciter sur le bouton refresh. Pas
plus, pas moins. Et encore, marchera pas pour les utilisateurs d'AOL.

Oui.

Dans ce cas, peut-être faudrait-il simplement, en plus de l'adresse
IP obsolète, supprimer la variable de session ( des scripts publics ),
de la base de données, ce qui arrête l'authentification, avec
éventuellement backlistage de l'adresse IP correspondante, sans pour
autant modifier le message par défaut, pour ne pas alerter le visiteur
malhonnête.

Merci beaucoup pour tous vos conseils.

"La connaissance s'accroît quand on la partage." ;)

Bien à vous.
Amicalement.

Jean-François Ortolo

--
Visitez mon site gratuit donnant des Statistiques
et des Historiques Graphiques sur les Courses de Chevaux:
http://www.ortolojf-courses.com

Jean-Francois Ortolo wrote:

Oui.

Dans ce cas, peut-être faudrait-il simplement, en plus de l'adresse IP
obsolète, supprimer la variable de session ( des scripts publics ), de
la base de données, ce qui arrête l'authentification, avec
éventuellement backlistage de l'adresse IP correspondante, sans pour
autant modifier le message par défaut, pour ne pas alerter le visiteur
malhonnête.

Excusez-moi de mon erreur.

J'ai fait une sorte de lapsus, qui vient du fait que mon esprit était
un peu brouillé.

Ce problème de refresh, ne peut provenir, théoriquement, que de
l'appel au script public de prise en compte des données d'affichage du
sondage, dans la bdd. Le script d'administration, lui, est protégé par
login/password.

Donc, effectivement, authentification par variable de session au
niveau du script public de prise en compte dans la bdd, donc il
semblerait, qu'il faille supprimer la variable de session, ce qui aurait
pour effet de supprimer l'authentification par cette variable de
session, lors d'un refresh éventuel.

Mais... Si cet effacement de la variable de session juste à la fin de
la première exécution du deuxième script public ( dédié à
l'enregistrement dans la bdd ), si cet effacement permet d'éviter les
refresh, ne vaut-il pas mieux garder les adresses IP durant un délai
plus grand ( tout en les supprimant aussi après ce délai ), ce qui
servira, non pas à éviter les refresh, mais à permettre à des visiteurs
différents d'adresses IP identiques, de répondre au sondage ?

Dans ce cas, les adresses IP serviraient, à éviter que des visiteurs
répondent entièrement plusieurs fois au sondage, de manière répétée.

Le message d'acknowledgment donné par le deuxième script, ne variant
pas suivant succès ou échec, les hackers ne seraient pas censés
s'apercevoir du fait, qu'il leur est nécéssaire d'attendre pour refaire
le sondage.

Une question: Dans ce cas, pourriez-vous me dire, quel délai serait
envisageable, pour cette utilisation ?

Merci beaucoup à vous pour vos conseils.

Bien à vous.
Amicalement.

Jean-François Ortolo

--
Visitez mon site gratuit donnant des Statistiques
et des Historiques Graphiques sur les Courses de Chevaux:
http://www.ortolojf-courses.com

Bonjour Monsieur

J'ajoute, pour être plus clair:

La partie admin privée, est entièrement séparée de la partie
publique, qui sert, elle, aux sondages proprement dits.

La partie publique, comprendra deux scripts PHP, le premier contenant
uniquement une fonction d'affichage du sondage appelée par le script PHP
du site web, à l'endroit de l'affichage du sondage. Cette fonction ne
prendra qu'un paramètre numérique, qui sera l'indice du sondage affiché,
dont les données d'affichage et de sondage seront contenues entièrement
dans la base de données. Ce premier script sera inclus dans le script
PHP du site web. Le deuxième script public, quant à lui servira à
enregistrer dans la base de données, les données reçues en POST
provenant du premier script. Une variable de session assurera que cet
appel POST, provient bien du premier script correctement utilisé, et non
pas directement d'un hacker quelconque.


La partie admin, située dans un répertoire ad hoc séparé et protégé
par .htaccess et .htpasswd, avec login/password classique, sera composée
d'un seul script PHP, qui contiendra ce que j'ai déjà indiqué au début
de cet échange. Je préfère ne pas faire d'include dans ce script ( à
part celui du fichier de configuration ), car je ne veux pas que
d'autres scripts PHP inclus, puissent être éventuellement appelés de
façon intrusive.

Donc, la seule irrégularité possible pour la partie admin, concernera
ce script d'admin, protégé par login/password, et peut-être ( si vous
voulez me donner votre avis à ce sujet ) par une variable de session
assurant que tout appel POST à ce script, aura été fait par ce même script.

Ouf. Voilà le complément à ces messages que j'ai envoyés précédemment.

Bien à vous.
Amicalement.

Jean-François Ortolo

--
Visitez mon site gratuit donnant des Statistiques
et des Historiques Graphiques sur les Courses de Chevaux:
http://www.ortolojf-courses.com

Bonjour Monsieur Gallet

Ce problème de refresh, ne peut provenir, théoriquement, que de
l'appel au script public de prise en compte des données d'affichage du
sondage, dans la bdd. Le script d'administration, lui, est protégé par
login/password.

Donc, effectivement, authentification par variable de session au
niveau du deuxième script public de prise en compte dans la bdd, donc
il semblerait, qu'il faille supprimer la variable de session en fin
d'excéution du deuxième script public, ce qui aurait pour effet de
supprimer l'authentification par cette variable de session, lors d'un
refresh éventuel.

Mais... Si cet effacement de la variable de session juste à la fin de
la première exécution du deuxième script public ( dédié à
l'enregistrement dans la bdd ), si cet effacement permet d'éviter les
refresh, ne vaut-il pas mieux garder les adresses IP durant un délai
plus grand, tout en les supprimant aussi après ce délai, ce qui
servira, non pas à éviter les refresh, mais à permettre à des visiteurs
différents d'adresses IP identiques, de répondre au sondage ?

Dans ce cas, les adresses IP serviraient, à éviter que des visiteurs
répondent entièrement plusieurs fois au sondage, de manière répétée.

Le message d'acknowledgment donné par le deuxième script public, ne
variant pas suivant succès ou échec, les hackers ne seraient pas censés
s'apercevoir du fait, qu'il leur est nécéssaire d'attendre pour refaire
le sondage.

Une question: Dans ce cas, pourriez-vous me dire, quel délai serait
envisageable, pour cette utilisation ?

Ouf. Voilà le complément à ces messages que j'ai envoyés précédemment.

Bien à vous.
Amicalement.

Jean-François Ortolo