Voici une situation nouvelle que les développeurs doivent considérer afin de
protéger leurs logiciels contre une forme déguisée de copies illégales.
Voici un exemple pratique de ce que je veux dire.
Un client achète notre logiciel version réseau et l'installe sur son
serveur. Le logiciel est ensuite activé et barré sur ce serveur.
Le client branche ensuite ses stations avec un icône sur le bureau qui
pointe simplement vers l'application installée sur le serveur. Si tout se
passe en réseau local il n'y a aucun problème, tout est légal.
Vous connaissez le logiciel LogMeIn ? Cela permet à un usager extérieur de
se connecter sur un ordinateur local en utilisant Internet. C'est comme un
genre de peer-to-peer qui était beaucoup utilisé à l'époque - mais en
passant par Internet.
C'est très connu mais je viens de le découvrir. La copie gratuite est très
utilisée.
Voici le site français :
http://secure.logmein.com/welcome/logmeinrescueintro/rescue.asp?lang=fr
C'est formidable comme concept et ça peut être très utile pour tout
développeur pour dépanner un client à distance.
Mais le problème est le suivant. Si notre client se branche à distance avec
LogMeIn sur son serveur pour exécuter depuis chez lui le logiciel situé dans
son magasin, ce n'est pas un problème MAIS si un client achète une version
réseau et qu'il permet à 50 autres utilisateurs extérieurs d'utiliser son
logiciel depuis son Master à lui... alors ça va pas du tout.
Vous voyez ce que je veux dire?
Quelqu'un a une bonne idée pour résoudre ce problème?
Le Tue, 26 Jun 2007 10:30:16 +0200, patrice a écrit:
"Real Phil" a écrit dans le message de news:xkVfi.6624$
> interdire d'étre lancé depuis une copie amovible > ou développer une protection groupware (avec comptage des utilisateurs > connectés) > Salut Patrice,
Tu es certain qu'un utilisateur branché à distance avec LogMeIn ou Pc-Anywhere est toujours identifié comme utilisant une copie amovible ?
non tu as raison, il sera vu comme un utilisateur normal. Compte plutot le nombre de session totale. je te conseille un fichier de verrou tu crée un fichier de n enregistrement tu essaie de locker de 1 à n jusqu'a trouver une place libre si tu peux pas => max utilisateur dépassé
Sauf erreur de ma part , sous Windows , un utilisateur connecté par PCAW ou VNC n'est PAS un autre utilisateur avec une autre session , c'est le même que celui du PC avec sa session (c'est un simple déport de clavier/écran/souris à distance). Ce n'est pas le cas avec VNC sur serveur Unix où cela ouvre une session.
-- J.Bratières
Le Tue, 26 Jun 2007 10:30:16 +0200, patrice <patrice@idea.dnsalias.net> a
écrit:
"Real Phil" <_pasde_Spam_realp@ultra.ca> a écrit dans le message de
news:xkVfi.6624$v5.82403@wagner.videotron.net...
> interdire d'étre lancé depuis une copie amovible
> ou développer une protection groupware (avec comptage des utilisateurs
> connectés)
>
Salut Patrice,
Tu es certain qu'un utilisateur branché à distance avec LogMeIn ou
Pc-Anywhere est toujours identifié comme utilisant une copie amovible ?
non tu as raison, il sera vu comme un utilisateur normal.
Compte plutot le nombre de session totale.
je te conseille un fichier de verrou
tu crée un fichier de n enregistrement
tu essaie de locker de 1 à n jusqu'a trouver une place libre
si tu peux pas => max utilisateur dépassé
Sauf erreur de ma part , sous Windows , un utilisateur connecté par PCAW
ou VNC n'est PAS un autre utilisateur avec une autre session , c'est le
même que celui du PC avec sa session (c'est un simple déport de
clavier/écran/souris à distance). Ce n'est pas le cas avec VNC sur serveur
Unix où cela ouvre
une session.
Le Tue, 26 Jun 2007 10:30:16 +0200, patrice a écrit:
"Real Phil" a écrit dans le message de news:xkVfi.6624$
> interdire d'étre lancé depuis une copie amovible > ou développer une protection groupware (avec comptage des utilisateurs > connectés) > Salut Patrice,
Tu es certain qu'un utilisateur branché à distance avec LogMeIn ou Pc-Anywhere est toujours identifié comme utilisant une copie amovible ?
non tu as raison, il sera vu comme un utilisateur normal. Compte plutot le nombre de session totale. je te conseille un fichier de verrou tu crée un fichier de n enregistrement tu essaie de locker de 1 à n jusqu'a trouver une place libre si tu peux pas => max utilisateur dépassé
Sauf erreur de ma part , sous Windows , un utilisateur connecté par PCAW ou VNC n'est PAS un autre utilisateur avec une autre session , c'est le même que celui du PC avec sa session (c'est un simple déport de clavier/écran/souris à distance). Ce n'est pas le cas avec VNC sur serveur Unix où cela ouvre une session.
-- J.Bratières
Real Phil
Oui, tu as raison mais avec cette méthode il ne faut plus utiliser l'interrupteur. Tout est remplacé par les blocages d'enregistrements.
Jette un coup d'oeil à la dernière réponse de Patrice reçue après que je t'ai envoyé la suggestion.
"JP Courseille" a écrit dans le message de news:4680b36e$0$23905$
Il me semble que meme dans ce cas l'interrupteur resterait a 1 puisque l'enregistrement a bien eu lieu. Des qu il tape sont mot de passe je fais un hmodifie
"Real Phil" a écrit dans le message de news: mk2gi.11103$ > C'est pas mauvais ton truc et je vais considérer. > > Pour régler le fait d'un utilisateur qui plante et qui ne remet pas > l'interrupteur à 0, il y a un truc que j'aimerais bien essayer et qui > pourrais t'être utile - si ça fonctionne ;-) > > Considérant 1 utilisateur par enregistrement - un fichier de gestion des > Login. > Quand un utilisateur est validé tu bloque cet enregistrement avec > HBloqueNumEnr() et tu le laisse bloqué. Si jamais cet usager plante j'ai > bien l'impression que cet enregistrement ne reste pas bloqué et il peut
se
> connecter à nouveau sans problème. Tu vois l'idée? > > Si jamais tu l'essai j'apprécierais que tu m'en donne des nouvelles. > >
Oui, tu as raison mais avec cette méthode il ne faut plus utiliser
l'interrupteur. Tout est remplacé par les blocages d'enregistrements.
Jette un coup d'oeil à la dernière réponse de Patrice reçue après que je
t'ai envoyé la suggestion.
"JP Courseille" <J.courseille@chello.fr> a écrit dans le message de
news:4680b36e$0$23905$79c14f64@nan-newsreader-06.noos.net...
Il me semble que meme dans ce cas l'interrupteur resterait a 1
puisque l'enregistrement a bien eu lieu.
Des qu il tape sont mot de passe je fais un hmodifie
"Real Phil" <_pasde_Spam_realp@ultra.ca> a écrit dans le message de news:
mk2gi.11103$v5.162734@wagner.videotron.net...
> C'est pas mauvais ton truc et je vais considérer.
>
> Pour régler le fait d'un utilisateur qui plante et qui ne remet pas
> l'interrupteur à 0, il y a un truc que j'aimerais bien essayer et qui
> pourrais t'être utile - si ça fonctionne ;-)
>
> Considérant 1 utilisateur par enregistrement - un fichier de gestion des
> Login.
> Quand un utilisateur est validé tu bloque cet enregistrement avec
> HBloqueNumEnr() et tu le laisse bloqué. Si jamais cet usager plante j'ai
> bien l'impression que cet enregistrement ne reste pas bloqué et il peut
se
> connecter à nouveau sans problème. Tu vois l'idée?
>
> Si jamais tu l'essai j'apprécierais que tu m'en donne des nouvelles.
>
>
Oui, tu as raison mais avec cette méthode il ne faut plus utiliser l'interrupteur. Tout est remplacé par les blocages d'enregistrements.
Jette un coup d'oeil à la dernière réponse de Patrice reçue après que je t'ai envoyé la suggestion.
"JP Courseille" a écrit dans le message de news:4680b36e$0$23905$
Il me semble que meme dans ce cas l'interrupteur resterait a 1 puisque l'enregistrement a bien eu lieu. Des qu il tape sont mot de passe je fais un hmodifie
"Real Phil" a écrit dans le message de news: mk2gi.11103$ > C'est pas mauvais ton truc et je vais considérer. > > Pour régler le fait d'un utilisateur qui plante et qui ne remet pas > l'interrupteur à 0, il y a un truc que j'aimerais bien essayer et qui > pourrais t'être utile - si ça fonctionne ;-) > > Considérant 1 utilisateur par enregistrement - un fichier de gestion des > Login. > Quand un utilisateur est validé tu bloque cet enregistrement avec > HBloqueNumEnr() et tu le laisse bloqué. Si jamais cet usager plante j'ai > bien l'impression que cet enregistrement ne reste pas bloqué et il peut
se
> connecter à nouveau sans problème. Tu vois l'idée? > > Si jamais tu l'essai j'apprécierais que tu m'en donne des nouvelles. > >
Real Phil
Bonjour Patrice,
Et si, au lieu de chercher les enregistrements libres, j'assignais les postes des utilisateurs selon leurs nos d'enregistrements bien identifés par leurs noms ou leurs nos de disque dur, ça fonctionnerait? (en bloquant aussi cet enregistrement bien sûr)
Par exemple, l'enregistrement no 4 = le poste 4 , etc... De cette façon ça évite la recherche et le même poste physique aurait toujours le même numéro. C'est pratique quand des erreurs se produisent on peut savoir la date, l'heure et le no du poste qui a causé l'erreur - ou encore pour savoir où s'est effectuée une transaction particulière.
Qu'en penses-tu?
Et, est-ce qu'on ne doit pas aussi réduire la valeur de H.NbEssais pour accélérer la validation si bloqué ou non ? Sinon on doit attendre le délais fixé par H.NbEssais qui est de 50 par défaut - soit plusieurs secondes à chaque vérification.
Réal Phil
> non tu as raison, il sera vu comme un utilisateur normal. > Compte plutot le nombre de session totale. > je te conseille un fichier de verrou > tu crée un fichier de n enregistrement > tu essaie de locker de 1 à n jusqu'a trouver une place libre > si tu peux pas => max utilisateur dépassé J.Bratières
Bonjour Patrice,
Et si, au lieu de chercher les enregistrements libres, j'assignais les
postes des utilisateurs selon leurs nos d'enregistrements bien identifés par
leurs noms ou leurs nos de disque dur, ça fonctionnerait? (en bloquant aussi
cet enregistrement bien sûr)
Par exemple, l'enregistrement no 4 = le poste 4 , etc...
De cette façon ça évite la recherche et le même poste physique aurait
toujours le même numéro. C'est pratique quand des erreurs se produisent on
peut savoir la date, l'heure et le no du poste qui a causé l'erreur - ou
encore pour savoir où s'est effectuée une transaction particulière.
Qu'en penses-tu?
Et, est-ce qu'on ne doit pas aussi réduire la valeur de H.NbEssais pour
accélérer la validation si bloqué ou non ?
Sinon on doit attendre le délais fixé par H.NbEssais qui est de 50 par
défaut - soit plusieurs secondes à chaque vérification.
Réal Phil
> non tu as raison, il sera vu comme un utilisateur normal.
> Compte plutot le nombre de session totale.
> je te conseille un fichier de verrou
> tu crée un fichier de n enregistrement
> tu essaie de locker de 1 à n jusqu'a trouver une place libre
> si tu peux pas => max utilisateur dépassé
J.Bratières
Et si, au lieu de chercher les enregistrements libres, j'assignais les postes des utilisateurs selon leurs nos d'enregistrements bien identifés par leurs noms ou leurs nos de disque dur, ça fonctionnerait? (en bloquant aussi cet enregistrement bien sûr)
Par exemple, l'enregistrement no 4 = le poste 4 , etc... De cette façon ça évite la recherche et le même poste physique aurait toujours le même numéro. C'est pratique quand des erreurs se produisent on peut savoir la date, l'heure et le no du poste qui a causé l'erreur - ou encore pour savoir où s'est effectuée une transaction particulière.
Qu'en penses-tu?
Et, est-ce qu'on ne doit pas aussi réduire la valeur de H.NbEssais pour accélérer la validation si bloqué ou non ? Sinon on doit attendre le délais fixé par H.NbEssais qui est de 50 par défaut - soit plusieurs secondes à chaque vérification.
Réal Phil
> non tu as raison, il sera vu comme un utilisateur normal. > Compte plutot le nombre de session totale. > je te conseille un fichier de verrou > tu crée un fichier de n enregistrement > tu essaie de locker de 1 à n jusqu'a trouver une place libre > si tu peux pas => max utilisateur dépassé J.Bratières
patrice
"Real Phil" a écrit dans le message de news:mO9gi.77451$
Bonjour Patrice,
Et si, au lieu de chercher les enregistrements libres, j'assignais les postes des utilisateurs selon leurs nos d'enregistrements bien identifés
par
leurs noms ou leurs nos de disque dur, ça fonctionnerait? (en bloquant
aussi
cet enregistrement bien sûr)
pourquoi pas... a condition que l'utilisateur saisie son poste (ou que tu ai les moyens de connaitre son poste)
Par exemple, l'enregistrement no 4 = le poste 4 , etc... De cette façon ça évite la recherche et le même poste physique aurait toujours le même numéro. C'est pratique quand des erreurs se produisent on peut savoir la date, l'heure et le no du poste qui a causé l'erreur - ou encore pour savoir où s'est effectuée une transaction particulière.
Qu'en penses-tu?
Et, est-ce qu'on ne doit pas aussi réduire la valeur de H.NbEssais pour accélérer la validation si bloqué ou non ?
non : - test si locké: oui => erreur poste déjà lancé - si non, tu lock sans te soucié du timeout (car soit ca marche, soit ils sont 2 ou plus à utiliser le meme n° de poste)(et les "vilains" vont attendre) :))
"Real Phil" <_pasde_Spam_realp@ultra.ca> a écrit dans le message de
news:mO9gi.77451$lI4.465681@weber.videotron.net...
Bonjour Patrice,
Et si, au lieu de chercher les enregistrements libres, j'assignais les
postes des utilisateurs selon leurs nos d'enregistrements bien identifés
par
leurs noms ou leurs nos de disque dur, ça fonctionnerait? (en bloquant
aussi
cet enregistrement bien sûr)
pourquoi pas... a condition que l'utilisateur saisie son poste (ou que tu ai
les moyens de connaitre son poste)
Par exemple, l'enregistrement no 4 = le poste 4 , etc...
De cette façon ça évite la recherche et le même poste physique aurait
toujours le même numéro. C'est pratique quand des erreurs se produisent on
peut savoir la date, l'heure et le no du poste qui a causé l'erreur - ou
encore pour savoir où s'est effectuée une transaction particulière.
Qu'en penses-tu?
Et, est-ce qu'on ne doit pas aussi réduire la valeur de H.NbEssais pour
accélérer la validation si bloqué ou non ?
non :
- test si locké: oui => erreur poste déjà lancé
- si non, tu lock sans te soucié du timeout
(car soit ca marche, soit ils sont 2 ou plus à utiliser le meme n° de
poste)(et les "vilains" vont attendre) :))
"Real Phil" a écrit dans le message de news:mO9gi.77451$
Bonjour Patrice,
Et si, au lieu de chercher les enregistrements libres, j'assignais les postes des utilisateurs selon leurs nos d'enregistrements bien identifés
par
leurs noms ou leurs nos de disque dur, ça fonctionnerait? (en bloquant
aussi
cet enregistrement bien sûr)
pourquoi pas... a condition que l'utilisateur saisie son poste (ou que tu ai les moyens de connaitre son poste)
Par exemple, l'enregistrement no 4 = le poste 4 , etc... De cette façon ça évite la recherche et le même poste physique aurait toujours le même numéro. C'est pratique quand des erreurs se produisent on peut savoir la date, l'heure et le no du poste qui a causé l'erreur - ou encore pour savoir où s'est effectuée une transaction particulière.
Qu'en penses-tu?
Et, est-ce qu'on ne doit pas aussi réduire la valeur de H.NbEssais pour accélérer la validation si bloqué ou non ?
non : - test si locké: oui => erreur poste déjà lancé - si non, tu lock sans te soucié du timeout (car soit ca marche, soit ils sont 2 ou plus à utiliser le meme n° de poste)(et les "vilains" vont attendre) :))
Real Phil
Et bien, un GROS merci pour tout Patrice et bonne journée.
Réal Phil
"patrice" a écrit dans le message de news:46812d59$0$5109$
"Real Phil" a écrit dans le message de news:mO9gi.77451$ > Bonjour Patrice, > > Et si, au lieu de chercher les enregistrements libres, j'assignais les > postes des utilisateurs selon leurs nos d'enregistrements bien identifés par > leurs noms ou leurs nos de disque dur, ça fonctionnerait? (en bloquant aussi > cet enregistrement bien sûr)
pourquoi pas... a condition que l'utilisateur saisie son poste (ou que tu
ai
les moyens de connaitre son poste)
> Par exemple, l'enregistrement no 4 = le poste 4 , etc... > De cette façon ça évite la recherche et le même poste physique aurait > toujours le même numéro. C'est pratique quand des erreurs se produisent
on
> peut savoir la date, l'heure et le no du poste qui a causé l'erreur - ou > encore pour savoir où s'est effectuée une transaction particulière. > > Qu'en penses-tu? > > Et, est-ce qu'on ne doit pas aussi réduire la valeur de H.NbEssais pour > accélérer la validation si bloqué ou non ? non : - test si locké: oui => erreur poste déjà lancé - si non, tu lock sans te soucié du timeout (car soit ca marche, soit ils sont 2 ou plus à utiliser le meme n° de poste)(et les "vilains" vont attendre) :))
Et bien, un GROS merci pour tout Patrice et bonne journée.
Réal Phil
"patrice" <patrice@idea.dnsalias.net> a écrit dans le message de
news:46812d59$0$5109$ba4acef3@news.orange.fr...
"Real Phil" <_pasde_Spam_realp@ultra.ca> a écrit dans le message de
news:mO9gi.77451$lI4.465681@weber.videotron.net...
> Bonjour Patrice,
>
> Et si, au lieu de chercher les enregistrements libres, j'assignais les
> postes des utilisateurs selon leurs nos d'enregistrements bien identifés
par
> leurs noms ou leurs nos de disque dur, ça fonctionnerait? (en bloquant
aussi
> cet enregistrement bien sûr)
pourquoi pas... a condition que l'utilisateur saisie son poste (ou que tu
ai
les moyens de connaitre son poste)
> Par exemple, l'enregistrement no 4 = le poste 4 , etc...
> De cette façon ça évite la recherche et le même poste physique aurait
> toujours le même numéro. C'est pratique quand des erreurs se produisent
on
> peut savoir la date, l'heure et le no du poste qui a causé l'erreur - ou
> encore pour savoir où s'est effectuée une transaction particulière.
>
> Qu'en penses-tu?
>
> Et, est-ce qu'on ne doit pas aussi réduire la valeur de H.NbEssais pour
> accélérer la validation si bloqué ou non ?
non :
- test si locké: oui => erreur poste déjà lancé
- si non, tu lock sans te soucié du timeout
(car soit ca marche, soit ils sont 2 ou plus à utiliser le meme n° de
poste)(et les "vilains" vont attendre) :))
Et bien, un GROS merci pour tout Patrice et bonne journée.
Réal Phil
"patrice" a écrit dans le message de news:46812d59$0$5109$
"Real Phil" a écrit dans le message de news:mO9gi.77451$ > Bonjour Patrice, > > Et si, au lieu de chercher les enregistrements libres, j'assignais les > postes des utilisateurs selon leurs nos d'enregistrements bien identifés par > leurs noms ou leurs nos de disque dur, ça fonctionnerait? (en bloquant aussi > cet enregistrement bien sûr)
pourquoi pas... a condition que l'utilisateur saisie son poste (ou que tu
ai
les moyens de connaitre son poste)
> Par exemple, l'enregistrement no 4 = le poste 4 , etc... > De cette façon ça évite la recherche et le même poste physique aurait > toujours le même numéro. C'est pratique quand des erreurs se produisent
on
> peut savoir la date, l'heure et le no du poste qui a causé l'erreur - ou > encore pour savoir où s'est effectuée une transaction particulière. > > Qu'en penses-tu? > > Et, est-ce qu'on ne doit pas aussi réduire la valeur de H.NbEssais pour > accélérer la validation si bloqué ou non ? non : - test si locké: oui => erreur poste déjà lancé - si non, tu lock sans te soucié du timeout (car soit ca marche, soit ils sont 2 ou plus à utiliser le meme n° de poste)(et les "vilains" vont attendre) :))
JP Courseille
Je note cette idée de blocage qui me parait bonne et a l'occasion je la testerai
Merci pour cette suggestion
"Real Phil" a écrit dans le message de news: 9f9gi.75253$
Oui, tu as raison mais avec cette méthode il ne faut plus utiliser l'interrupteur. Tout est remplacé par les blocages d'enregistrements.
Jette un coup d'oeil à la dernière réponse de Patrice reçue après que je t'ai envoyé la suggestion.
"JP Courseille" a écrit dans le message de news:4680b36e$0$23905$
Il me semble que meme dans ce cas l'interrupteur resterait a 1 puisque l'enregistrement a bien eu lieu. Des qu il tape sont mot de passe je fais un hmodifie
"Real Phil" a écrit dans le message de news: mk2gi.11103$ > C'est pas mauvais ton truc et je vais considérer. > > Pour régler le fait d'un utilisateur qui plante et qui ne remet pas > l'interrupteur à 0, il y a un truc que j'aimerais bien essayer et qui > pourrais t'être utile - si ça fonctionne ;-) > > Considérant 1 utilisateur par enregistrement - un fichier de gestion > des > Login. > Quand un utilisateur est validé tu bloque cet enregistrement avec > HBloqueNumEnr() et tu le laisse bloqué. Si jamais cet usager plante > j'ai > bien l'impression que cet enregistrement ne reste pas bloqué et il peut
se
> connecter à nouveau sans problème. Tu vois l'idée? > > Si jamais tu l'essai j'apprécierais que tu m'en donne des nouvelles. > >
Je note cette idée de blocage qui me parait bonne
et a l'occasion je la testerai
Merci pour cette suggestion
"Real Phil" <_pasde_Spam_realp@ultra.ca> a écrit dans le message de news:
9f9gi.75253$lI4.459377@weber.videotron.net...
Oui, tu as raison mais avec cette méthode il ne faut plus utiliser
l'interrupteur. Tout est remplacé par les blocages d'enregistrements.
Jette un coup d'oeil à la dernière réponse de Patrice reçue après que je
t'ai envoyé la suggestion.
"JP Courseille" <J.courseille@chello.fr> a écrit dans le message de
news:4680b36e$0$23905$79c14f64@nan-newsreader-06.noos.net...
Il me semble que meme dans ce cas l'interrupteur resterait a 1
puisque l'enregistrement a bien eu lieu.
Des qu il tape sont mot de passe je fais un hmodifie
"Real Phil" <_pasde_Spam_realp@ultra.ca> a écrit dans le message de news:
mk2gi.11103$v5.162734@wagner.videotron.net...
> C'est pas mauvais ton truc et je vais considérer.
>
> Pour régler le fait d'un utilisateur qui plante et qui ne remet pas
> l'interrupteur à 0, il y a un truc que j'aimerais bien essayer et qui
> pourrais t'être utile - si ça fonctionne ;-)
>
> Considérant 1 utilisateur par enregistrement - un fichier de gestion
> des
> Login.
> Quand un utilisateur est validé tu bloque cet enregistrement avec
> HBloqueNumEnr() et tu le laisse bloqué. Si jamais cet usager plante
> j'ai
> bien l'impression que cet enregistrement ne reste pas bloqué et il peut
se
> connecter à nouveau sans problème. Tu vois l'idée?
>
> Si jamais tu l'essai j'apprécierais que tu m'en donne des nouvelles.
>
>
Je note cette idée de blocage qui me parait bonne et a l'occasion je la testerai
Merci pour cette suggestion
"Real Phil" a écrit dans le message de news: 9f9gi.75253$
Oui, tu as raison mais avec cette méthode il ne faut plus utiliser l'interrupteur. Tout est remplacé par les blocages d'enregistrements.
Jette un coup d'oeil à la dernière réponse de Patrice reçue après que je t'ai envoyé la suggestion.
"JP Courseille" a écrit dans le message de news:4680b36e$0$23905$
Il me semble que meme dans ce cas l'interrupteur resterait a 1 puisque l'enregistrement a bien eu lieu. Des qu il tape sont mot de passe je fais un hmodifie
"Real Phil" a écrit dans le message de news: mk2gi.11103$ > C'est pas mauvais ton truc et je vais considérer. > > Pour régler le fait d'un utilisateur qui plante et qui ne remet pas > l'interrupteur à 0, il y a un truc que j'aimerais bien essayer et qui > pourrais t'être utile - si ça fonctionne ;-) > > Considérant 1 utilisateur par enregistrement - un fichier de gestion > des > Login. > Quand un utilisateur est validé tu bloque cet enregistrement avec > HBloqueNumEnr() et tu le laisse bloqué. Si jamais cet usager plante > j'ai > bien l'impression que cet enregistrement ne reste pas bloqué et il peut
se
> connecter à nouveau sans problème. Tu vois l'idée? > > Si jamais tu l'essai j'apprécierais que tu m'en donne des nouvelles. > >
