url IE powershell
Robby
Avec powershell, en gwmi.
Comment afficher l'URL d'une page de mon browser IE ?
est-ce avec win32_process ?
ou une autre classe ?
Merci d'avance,
Robby.
Méta-MCI (MVP)
Tu veux dire l'URL actuellement utilisé, ou faire afficher par IE l'URL
de ton choix ?
Dans le premier cas, que doit-on faire, s'il y a plusieurs instances
d'IE ouvertes ? Afficher toutes les URL ?
@+
Michel Claveau
![Gilles LAURENT [MVP]'s profile photo](http://lh3.googleusercontent.com/a-/ALV-UjW17DYnnl_aMcG7Oy7w_YcQeZrAKMhM69m39cfznGHswvQ3Eg=s40-c)
Gilles LAURENT [MVP]
> Bonjour,
Bonjour,
> Avec powershell, en gwmi.
> Comment afficher l'URL d'une page de mon browser IE ?
> est-ce avec win32_process ?
> ou une autre classe ?
En VBScript à l'aide de la console WSH Shell :
<http://glsft.free.fr/index.php?option=com_content&task=view&id=43&Itemid=28>
--
Gilles LAURENT
MVP Windows Server - Admin Frameworks
http://glsft.free.fr
Robby
"Méta-MCI (MVP)" <enleverl...@XmclaveauX.com> a écrit dans le message
de news: 47fdeb03$0$874$ba4a...@news.orange.fr...
MCI (ex do ré Mi chel la si do) [MVP]
En powershell, je n'ai pas regardé.
Mais, avec Python (ou avec PeJBshell ; ou avec Ponx), je fais ça :
import win32com.client
for instance in
win32com.client.Dispatch('{9BA05972-F6A8-11CF-A442-00A0C90A8F39}'):
print "URL:",instance.LocationURL
Ce qui me donne la liste de TOUTES les URL d'Internet-Explorer
(instances multiples, instances cachées (invisibles), onglets multiples,
fichiers/URL locaux, etc.)
@-salutations
Michel Claveau
Robby
Mais je suis pas trop dans le script, avec le powershell je debute alors les
Python...je ne connais pas.
Comment ca marche Python ? que faut-il , une interface qui lance le
programme ?
Est-ce que ton script fonctionne pour les PCs distants ?
Robby;
"MCI (ex do ré Mi chel la si do) [MVP]" <enleverl...@OmclaveauO.com> a
écrit dans le message de news: uwy1N5ym...@TK2MSFTNGP03.phx.gbl...
Jacques Barathon [MS]
> Re !
>
> En powershell, je n'ai pas regardé.
> Mais, avec Python (ou avec PeJBshell ; ou avec Ponx), je fais ça :
>
> import win32com.client
> for instance in
> win32com.client.Dispatch('{9BA05972-F6A8-11CF-A442-00A0C90A8F39}'):
> print "URL:",instance.LocationURL
Vu le nom de la propriété affichée, j'imagine que l'objet au nom imbittable
:-) utilisé par Michel est le même que j'instancie via Shell.Application
dans mon autre exemple en PowerShell (voir ma réponse sur l'autre fil
consacré à la même discussion).
Jacques
Méta-MCI (MVP)
Le truc "imbittable", c'est le CLSID d'Internet-Explorer (plus
exactement de "Internet.Application").
Une particularité de PyWin32 (l'extension Windows de Python), c'est que,
si on utilise le CLSID, ça se connecte sur les instances existantes,
alors que , si on utilise la chaîne "Internet.Application", ça lance une
nouvelle session.
Une différence avec ton script PowerShell, c'est que, là, on est
connecté. On peut donc piloter, faire ce que l'on veut, avec les
instances (les fermer, déplacer, les rendre visibles/invisibles, accéder
au contenu (DOM), le changer, etc.)
Par contre, pas d'accès distant, à moins de passer par DCOM, qui
nécessite d'être configuré (sur le poste distant).
@+
Michel Claveau
Méta-MCI (MVP)
Python est un langage à part entière. Il n'a rien à voir avec PowerShell
(même si on peut faire des passerelles).
Pour ce script, pas d'accès distant, à moins de passer par DCOM, qui
nécessite d'être configuré (sur le poste distant). Mais, à ce moment là,
autant installer Python sur le poste distant, et utiliser un package
d'objets distribués (Pyro, par exemple). Cela permet (entre autre) de
définir localement des scripts qui s'exécuteront à distance, avec retour
local.
Une autre possibilité serait de faire un serveur XMLRPC ; c'est assez
simple. Mais, il faut avoir installé Python des deux côtés.
@-salutations
Michel Claveau
Jacques Barathon [MS]
news:47ff3f4e$0$897$ba4a...@news.orange.fr...
> Salut !
>
> Le truc "imbittable", c'est le CLSID d'Internet-Explorer (plus exactement
> de "Internet.Application").
>
> Une particularité de PyWin32 (l'extension Windows de Python), c'est que,
> si on utilise le CLSID, ça se connecte sur les instances existantes, alors
> que , si on utilise la chaîne "Internet.Application", ça lance une
> nouvelle session.
>
> Une différence avec ton script PowerShell, c'est que, là, on est connecté.
> On peut donc piloter, faire ce que l'on veut, avec les instances (les
> fermer, déplacer, les rendre visibles/invisibles, accéder au contenu
> (DOM), le changer, etc.)
Bon à savoir. Je serais curieux de voir quelle API est utilisée dans la
cuisine de PyWin32, parce que la méthode .Net
[System.Runtime.InteropServices.Marshal]::GetActiveObject() qui marche très
bien avec d'autres objets (notamment les applis Office) ne marche pas avec
Internet Explorer... Dommage.
Jacques
MCI (ex do ré Mi chel la si do) [MVP]
> GetActiveObject() ... ne marche pas avec Internet Explorer
En fait, j'avais déjà remarque des limitations (volontaires) dans le
pilotage de certains objets COM, dont Internet-Explorer.
Une autre limitation, c'est que PowerShell ne gère pas le "late-binding"
(liaison tardive des méthodes / propriétés d'un objet COM). En fait PS
ne sait travailler qu'avec les objets COM ayant une TLB (Type Library).
Heureusement, j'ai trouvé un moyen simple (et tout bête) de contourner
cette limitation. C'est de passer par un pont. Perso, j'utilise
MSScriptControl.ScriptControl et JScript (on pourrait utiliser
VBscript).
Du coup, je contourne la presque totalité des limitations.
Toutefois, c'est un peu délicat à donner, comme réponse dans un
newsgroup...
@-salutations
Michel Claveau
Gilles LAURENT [MVP]
> Bon à savoir. Je serais curieux de voir quelle API est utilisée dans la
> cuisine de PyWin32, parce que la méthode .Net
> [System.Runtime.InteropServices.Marshal]::GetActiveObject() qui marche très
> bien avec d'autres objets (notamment les applis Office) ne marche pas avec
> Internet Explorer... Dommage.
Le server COM Internet Explorer n'enregistre pas ses instances d'exécution
dans la ROT (Running Object Table). C'est pourquoi les méthodes GetObject
(VBScript) ou GetActiveObject (.Net) échouent. Une solution de contournement
consiste à parcourir la collection Windows de l'objet Shell.Application. La
function VBScript ci-dessous retourne la première instance Internet Explorer
en cours d'exécution.
Function GetActiveIEObject ()
Set GetActiveIEObject=Nothing
Set oApp=CreateObject("Shell.Application")
For Each oWindow In oApp.Windows()
If InStr(oWindow.FullName,"Internet") Then
Set GetActiveIEObject=oWindow
Exit For
End If
Next
End Function
' on se raccroche à une instance Internet Explorer en cours d'exécution
Set oIE=GetActiveIEObject()
oIE.Visible=False
Jacques Barathon [MS]
> Re !
>
>> GetActiveObject() ... ne marche pas avec Internet Explorer
>
> En fait, j'avais déjà remarque des limitations (volontaires) dans le
> pilotage de certains objets COM, dont Internet-Explorer.
Tu es sûr que la limitation est volontaire? Tu as des infos précises là
dessus? Je m'apprétais à remonter le bug, mais si c'est pour me faire
répondre que c'est "by design", je vais éviter... :-)
Jacques
Jacques Barathon [MS]
news:6B13B18F-1811-4D05...@microsoft.com...
> Le server COM Internet Explorer n'enregistre pas ses instances d'exécution
> dans la ROT (Running Object Table). C'est pourquoi les méthodes GetObject
> (VBScript) ou GetActiveObject (.Net) échouent.
Ah oui, c'est vrai. Je me rappelle avoir eu cette même discussion et avoir
déjà reçu cette même réponse de ta part... Ah là là, je vieillis...
Mais dans ce cas, je suis quand même intrigué par la possibilité qu'a
PyWin32 de récupérer les instances ouvertes via le CLSID. Utiliserait-il une
API qui interroge une autre table? Si quelqu'un sait, ça m'intéresse.
> Une solution de contournement
> consiste à parcourir la collection Windows de l'objet Shell.Application.
> La
> function VBScript ci-dessous retourne la première instance Internet
> Explorer
> en cours d'exécution.
Oui, c'est la technique que j'ai indiquée dans mon autre réponse, en
proposant bien évidemment la version PowerShell... :-)
Jacques
Méta-MCI (MVP)
> Tu es sûr que la limitation est volontaire?
Une fois que l'on est "connecté" à un IE, j'ai eu plein de méthodes qui
ne fonctionnent pas sous PS, alors que ça marche avec Jscript, Python,
ou VBscript.
En cherchant pourquoi, je suis tombé, un jour, sur une page expliquant
que c'était pour des raisons de sécurité (ce que je comprends, vu ce que
j'arrive à faire avec). Malheureusement, je n'ai pas gardé le lien.
@+
Michel Claveau
Gilles LAURENT [MVP]
message de
news:uepuzX%23mIH...@TK2MSFTNGP06.phx.gbl
| "Gilles LAURENT [MVP]" <gl...@free.fr> wrote in message
| news:6B13B18F-1811-4D05...@microsoft.com...
|
|| Le server COM Internet Explorer n'enregistre pas ses instances
|| d'exécution dans la ROT (Running Object Table). C'est pourquoi les
|| méthodes GetObject (VBScript) ou GetActiveObject (.Net) échouent.
|
| Ah oui, c'est vrai. Je me rappelle avoir eu cette même discussion et
| avoir déjà reçu cette même réponse de ta part... Ah là là, je
| vieillis...
Hé hé :-) Comme tout le monde !
| Mais dans ce cas, je suis quand même intrigué par la possibilité qu'a
| PyWin32 de récupérer les instances ouvertes via le CLSID.
| Utiliserait-il une API qui interroge une autre table? Si quelqu'un
| sait, ça m'intéresse.
Le CLSID utilisé par Michel n'est autre que celui de l'objet
ShellWindows :
http://msdn2.microsoft.com/en-us/library/bb773974(VS.85).aspx
C'est en fait l'interface de l'objet COM (Shell.Application).Windows
MCI (ex do ré Mi chel la si do) [MVP]
> Le CLSID utilisé par Michel n'est autre que celui de l'objet
> ShellWindows
C'est exact. Sous Windows, jusqu'à IE-6 compris, Internet-Explorer et
l'explorateur, c'était le même objet. On pouvait d'ailleurs taper une
URL dans la barre d'adresse de l'explorateur, et voir le site à la place
des fichiers d'une directory. Ou saisir "C:\" dans Internet-Explorer, et
voir la liste des fichiers.
Depuis IE-7, les deux objets sont séparés, mais restent très liés. Par
exemple, taper "C:\" dans Internet-Explorer ouvre une nouvelle fenêtre
dans l'explorateur. Idem avec une adresse FTP: (c'est l'explorateur
qui s'occupe du FTP). Inversement, taper une URL dans l'explorateur
ouvre une nouvelle fenêtre dans Internet-Explorer.
Mais, le CLSID unique a été maintenu. Mon script Python fournit donc, à
la fois les instances d'Internet-Explorer et celles de l'explorateur.
Les développeurs ont dû s'arracher pas mal de cheveux, pour maintenir
cette cohérence du CLSID, tout en séparant les deux éléments...
@-salutations
Michel Claveau
Méta-MCI (MVP)
Tout ça (message précédent) m'a amené à réfléchir à la question
(essentielle) : qu'est-ce qu'un programme ?
Et la réponse est tout, sauf simple.
Au départ, c'est un ensemble d'instructions. Que l'on peut enregistrer
dans un fichier. Mais, cela peut être, aussi, plusieurs ensembles
d'instructions, qui peuvent être enregistrés dans plusieurs fichiers.
De plus, qu'est-ce qu'une instruction ? C'est un ordre, envoyé à ... à
un équipement (OS, ou matériel, par exemple), ou à un autre programme,
ou à une autre couche de programmation. Par exemple, l'instruction
VBscript wscript.echo va envoyer un ordre à wscript, qui est un autre
programme, le moteur de script, composant additionnel (facultatif mais
utile) de Windows.
Si on en revient au fil, on se rend compte de la difficulté à identifier
un programme, tel que Internet-Explorer.
En effet, qu'est "Internet-Explorer" ? Certes, c'est le nom d'un
programme. Mais, comment l'identifier ? Le premier réflexe est
d'utiliser le processus qui permet de le lancer (iexplore.exe). Mais, il
y en a d'autres ; par exemple mshta.exe. Et, rien n'empêche de le
renommer (en réalité, c'est difficile).
Le cas mshta.exe est intéressant. Si on lance: %WINDIR%\mshta.exe
http://google.fr
On va bien naviguer sur Google, de manière pleinement fonctionnelle. Et
pourtant, pas de trace du processus iexplore.exe, dans le gestionnaire
de taches. Il n'est d'ailleurs pas identifié par les scripts pistant
shell.application.
Or, nul doute que les composants d'Internet-Explorer, nécessaires à la
navigation, sont bien en cours d'exécution ; y compris un interface
actif.
Alors, Internet-Explorer ou non ? Cette question devrait titiller
beaucoup d'administrateurs.
Mais, je n'ai pas la réponse, car, finalement, après ces réflexions, hé
bien... je ne sais plus ce qu'est un programme ;-)
@-salutations
--
Michel Claveau
MCI (ex do ré Mi chel la si do) [MVP]
C'est %WINDIR%\system32\mshta.exe
Désolé.
Méta-MCI (MVP)
En farfouillant un peu, je n'arrivais pas à bricoler Shell.Application
depuis JScript.
Après m'être arraché quelques cheveux, je suis tombé sur cette page :
http://msdn2.microsoft.com/en-us/library/bb773972(VS.85).aspx
Où il est clairement marqué, dans _NewEnum Method , en fin du 1er
paragraphe "example", ceci :
"...This method cannot be used with Microsoft JScript."
Dur ! Dur !
Pourquoi cet ostracisme envers JScript ? Vais-je être obligé de me
mettre au VBS ?
Très dur ! Très dur !
Sinon, connaissez-vous beaucoup de choses interdites à JScript, et
autorisées à VBScript ?
Ou, mieux, une doc ou un lien recensant ces problèmes ?
@-salutations
--
Michel Claveau
MCI (ex do ré Mi chel la si do) [MVP]
à cause des parenthèses, il faut copier le lien, et le coller dans la
barre d'adresse de IE, sinon, il ne trouve pas...
@+
MCI
Jacques Barathon [MS]
> Le CLSID utilisé par Michel n'est autre que celui de l'objet
> ShellWindows :
> http://msdn2.microsoft.com/en-us/library/bb773974(VS.85).aspx
>
> C'est en fait l'interface de l'objet COM (Shell.Application).Windows
Oui, ça je l'avais bien compris. En fait, la solution proposée par Michel
donne les mêmes fonctionnalités que l'appel à Shell.Application sous VBS ou
PowerShell. Mais pendant un instant j'ai pensé que sa solution permettait
d'accéder à l'objet Internet.Application, ce qui n'est pas le cas si j'ai
bien tout compris (j'en doute, parfois...).
Jacques
Gilles LAURENT [MVP]
Oui, nos solutions PowerShell, VBScript, Python permettent d'accèder de
manière indirecte à l'objet InternetExplorer.Application. Ci-dessous un
transcript WSH Shell dans le but de tracer la démarche utilisée et de
comprendre le fonctionnement (efin j'espère !) :
*******************************
WSH Transcript Start
Start time : 2008-04-12 21:10:34
Username : DEVXP\Gilles
Machine : DEVXP (Microsoft Windows NT 5.1.2600.2)
*******************************
Transcript started, output file is D:\Test\IExplore.txt
WSH D:\Test> ' instanciation de l'object InternetExplorer.Application
WSH D:\Test> Set oIE=co("InternetExplorer.Application")
WSH D:\Test> ' lecture du type de l'objet
WSH D:\Test> echo TypeName(oIE)
IWebBrowser2
WSH D:\Test> ' instanciation de l'objet Shell.Application
WSH D:\Test> Set oApp=co("Shell.Application")
WSH D:\Test> ' lecture du type de l'objet
WSH D:\Test> echo TypeName(oApp)
IShellDispatch4
WSH D:\Test> ' bon ok, c'est pas très verbeux tout cela !
WSH D:\Test> ' l'important est que l'interface C++ IDispach (VTable)
WSH D:\Test> ' soit implémentée
WSH D:\Test> ' tentative d'instanciation de l'objet ShellWindows
WSH D:\Test> Set oShellWindows=oApp.Windows
WSH D:\Test> ' lecture du type de l'objet
WSH D:\Test> echo TypeName(oShellWindows)
IShellWindows
WSH D:\Test> ' c'est tout bon, on possède l'interface qui va bien !
WSH D:\Test> ' parcours de l'objet via ICollection (VTable)
WSH D:\Test> % oIEInst In oShellWindows {
>> echo TypeName(oIEInst), oIEInst.Name
>> }
>>
IWebBrowser2 Microsoft Internet Explorer
IWebBrowser2 Microsoft Internet Explorer
WSH D:\Test>
WSH D:\Test> ' nous retrouvons bien ici les instances de l'objet
WSH D:\Test> ' COM InternetExplorer.Application par référence
WSH D:\Test> echo TypeName(oIE), oIE.Name
IWebBrowser2 Microsoft Internet Explorer
WSH D:\Test>
WSH D:\Test> ' Enjoy !
Transcript stopped.
Méta-MCI (MVP)
Vi vi ; on est tous d'accord.
Mais, en plus de Internet-Explorer, cela détecte aussi les instances de
l'explorateur, que l'on peut éliminer en utilisant le mot "Internet"
pour sélectionner (comme l'avait fait Jacques, et toi).
Par contre, on ne voit pas les connexions .HTA (liées à mshta.exe). Du
moins, pas dans mes tests.
Sinon, j'ai cherché s'il était possible de voir les connexions à
Internet, avec NETSTAT. Et, très vite, je suis tombé sur les proxies
(locaux) des antivirus, ce qui rend trop difficile l'exploitation des
sorties.
@+
Michel Claveau
Jean
Sans vouloir me vanter, pas chez moi :P
Amicalement,
--
Jean - JMST
Belgium
Jean
>
> Vi vi ; on est tous d'accord.
> Mais, en plus de Internet-Explorer, cela détecte aussi les instances de
> l'explorateur,
Ce qui était le cas naguère avec l'utilisation directe de
shell.application.windows (probablement avant que l'interface de
l'explorateur ne soit dissociée de celle d'internet explorer).
> que l'on peut éliminer en utilisant le mot "Internet" pour sélectionner
> (comme l'avait fait Jacques, et toi).
> Par contre, on ne voit pas les connexions .HTA (liées à mshta.exe).
Les HTA n'ont rien à voir avec Shell.Application (ou
InternetExplorer.Application) ... c'est le WebBrowser qu'il faudrait
cibler, clsid 8856F961-340A-11D0-A96B-00C04FD705A2 voire html document,
clsid 25336920-03F9-11CF-8FD0-00AA00686F13
> Du moins, pas dans mes tests.
>
> Sinon, j'ai cherché s'il était possible de voir les connexions à Internet,
> avec NETSTAT. Et, très vite, je suis tombé sur les proxies (locaux) des
> antivirus, ce qui rend trop difficile l'exploitation des sorties.
>
> @+
>
> Michel Claveau
Amicalement,
Jean
> autorisées à VBScript ?
Je parlerais plutôt de différences entre JScript et VbScript.
Je n'ai pas listé les différences mais deux choses importantes pour la
manipulation des com :
les paramètres byref et les tableaux vb safe array ne sont pas gérés
par le type variant de jscript.
Donc si un com impose un paramètre byref ou retourne un tableau safe
array jscript perd la vue.
Je crois que l'on trouve des solutions de contournement en broutant un
peu mais autant utiliser le langage qui sait faire la tâche, donc pour
ce qui précède, VbScript.
MCI (ex do ré Mi chel la si do) [MVP]
> Sans vouloir me vanter, pas chez moi :P
Je pense que c'est lié à Windows-Mail...
@+
--
MCI
MCI (ex do ré Mi chel la si do) [MVP]
En fait, lorsque j'en ai besoin, je m'en sors avec un .WSF, avec juste
une fonction en VBScript, appelée par le script en JScript.
Sinon, lorsque tu parles de "variant" pour JScript, je suppose que c'est
un léger abus de langage, JScript utilisant , à la place les variables
comme étant des identifiants d'objets, et le changement de type d'objet
étant lié au changement de prototype ; et non à la possibilité d'avoir
différents types dans une même zone mémoire.
@+
Michel Claveau
MCI (ex do ré Mi chel la si do) [MVP]
> Ce qui était le cas naguère avec l'utilisation directe de
> shell.application.windows (probablement avant que l'interface de
> l'explorateur ne soit dissociée de celle d'internet explorer).
C'est ce que j'ai expliqué dans mon message de 22h.12 ; on est donc
d'accord.
> Les HTA n'ont rien à voir avec Shell.Application (ou
> InternetExplorer.Application) ... c'est le WebBrowser qu'il faudrait
> cibler, clsid 8856F961-340A-11D0-A96B-00C04FD705A2 voire html
> document, clsid 25336920-03F9-11CF-8FD0-00AA00686F13
Malheureusement, ces objets n'exposent pas de "Dispatch" ; ils ne
peuvent dont pas être joint depuis Python, et sans doute pas depuis
VBScript.CreateObject
@+
Michel Claveau
Jean
>
> En fait, lorsque j'en ai besoin, je m'en sors avec un .WSF, avec juste une
> fonction en VBScript, appelée par le script en JScript.
>
Oui un wsf ou un hta est ce à quoi je pensais ...
> Sinon, lorsque tu parles de "variant" pour JScript, je suppose que c'est un
> léger abus de langage, JScript utilisant , à la place les variables comme
> étant des identifiants d'objets, et le changement de type d'objet étant lié
> au changement de prototype ; et non à la possibilité d'avoir différents
> types dans une même zone mémoire.
>
> @+
>
> Michel Claveau
Amicalement,
Jean
Pas au mien ... ni à mon MesNews brolifié ... la pression atmosphérique
peut être ? ... :-)
Jean
D'où l'emploi du conditionnel ... par contre il y a sans doute moyen en
py de lister les applications qui ont une fenêtre fille de classe
"Internet Explorer_Server" ... (sinon il suffit de développer un com ou
un exe, forcément :-)).
MCI (ex do ré Mi chel la si do) [MVP]
Il y a un autre moyen (suggéré, dans un passé lointain, par un certain
Jean...)
C'est d'utiliser un .HTA, avec la fonction open("", pour se connecter
à des pages web ouvertes.
Mais, bon, on s'éloigne de la demande initiale, et ça ne fonctionnera
pas sur un ordinateur distant.
Bonne nuit.
Michel Claveau