Processus a chaque ouverture de connexion
fmurgues
Messages postés
3
Date d'inscription
lundi 20 février 2006
Statut
Membre
Dernière intervention
21 février 2006
-
20 févr. 2006 à 15:38
cs_AlexN Messages postés 694 Date d'inscription lundi 5 décembre 2005 Statut Membre Dernière intervention 8 janvier 2014 - 21 févr. 2006 à 12:48
cs_AlexN Messages postés 694 Date d'inscription lundi 5 décembre 2005 Statut Membre Dernière intervention 8 janvier 2014 - 21 févr. 2006 à 12:48
A voir également:
- Processus a chaque ouverture de connexion
- Netmath connexion - Forum Visual Basic
- Il n'y a pas de processus à l'autre extrémité du canal - Forum ASP.NET
- Alternative processus excel ✓ - Forum C# / .NET
- Afficher userform vba a l'ouverture d'excel ✓ - Forum VBA Office (Excel, Word ...)
- Connexion base de données - Conseils pratiques -PHP
6 réponses
wxccxw
Messages postés
755
Date d'inscription
samedi 15 mai 2004
Statut
Membre
Dernière intervention
30 janvier 2011
20 févr. 2006 à 19:06
20 févr. 2006 à 19:06
tu met dans
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\system
un cle DWORD DisableTaskMgr a 1 et donc tu utilisateur ne peux plus ouvrir Ctrl Alt Supp
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\system
un cle DWORD DisableTaskMgr a 1 et donc tu utilisateur ne peux plus ouvrir Ctrl Alt Supp
cs_AlexN
Messages postés
694
Date d'inscription
lundi 5 décembre 2005
Statut
Membre
Dernière intervention
8 janvier 2014
19
20 févr. 2006 à 19:34
20 févr. 2006 à 19:34
Solution mutlithread:
explication :
- main crée un Thread pour l'utilisateur (Thread One)
- Le Thread utilisateur crée son propre Thread "Timer" (Thread Two) en lui passant une copie de son handle
ThreadOne tourne (en rond)...Thread Two compte...
Quand Thread Two a fini de compter, il termine le Thread One...
// TwoStopOne.cpp : Defines the entry point for the console application.
//
#include "stdafx.h"
#include <windows.h>
#include <windows.h>
void Erreur (char *Msg) {
fprintf(stderr, Msg);
ExitProcess (1);
}
DWORD WINAPI ThreadTwo (LPVOID lpvThreadParam) {
DWORD dwResult = 0;
printf("Dans le thread two\n");
Sleep(2000); // Timer
TerminateThread((HANDLE)lpvThreadParam , dwResult); // Terminer le Thread One
printf("Thread two fini\n");
return dwResult;
}
DWORD WINAPI ThreadOne (LPVOID lpvThreahParam) {
DWORD dwResult = 0, dwThreadId;
HANDLE hThread, hThreadOne;
printf("Dans le thread one\n");
DuplicateHandle(
GetCurrentProcess(),
GetCurrentThread(),
GetCurrentProcess(),
&hThreadOne, 0, FALSE, DUPLICATE_SAME_ACCESS);
hThread = CreateThread(NULL,0,ThreadTwo, (LPVOID)&hThreadOne, 0, &dwThreadId);
if ( hThread == NULL ) Erreur ("CreateThread(Two)");
CloseHandle(hThread);
while(1);
}
int main(int argc, char* argv[])
{
HANDLE hThread;
DWORD dwThreadId;
hThread = CreateThread(NULL,0,ThreadOne, NULL,0, &dwThreadId);
if ( hThread == NULL ) Erreur ("CreateThread(One)");
CloseHandle(hThread);
Sleep(5000);
return 0;
}
Les deux threads étant inclus dans le même processus. L'utilisateur ne
peut distinguer le Thread "Timer", il ne peut pas le stopper. (dans la
fenetre CTRLALTSUPPR, il ne peut faire qu'une chose terminer le
processus en entier)
Je sais pas si ça peut répondre à ta question.
explication :
- main crée un Thread pour l'utilisateur (Thread One)
- Le Thread utilisateur crée son propre Thread "Timer" (Thread Two) en lui passant une copie de son handle
ThreadOne tourne (en rond)...Thread Two compte...
Quand Thread Two a fini de compter, il termine le Thread One...
// TwoStopOne.cpp : Defines the entry point for the console application.
//
#include "stdafx.h"
#include <windows.h>
#include <windows.h>
void Erreur (char *Msg) {
fprintf(stderr, Msg);
ExitProcess (1);
}
DWORD WINAPI ThreadTwo (LPVOID lpvThreadParam) {
DWORD dwResult = 0;
printf("Dans le thread two\n");
Sleep(2000); // Timer
TerminateThread((HANDLE)lpvThreadParam , dwResult); // Terminer le Thread One
printf("Thread two fini\n");
return dwResult;
}
DWORD WINAPI ThreadOne (LPVOID lpvThreahParam) {
DWORD dwResult = 0, dwThreadId;
HANDLE hThread, hThreadOne;
printf("Dans le thread one\n");
DuplicateHandle(
GetCurrentProcess(),
GetCurrentThread(),
GetCurrentProcess(),
&hThreadOne, 0, FALSE, DUPLICATE_SAME_ACCESS);
hThread = CreateThread(NULL,0,ThreadTwo, (LPVOID)&hThreadOne, 0, &dwThreadId);
if ( hThread == NULL ) Erreur ("CreateThread(Two)");
CloseHandle(hThread);
while(1);
}
int main(int argc, char* argv[])
{
HANDLE hThread;
DWORD dwThreadId;
hThread = CreateThread(NULL,0,ThreadOne, NULL,0, &dwThreadId);
if ( hThread == NULL ) Erreur ("CreateThread(One)");
CloseHandle(hThread);
Sleep(5000);
return 0;
}
Les deux threads étant inclus dans le même processus. L'utilisateur ne
peut distinguer le Thread "Timer", il ne peut pas le stopper. (dans la
fenetre CTRLALTSUPPR, il ne peut faire qu'une chose terminer le
processus en entier)
Je sais pas si ça peut répondre à ta question.
fmurgues
Messages postés
3
Date d'inscription
lundi 20 février 2006
Statut
Membre
Dernière intervention
21 février 2006
21 févr. 2006 à 09:22
21 févr. 2006 à 09:22
Merci pr les reponses mais ca ne resoud pas mn pb du moins en partie :
pr la premiere reponse je l'avais deja mis en place par les groupes policies.
pr la deuxieme reponse l'idee d'avoir deux thread est bien mais le souci c'est qu'il suffit de terminer le process pere pr arreter le prog...
Il faudrait qu'il y ait deux proccess qui verifient chqe ms la presence des 2 mais là je suis depassé !!!
pr la premiere reponse je l'avais deja mis en place par les groupes policies.
pr la deuxieme reponse l'idee d'avoir deux thread est bien mais le souci c'est qu'il suffit de terminer le process pere pr arreter le prog...
Il faudrait qu'il y ait deux proccess qui verifient chqe ms la presence des 2 mais là je suis depassé !!!
cs_AlexN
Messages postés
694
Date d'inscription
lundi 5 décembre 2005
Statut
Membre
Dernière intervention
8 janvier 2014
19
21 févr. 2006 à 11:30
21 févr. 2006 à 11:30
Si tu veux empêcher le père (threadone, le thread utilisateur) de se
terminer avant que le fils (threadtwo) n'ai fini de compter, ca veut
dire que tu veux empêcher l'utilisateur de terminer sa connexion avant
que toi (threadtwo) l'ai décidé. Tu dois pouvoir laisser l'utilisateur
se deconnecter quand il le souhaite, même si le compteur n'est pas fini.
A mon avis un programme qui empêche l'utilisateur de terminer quand lui
a envie (ou qui ne s'arrête que quand le concepteur le décide, c'est
pareil) ne fera pas une longue carrière.
terminer avant que le fils (threadtwo) n'ai fini de compter, ca veut
dire que tu veux empêcher l'utilisateur de terminer sa connexion avant
que toi (threadtwo) l'ai décidé. Tu dois pouvoir laisser l'utilisateur
se deconnecter quand il le souhaite, même si le compteur n'est pas fini.
A mon avis un programme qui empêche l'utilisateur de terminer quand lui
a envie (ou qui ne s'arrête que quand le concepteur le décide, c'est
pareil) ne fera pas une longue carrière.
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
fmurgues
Messages postés
3
Date d'inscription
lundi 20 février 2006
Statut
Membre
Dernière intervention
21 février 2006
21 févr. 2006 à 11:42
21 févr. 2006 à 11:42
Entierement d'accord avec toi, je voudrais que l'utilisateur ne puisse l'arreter mais lors d'une fermeture de session qu'il n'y ait pas de pb.
Dc du coup je pense laisser tomber cette solutioin, en fait j'ai mis mon exe en service lancé par le cpte admin local de la machine.
Celui ci doit verifier si qqun et connecté lire la base de registre et declecncher le compteur.
Le souci est que lors du lancement de l'exe à la main pas de pb, il voit bien ds le registre un utilisateur (clé logon user name ds HKLM) et le cpteur peut se lancer. (le but c de verifier a chaque sec si cette clé logon existe pr savoir si un utilisateur est logué ou pas)
Par contre des qu'il se lance par le service ca plante...
Il ne reconnait pas cette clé.
Je pense qu'il doit y avoir un pb de droit mais la je ne vois pas.
ps : j'ai essayé de le lancer avec le cpte local, ca ne marche pas non plus (de tte facon, je pense que l'utilisateur pourrait larreter apres ...)
Dc du coup je pense laisser tomber cette solutioin, en fait j'ai mis mon exe en service lancé par le cpte admin local de la machine.
Celui ci doit verifier si qqun et connecté lire la base de registre et declecncher le compteur.
Le souci est que lors du lancement de l'exe à la main pas de pb, il voit bien ds le registre un utilisateur (clé logon user name ds HKLM) et le cpteur peut se lancer. (le but c de verifier a chaque sec si cette clé logon existe pr savoir si un utilisateur est logué ou pas)
Par contre des qu'il se lance par le service ca plante...
Il ne reconnait pas cette clé.
Je pense qu'il doit y avoir un pb de droit mais la je ne vois pas.
ps : j'ai essayé de le lancer avec le cpte local, ca ne marche pas non plus (de tte facon, je pense que l'utilisateur pourrait larreter apres ...)
cs_AlexN
Messages postés
694
Date d'inscription
lundi 5 décembre 2005
Statut
Membre
Dernière intervention
8 janvier 2014
19
21 févr. 2006 à 12:48
21 févr. 2006 à 12:48
Je ne sais pas si l'utilisation de la base de registres est legitime
dans ton cas. Là ça va, tu n'a qu'un seul utilisateur test. Mais dans
un vrai environnement multi-utilisateurs, tu vas encombrer ta base de
registres avec une multitude de petits compteurs. Tu risques d'avoir de
graves problèmes de perfomances (sauf son ton appli tourne juste pour
une personne) en lisant toutes les secondes ce gros pavé de windows. La
base de registres sert plus pour stocker des informations systèmes, que
des données de programmes.
D'autre part, si tu lances un service en arrière plan de "surveillance
de visiteurs" il faut faire attention à ne pas inverser les rôles, à
savoir, si ton service va régulièrement interroger quelquechose pour
savoir si quelqu'un est là, il peut mobiliser des ressources
inutilement. Tandis que s'il est réveillé uniquement quand quelqu'un
"frappe à la porte", c'est mieux.
Soit tu fais un processus "écouteur" qui toutes les secondes se
réveille pour fouiller la base de registres ou autre chose et voir s'il
y a quelqu'un et qui en plus décompte les secondes pour ceux qui sont
déjà connectés (coûte cher).
Soit tu fais un processus "écouteur", disons endormi, prêt à
créer une connexion et un compteur chaque fois qu'il reçoit une demande
d'ouverture de session (coûte moins cher, je pense).
L'idée avec le multithread est que chaque utilisateur dispose de son
propre compteur, libérant ainsi, main (le processus ecouteur) de
travail inutile (decompter le temps pour les utlisateurs deja
connectés). Et d'autre part, comme chaque compteur est intégré dans le
processus maitre, l'utilisateur n'a aucun accès, ni aucun contrôle
dessus.
Quant à tes problèmes de droits d'accès, ça peut venir du fait que la
base ou une partie n'est pas accessible à ton process. je sais pas..
dans ton cas. Là ça va, tu n'a qu'un seul utilisateur test. Mais dans
un vrai environnement multi-utilisateurs, tu vas encombrer ta base de
registres avec une multitude de petits compteurs. Tu risques d'avoir de
graves problèmes de perfomances (sauf son ton appli tourne juste pour
une personne) en lisant toutes les secondes ce gros pavé de windows. La
base de registres sert plus pour stocker des informations systèmes, que
des données de programmes.
D'autre part, si tu lances un service en arrière plan de "surveillance
de visiteurs" il faut faire attention à ne pas inverser les rôles, à
savoir, si ton service va régulièrement interroger quelquechose pour
savoir si quelqu'un est là, il peut mobiliser des ressources
inutilement. Tandis que s'il est réveillé uniquement quand quelqu'un
"frappe à la porte", c'est mieux.
Soit tu fais un processus "écouteur" qui toutes les secondes se
réveille pour fouiller la base de registres ou autre chose et voir s'il
y a quelqu'un et qui en plus décompte les secondes pour ceux qui sont
déjà connectés (coûte cher).
Soit tu fais un processus "écouteur", disons endormi, prêt à
créer une connexion et un compteur chaque fois qu'il reçoit une demande
d'ouverture de session (coûte moins cher, je pense).
L'idée avec le multithread est que chaque utilisateur dispose de son
propre compteur, libérant ainsi, main (le processus ecouteur) de
travail inutile (decompter le temps pour les utlisateurs deja
connectés). Et d'autre part, comme chaque compteur est intégré dans le
processus maitre, l'utilisateur n'a aucun accès, ni aucun contrôle
dessus.
Quant à tes problèmes de droits d'accès, ça peut venir du fait que la
base ou une partie n'est pas accessible à ton process. je sais pas..
