[Winsock] Désactiver Autodial par programme
Patrick Philippot
Voilà une question (difficile) que je n'ai jamais bien résolue et je ne
suis pas vraiment sûr qu'il y ait une réponse. Au cas où......
Je travaille actuellement sur une application (C++ / non MFC) qui doit
garantir que l'utilisateur ne modifie pas l'heure système. Sous Win9x,
cette garantie est impossible à donner mais on peut néanmoins mettre en
place des mesures préventives. Parmi celles-ci, l'appli essaye de
récupérer l'heure depuis un serveur SNTP. Cependant, il est hors de
question que ce mécanisme se déclenche s'il n'y a pas de connexion
active.
L'appel aux fonctions Winsock utilisées pour accéder au serveur SNTP
doit donc tout simplement échouer dans 100% des cas s'il n'y pas de
connexion active à Internet **et ne pas déclencher autodial**, pour mon
appli seulement bien sûr. Les réglages utilisateurs doivent rester
inchangés (ou être modifiés de manière temporaire).
Oui, je connais l'existence de la fonction InternetGetConnectedState
(WinInet) mais cette fonction n'est pas fiable et ne correspond pas au
besoin.
Merci d'avance.
--
Patrick Philippot
MainSoft Consulting Services
www.mainsoft.xx
(remplacez .xx par .fr si vous répondez par e-mail)
Remi Thomas
> Bonjour,
>
> Voilà une question (difficile) que je n'ai jamais bien résolue et je
> ne suis pas vraiment sûr qu'il y ait une réponse. Au cas où......
>
> Je travaille actuellement sur une application (C++ / non MFC) qui doit
> garantir que l'utilisateur ne modifie pas l'heure système. Sous Win9x,
> cette garantie est impossible à donner mais on peut néanmoins mettre
> en place des mesures préventives. Parmi celles-ci, l'appli essaye de
> récupérer l'heure depuis un serveur SNTP. Cependant, il est hors de
> question que ce mécanisme se déclenche s'il n'y a pas de connexion
> active.
>
> L'appel aux fonctions Winsock utilisées pour accéder au serveur SNTP
> doit donc tout simplement échouer dans 100% des cas s'il n'y pas de
> connexion active à Internet **et ne pas déclencher autodial**, pour
> mon appli seulement bien sûr. Les réglages utilisateurs doivent rester
> inchangés (ou être modifiés de manière temporaire).
>
> Oui, je connais l'existence de la fonction InternetGetConnectedState
> (WinInet) mais cette fonction n'est pas fiable et ne correspond pas au
> besoin.
>
> Merci d'avance.
J'aborderai le problème différemment en faisant un état des lieux de la
machine.
Si le poste est paramétré en AutoDial, alors retrouver le profil de
connexion par défaut, puis regarder si ce profil est connecté. Ensuite
regarder si un des profiles de connexion est connecté.
Je pense qu'une autre solution consiste à comptabiliser le nombre d'adresse
IP actuellement sur la machine. Si 0 alors ne pas faire de connexion. Si >0
alors désactiver l'autodial, tenter une connexion, réactiver l'autodial (si
il était actif). Si le teste est OK, alors détecter que l'adresse IP tombe,
sinon détecter qu'une nouvelle adresse IP apparaît.
Je ne sais pas comment fonctionne MSN Messenger mais il s'en sort assez bien
pour faire cela et se connecte dès qu'Internet est disponible.
Rémi
--
Rémi Thomas - MVP Visual Studio .NET
Développeur Windows indépendant
http://www.xtware.com/cv
Remi Thomas
> Je travaille actuellement sur une application (C++ / non MFC) qui doit
> garantir que l'utilisateur ne modifie pas l'heure système. Sous Win9x,
> cette garantie est impossible à donner mais on peut néanmoins mettre
> en place des mesures préventives. Parmi celles-ci, l'appli essaye de
> récupérer l'heure depuis un serveur SNTP. Cependant, il est hors de
> question que ce mécanisme se déclenche s'il n'y a pas de connexion
> active.
>
Sinon je verai bien aussi une petite application qui se lance au démarrage
de Windows et mémorise l'heure et le GetTickCount() correspondant. Ensuite
si tu remarques une dérive entre l'heure et le GetTickCount() tu remets la
bonne l'heure. Le seul moyen de passer outre serait de tuer ce daemon ou de
booter en DOS pour changer l'heure.
Cyrille "cns" Szymanski
> garantir que l'utilisateur ne modifie pas l'heure système. Sous Win9x,
> cette garantie est impossible à donner mais on peut néanmoins mettre en
> place des mesures préventives. Parmi celles-ci, l'appli essaye de
> récupérer l'heure depuis un serveur SNTP. Cependant, il est hors de
> question que ce mécanisme se déclenche s'il n'y a pas de connexion
> active.
Il est peut-être possible de contourner l'autodial en faisant un appel
direct à TDI voire à NDIS ? Il faut espérer que l'autodial se place au
dessus...
http://www.komodia.com/tools.htm
--
_|_|_| CnS
_|_| for(n=0;b;n++)
_| b&=b-1; /*pp.47 K&R*/
Cyrille "cns" Szymanski
> démarrage de Windows et mémorise l'heure et le GetTickCount()
> correspondant. Ensuite si tu remarques une dérive entre l'heure et le
> GetTickCount() tu remets la bonne l'heure. Le seul moyen de passer
> outre serait de tuer ce daemon ou de booter en DOS pour changer
> l'heure.
Ou de changer l'heure dans le bios....
Samuel KABAK
Patrick Philippot a écrit:
> Bonjour,
>
> Voilà une question (difficile) que je n'ai jamais bien résolue et je ne
> suis pas vraiment sûr qu'il y ait une réponse. Au cas où......
>
> Je travaille actuellement sur une application (C++ / non MFC) qui doit
> garantir que l'utilisateur ne modifie pas l'heure système.
Une question bête, qui voudrait d'une application qui empêche de
modifier l'heure du système, en particulier pour l'heure d'été/heure
d'hiver?
--
Samuel KABAK
http://www.codeas.net/
http://www.2b-alive.com/
Patrick Philippot
> Sinon je verai bien aussi une petite application qui se lance au
> démarrage de Windows et mémorise l'heure et le GetTickCount()
> correspondant. Ensuite si tu remarques une dérive entre l'heure et le
> GetTickCount() tu remets la bonne l'heure. Le seul moyen de passer
> outre serait de tuer ce daemon ou de booter en DOS pour changer
> l'heure.
C'est ce que je fais. Cela marche bien mais cela ne protège pas d'une
modif de l'heure via le BIOS ou bien d'une modif après boot sur une
disquette DOS. C'est pour cela que je veux, quand c'est possible, faire
une rapide mise à jour via SNTP au lancement de l'appli (qui sera un
service sous NT/2000/XP).
Il me vient une autre idée: pourquoi ne pas utiliser IPHLPAPI.DLL (IP
Helper API) et sa fonction GetIpForwardTable? Si la table de routage ne
contient aucune entrée de type "Remote Route", c'est que la machine
n'est pas connectée, que ce soit en dial-up, via cable ou ADSL. Cette
API est dispo depuis Win98 (sauf NT pre-SP4). Avantage: cette info est
remise à jour dès que la connexion est rompue.
--
Patrick Philippot - Microsoft MVP [.Net]
Patrick Philippot
> Une question bête, qui voudrait d'une application qui empêche de
> modifier l'heure du système, en particulier pour l'heure d'été/heure
> d'hiver?
Les modifs que je fais n'empêcheront pas le système de se mettre à jour
au passage été / hiver. Par contre, cette appli est une appli qui est
entièrement basée sur des réglages horaires. Pas question de laisser
l'utilisateur modifier l'heure système de manière fantaisiste.
--
Patrick Philippot - Microsoft MVP [.Net]
David Scrève
"Samuel KABAK" <samuel...@free.fr> a écrit dans le message de news:3F26732A...@free.fr...
>
>
> > Je travaille actuellement sur une application (C++ / non MFC) qui doit
> > garantir que l'utilisateur ne modifie pas l'heure système.
>
> Une question bête, qui voudrait d'une application qui empêche de
> modifier l'heure du système, en particulier pour l'heure d'été/heure
> d'hiver?
Au hasard : un soft de facturation de temps de connexion Internet dans un cybercafé...
David
Samuel KABAK
David Scrève a écrit:
Pas besoin, quand le timer est lancé le délai passé est géré en mémoire.
C'est mon avis personnel, mais je pense que faire confiance à l'heure de
la machine et empêcher que l'utilisateur la modifie n'est pas une
solution très orthodoxe. Je ne dis pas qu'il ne faut pas l'utiliser. Je
dis simplement que ce n'est pas très orthodoxe.
J'ai eu besoin de gérer la date pour mon dernier utilitaire ManSubIE
http://www.codeas.net/mansubie/
shareware limité à 3 jours
J'ai préféré utiliser une date incrémentale d'accès au fichier pour
deviner que l'utilisateur a changé la date. Mais je n'ai pas touché à
l'heure système.
Mais il faut dire que l'informatique n'est pas, comme on pourrait le
croire, une science exacte.
Christian ASTOR
> L'appel aux fonctions Winsock utilisées pour accéder au serveur SNTP
> doit donc tout simplement échouer dans 100% des cas s'il n'y pas de
> connexion active à Internet **et ne pas déclencher autodial**, pour mon
> appli seulement bien sûr. Les réglages utilisateurs doivent rester
> inchangés (ou être modifiés de manière temporaire).
EnableAutodial (registry, avant/après)
Patrick Philippot
> EnableAutodial (registry, avant/après)
Christian,
Ce n'est pas la solution pour moi. Comme je l'ai indiqué, cette appli va
tourner comme service sous NT / 2000 / XP: pas d'HKCU disponible à un
service tournant sous le compte SYSTEM.
--
Patrick Philippot - Microsoft MVP [.Net]
Patrick Philippot
> Pas besoin, quand le timer est lancé le délai passé est géré en
> mémoire.
>
> C'est mon avis personnel, mais je pense que faire confiance à l'heure
> de la machine et empêcher que l'utilisateur la modifie n'est pas une
> solution très orthodoxe.
Il ne s'agit pas de gérer une durée. Il s'agit dans cette application de
tenir compte de l'heure et de la date **réelles**. Je ne vois pas où est
l'orthodoxie ou non là-dedans. Si votre application est par exemple un
agenda qui rappelle des RdV à l'heure voulue, si vous décidez que faire
confiance à l'heure système n'est pas une solution "orthodoxe", vous
pouvez imaginer plusieurs approches qui le sont certainement plus:
1) Mettre en place un timer et sur chaque notification (disons toutes
les 5 minutes), demander à l'utilisateur de consulter sa montre (imposer
l'achat d'une Rolex au moment de l'acquisition du logiciel - sinon
refuser a) de garantir le fonctionnement du programme et b) tout support
technique), d'entrer la valeur lue dans une boîte de dialogue et faire
ensuite une recherche dans la base de données pour voir si l'heure
entrée n'est pas à moins de n minutes d'un RdV enregistré. Penser à
inclure l'obligation de changement de la pile de la montre dans le
contrat de licence.
2) Faire un dialup automatique de l'horloge parlante toutes les 5
minutes, capturer le son, l'interpréter au travers d'un module
multimedia spécialisé, en déduire l'heure courante et procéder comme en
(1).
3) Demander à l'utilisateur d'imprimer son agenda et lui rappeler
régulièrement de le consulter, il pourrait manquer un RdV.
4) Repérer une horloge publique visible de la fenêtre du bureau de
l'utilisateur, braquer sa Webcam dessus, analyser l'image en continu via
un logiciel développé spécialement pour les pratiquants de l'orthodoxie
horaire et procéder ensuite comme en (1).
5) Joindre à la documentation de l'application un horaire SNCF, ne la
vendre qu'à des utilisateurs qui habitent près d'une voie ferrée, leur
demander de bien repérer à quelle heure et dans quel sens les trains
passent devant chez eux et proposer un système de positionnement des RdV
de la journée en association avec les numéros des trains. Solution
alternative: vendre une vache avec chaque logiciel et déléguer
l'observation des trains au ruminant en question. Brancher le PC sur la
vache via des capteurs installés sur ses glandes mammaires analysant sa
production laitière. Enregistrer la corrélation entre cette production
et le passage des trains (prévoir cette phase dans le logiciel
d'installation).
:-)))
On se demande d'ailleurs pourquoi NT / 2000 / XP mettent des verrous de
sécurité sur le changement de l'heure système si la modifier n'a aucun
impact sur les applis "orthodoxes".
Pour conclure, vous noterez que Visual Studio, par exemple, n'est pas
une appli orthodoxe de ce point de vue : si vous modifiez de manière
inconsidérée l'heure système, il refusera parfois de recompiler des
fichiers que vous avez pourtant modifiés. Aberrant, non? Je pense que
Visual Studio, avant toute compilation et sauvegarde de fichier source,
devrait émettre une requête SNTP pour mettre à jour l'horloge et si ce
n'est pas possible, présenter au développeur un message d'avertissement
lui demandant systématiquement de vérifier l'heure de son système.
--
Patrick Philippot - Microsoft MVP [.Net]
Ambassadeur Kosh
hors, sous ces systemes les non administrateurs n'ont pas la permission de
changer l'heure.
une subtilité a du m'échapper, parceque la, on dirait "probleme reglé :
utiliser les comptes".
non ?
Dominique Vaufreydaz
Ambassadeur Kosh wrote:
> cette appli doit tourner sous NT/2000/XP
> hors, sous ces systemes les non administrateurs n'ont pas la permission de
> changer l'heure.
> une subtilité a du m'échapper, parceque la, on dirait "probleme reglé :
> utiliser les comptes".
Ben non en fait. Copmme beaucoup de gens font des net time pour
mettre a l'heure leur machine (heretiques !!), ils donnent le droit
aux utilisateurs de modifier l'heure.
Et puis, l'administrateur n'est pas exempt d'utiliser ce programme.
Doms;
--
Impose ta chance, serre ton bonheur et va vers ton risque.
A te regarder, ils s'habitueront.
René Char, Les Matinaux.
----
http://www-prima.inrialpes.fr/Vaufreydaz/
http://slmg.imag.fr/
http://slmg-index.imag.fr/
http://TitchKaRa.free.fr/
http://logiciels.ntfaqfr.com/
Patrick Philippot
>> une subtilité a du m'échapper, parceque la, on dirait "probleme
>> reglé : utiliser les comptes".
>
> Ben non en fait. Copmme beaucoup de gens font des net time pour
> mettre a l'heure leur machine (heretiques !!), ils donnent le
> droit aux utilisateurs de modifier l'heure.
> Et puis, l'administrateur n'est pas exempt d'utiliser ce
> programme.
Et puis l'appli doit également tourner sous Win98 / Me et je limite le
plus possible le code qui diffère en fonction de la version de Windows
(ce qui n'est déjà pas incroyablement simple dans le cas précis). Non,
il me faut absolument un système de contrôle.
Patrick Philippot
> Il me vient une autre idée: pourquoi ne pas utiliser IPHLPAPI.DLL (IP
> Helper API) et sa fonction GetIpForwardTable? Si la table de routage
> ne contient aucune entrée de type "Remote Route", c'est que la machine
> n'est pas connectée, que ce soit en dial-up, via cable ou ADSL. Cette
> API est dispo depuis Win98 (sauf NT pre-SP4). Avantage: cette info est
> remise à jour dès que la connexion est rompue.
J'ai testé ça et ça a l'air de bien fonctionner mais je me suis trompé
sur ce qu'il fallait tester. En fait, il faut simplement vérifier si la
table de routage possède une entrée par défaut sur une gateway
(0.0.0.0). Si cette entrée existe, la machine est soit connectée en
dial-up, par cable, par ADSL ou via un réseau mais elle a une connexion
remote (valide ou non). En dial-up, cette entrée disparaît dès que l'on
a raccroché le modem.
Je peux ensuite faire une tentative d'accès au serveur. Si la liaison
est vraiment valide, l'accès va réussir. Si elle ne l'est pas, l'accès
va échouer sans pour cela me jeter la dialog box de dial-up à la figure,
ce qui est exactement ce que je veux. Seul inconvéneint Win95 et NT
pre-SP4 ne supporte pas IPHLPAPI.DLL.
J'ai écrit un programme de test qui va être tourné sur différentes
configs. Si les test sont concluants, je posterai le code.
Ambassadeur Kosh
bon courage.
Patrick Philippot
> En fait, il faut simplement vérifier si la table de routage
> possède une entrée par défaut sur une gateway
> (0.0.0.0). Si cette entrée existe, la machine est soit connectée en
> dial-up, par cable, par ADSL ou via un réseau mais elle a une
> connexion remote (valide ou non). En dial-up, cette entrée disparaît
> dès que l'on a raccroché le modem.
Bon, les tests avancent et ça se confirme (98, Me, NT4, 2000, XP - en
dial-up et ADSL). Le procédé est simple (quelques lignes de code) et
semble beaucoup plus fiable que les GetInternetConnectedState et autres
APIS dont le résultat est plus qu'aléatoire. Et surtout, il n'y a aucun
risque de déclencher autodial.
Ce qui me surprend, c'est que cette solution ne soit jamais proposée sur
les différents sites de développement. Ou alors ceux qui y ont pensé la
garde pour eux. J'ai déjà eu à régler ce problème il y a 2 ou 3 ans et
j'avais utilisé une méthode assez peu élégante. Le code que j'ai vu sur
ces différents sites est également en général peu efficace. Heureusement
que j'ai lu un commentaire sur codeguru qui m'a mis la puce à
l'oreille...