Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Développement Développement Scripting Microsoft Instances IE ; le retour des problèmes

Instances IE ; le retour des problèmes

4 réponses
Avatar
MCI \(ex do ré Mi chel la si do\) [MVP]
Bonsoir !

Il y a quelques temps, avait été posé le problème d'identifier les
instances d'Internet-explorer (avec les adresses/URL utilisées).

Plusieurs solutions avaient été proposées.

Mais, je tombe sur un problème pas piqué des hannetons...

C'est sous Vista ; et c'est un problème lié à l'UAC. Pour tester,
essayez la procédure suivante :
- démarrer une invite de commande en tant qu'Administrateur
(clic-droit + choix dans le menu).
- lancer Internet-Explorer normalement.
- là, on peut voir les instances, avec les différents scripts
proposés. C'est OK.
Ensuite :
- fermez IE
- lancez IE en tant qu'Administrateur (clic-droit + choix dans le
menu).
- maintenant, les scripts ne voient plus l'instance !!!!!!!!! ;-(((



Autre cas (dérivé). Lancez deux invites de commande :
- la première en tant qu'Administrateur (clic-droit + choix dans le
menu).
- la seconde normalement (la barre de titre permet de faire la
différence entre les deux).
- depuis chacune des consoles, lancez IE (normalement, par "\Program
Files\Internet Explorer\iexplore.exe").
- seule l'instance lancée depuis la console "normale" est visible.
L'autre "n'existe pas".


Toute l'après-midi, j'ai testé des dizaines de cas. Et, j'en arrive
toujours à la même conclusion : "lancement en tant qu'Administrateur" a
moins de pouvoirs que "lancement normal".

Le comportement est similaire, avec IE-7 et IE-8. Et, cela ne sert à
rien de (dé)-cocher des options dans IE (j'ai tout essayé).


Qu'en pensez-vous ?


@+
--
Michel Claveau



PS : avec l'UAC désactivé, il n'y a plus aucun problème.
Signaler un problème avec ce contenu

4 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Avatar
Michel__D
MCI (ex do ré Mi chel la si do) [MVP] a écrit :
Bonsoir !

Il y a quelques temps, avait été posé le problème d'identifier les
instances d'Internet-explorer (avec les adresses/URL utilisées).

Plusieurs solutions avaient été proposées.

Mais, je tombe sur un problème pas piqué des hannetons...

C'est sous Vista ; et c'est un problème lié à l'UAC. Pour tester,
essayez la procédure suivante :
- démarrer une invite de commande en tant qu'Administrateur (clic-droit
+ choix dans le menu).
- lancer Internet-Explorer normalement.
- là, on peut voir les instances, avec les différents scripts proposés.
C'est OK.
Ensuite :
- fermez IE
- lancez IE en tant qu'Administrateur (clic-droit + choix dans le menu).
- maintenant, les scripts ne voient plus l'instance !!!!!!!!! ;-(((



Autre cas (dérivé). Lancez deux invites de commande :
- la première en tant qu'Administrateur (clic-droit + choix dans le menu).
- la seconde normalement (la barre de titre permet de faire la
différence entre les deux).
- depuis chacune des consoles, lancez IE (normalement, par "Program
FilesInternet Exploreriexplore.exe").
- seule l'instance lancée depuis la console "normale" est visible.
L'autre "n'existe pas".


Toute l'après-midi, j'ai testé des dizaines de cas. Et, j'en arrive
toujours à la même conclusion : "lancement en tant qu'Administrateur" a
moins de pouvoirs que "lancement normal".

Le comportement est similaire, avec IE-7 et IE-8. Et, cela ne sert à
rien de (dé)-cocher des options dans IE (j'ai tout essayé).


Qu'en pensez-vous ?



Tes scripts sont lançés dans quel context ?

PS:Si c'est avec un context normal, le résultat semble correct.
Avatar
Gilles LAURENT [MVP]
"Michel__D" a écrit dans le
message de
news:
| MCI (ex do ré Mi chel la si do) [MVP] a écrit :
|| Bonsoir !
||
|| Il y a quelques temps, avait été posé le problème d'identifier les
|| instances d'Internet-explorer (avec les adresses/URL utilisées).
||
|| Plusieurs solutions avaient été proposées.
||
|| Mais, je tombe sur un problème pas piqué des hannetons...
||
|| C'est sous Vista ; et c'est un problème lié à l'UAC. Pour tester,
|| essayez la procédure suivante :
|| - démarrer une invite de commande en tant qu'Administrateur
|| (clic-droit + choix dans le menu).
|| - lancer Internet-Explorer normalement.
|| - là, on peut voir les instances, avec les différents scripts
|| proposés. C'est OK.
|| Ensuite :
|| - fermez IE
|| - lancez IE en tant qu'Administrateur (clic-droit + choix dans le
|| menu).
|| - maintenant, les scripts ne voient plus l'instance !!!!!!!!!
|| ;-(((
||
||
||
|| Autre cas (dérivé). Lancez deux invites de commande :
|| - la première en tant qu'Administrateur (clic-droit + choix dans le
|| menu).
|| - la seconde normalement (la barre de titre permet de faire la
|| différence entre les deux).
|| - depuis chacune des consoles, lancez IE (normalement, par "Program
|| FilesInternet Exploreriexplore.exe").
|| - seule l'instance lancée depuis la console "normale" est visible.
|| L'autre "n'existe pas".
||
||
|| Toute l'après-midi, j'ai testé des dizaines de cas. Et, j'en arrive
|| toujours à la même conclusion : "lancement en tant
|| qu'Administrateur" a moins de pouvoirs que "lancement normal".
||
|| Le comportement est similaire, avec IE-7 et IE-8. Et, cela ne sert à
|| rien de (dé)-cocher des options dans IE (j'ai tout essayé).
||
||
|| Qu'en pensez-vous ?
|
| Tes scripts sont lançés dans quel context ?
|
| PS:Si c'est avec un context normal, le résultat semble correct.

Situation: Trois instances Internet Explorer sont démarrées. Deux sous
l'autorité de l'utilisateur qui a ouvert la session de manière
interactive et une autre sous runas (XP) ou runas/UAC (Vista).

Ce problème n'est à mon sens du fait de l'UAC mais plutôt du composant
COM Shell.Application et plus particulièrement de l'interface
IShellWindows. Le composant COM Shell.Application est lié à la librairie
dynamique shell32.dll qui est chargée et instanciée sous l'autorité de
l'utilisateur qui a ouvert la session de manière interactive. Lorsqu'on
invoque l'interface IShellWindows (shdocvw.dll) via
Shell.Application.Windows avec un autre compte (runas et/ou UAC) alors
cela provoque :

Note: Les commandes ci-dessous s'exécutent sous runas (XP) ou runas/UAC
(Vista).

1- Un conflit d'autorité sous XP (runas) :
WSH D:Test> Set oShApp=CreateObject("Shell.Application")
WSH D:Test> Set colWindows=oshApp.Windows()
:: An error occured (429)
:: Un composant ActiveX ne peut pas créer un objet.

2- Uniquement la lecture des instances du Shell (Internet Explorer et
Explorer) de l'utilisateur qui a ouvert la session de manière
interactive sous Vista (runas et/ou UAC activé) :
WSH D:Test> Set oShApp=CreateObject("Shell.Application")
WSH D:Test> Set colWindows=oshApp.Windows()
WSH D:Test> WScript.Echo colWindows.Count
2 <= pourtant trois instances IE sont démarrées

Sous Vista, la désactivation de l'UAC résoud le problème car il n'y a
plus d'élévation de privilèges "à la demande". L'UAC peut être assimilé
à un runas du point de vue des droits et privilèges. Bien entendu, ce
problème persiste avec le runas sous Vista malgré la désactivation de
l'UAC. Pour résumer, ce fonctionnement peux sembler bizarre de prime
abord (j'avoue avoir été surpris) mais peut s'expliquer ensuite du fait
de l'implémentation de l'interface IShellWindows.

--
Gilles LAURENT
MVP Windows Server - Admin Frameworks
http://glsft.free.fr
Avatar
MCI \(ex do ré Mi chel la si do\) [MVP]
Bonsoir !

En fait, je comprends la logique d'implémentation du "truc". Lorsqu'une
appli est lancée "en tant qu'Administrateur", elle est isolée, dans une
"bulle d'exécution virtuelle" (l'expression est de Microsoft), et n'est
donc pas accessible par "autre chose".

Ce qui me gêne, c'est qu'un autre script, ou un logiciel, lancé lui
aussi "en tant qu'Administrateur" ne puisse pas y accéder non plus.
Cela signifie que l'isolation est plus profonde qu'il ne (me) semblait,
et est liée, non pas au compte/droits, mais à chaque instance
d'exécution par l'UAC.


Je pense aussi que ce n'est pas lié simplement à Shell.Application, mais
à tout l'ensemble des appels COM/Active-X, voire même à plus de choses.

Car, par exemple, si le problème est constaté avec Shell.Application, il
existe aussi avec des .HTA ou d'autres instances d'Internet-explorer,
lorsqu'elles veulent se connecter via Open("","nomfenetre").

Normalement, lorsque l'on ne précise pas le premier paramètre de Open,
cela n'ouvre pas une nouvelle instance (fenêtre) d'IE, mais établit une
connexion à une instance (fenêtre) déjà existante.
Et l'on rencontre strictement le même comportement. Or, cette
possibilité (Open("", ) fonctionne avec des logiciels qui n'utilisent
pas COM, tels que Firefox ou Opera ; ça ne passe donc pas par COM.

D'ailleurs, il serait intéressant de tester avec DynaWrap...


Une autre conséquence, c'est que le travail sous compte du (véritable)
Administrateur n'est pas équivalent à la désactivation de l'UAC. Mais,
bon, c'est moins important.


runas



Une solution, c'est effectivement d'utiliser runlike (mon équivalent de
runas). Comme il change le compte d'exécution, il annule le "en tant
qu'Administrateur".


J'ai encore quelques tests à faire. Mais, je pense que ce comportement
me gênera pour certains scripts.


Et, au passage, je m'aperçois que je ne sais rien du comportement des
objets-COM avec l'UAC...


@-salutations
--
Michel Claveau
Avatar
Gilles LAURENT [MVP]
"MCI (ex do ré Mi chel la si do) [MVP]"
a écrit dans le message de
news:
| Bonsoir !

Bonsoir,

[...]
| Et, au passage, je m'aperçois que je ne sais rien du comportement des
| objets-COM avec l'UAC...

ROTFL

The COM Elevation Moniker :
http://msdn.microsoft.com/en-us/library/ms679687(VS.85).aspx

--
Gilles LAURENT
MVP Windows Server - Admin Frameworks
http://glsft.free.fr