Voici ma situation:
J'ai un server exe ActiveX qui tourne sur (disons) PC1.
Mon client tourne sur un autre PC (disons PC2)
Quand j'appelle une fonction de mon exe ActiveX, le=20
programme soit:
1. contr=F4ler qu'un fichier donn=E9 existe
2. charger une application tierce (disons word), ouvrir=20
le fichier et l'imprimer.
Le chemin d'acc=E8s au fichier =E0 ouvrir est transmis par=20
l'application client. Le chemin est au format UNC (mais =E0=20
priori m=EAme avec un chemin mapp=E9, le probl=E8me est le=20
m=EAme).
Pour v=E9rifier si le fichier existe, j'utilise=20
FileSystemObject. Or FSO me dit que le fichier n'existe=20
pas, alors qu'il existe...
Maintenant si je transmets le chemin =E0 un fichier qui se=20
trouve sur PC1 (C:\Temp\blabla.doc, p.ex.) FSO me dit que=20
le fichier est bien l=E0. Par contre quand je veux d=E9marrer=20
Word (CreateObject("Word.Application")), =E7a ne marche pas=20
non plus...
Si je fais exactement la m=EAme chose avec mon client sur=20
le m=EAme PC que mon serveur, alors tout marche bien!
Il faut que le compte sous lequel tourne le process serveur sur PC1 ait les permissions d'accès sur les fichiers visés sur PC2. Comme vous avez spécifié "launching user", essayez voir avec Interactive User. Sinon, avec un autre compte dont vous êtes sûre qu'il a les permissions requises.
Il me semble que c'est par là que ça se passe. Lisez SVP dans le MSDN, l'article intitulé "COM Security Frequently Asked Questions", sections "Q4 I get E_ACCESSDENIED from CoCreateInstanceEx. Why?" et surtout "Q10 What are the limitations of RunAs the Launching User?".
Vous tournez tout ça sous quel OS au fait?
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
Patrick Philippot wrote:
Il faut que le compte sous lequel tourne le process serveur sur PC1
ait les permissions d'accès sur les fichiers visés sur PC2. Comme
vous avez spécifié "launching user", essayez voir avec Interactive
User. Sinon, avec un autre compte dont vous êtes sûre qu'il a les
permissions requises.
Il me semble que c'est par là que ça se passe. Lisez SVP dans le MSDN,
l'article intitulé "COM Security Frequently Asked Questions", sections
"Q4 I get E_ACCESSDENIED from CoCreateInstanceEx. Why?" et surtout "Q10
What are the limitations of RunAs the Launching User?".
Vous tournez tout ça sous quel OS au fait?
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
Il faut que le compte sous lequel tourne le process serveur sur PC1 ait les permissions d'accès sur les fichiers visés sur PC2. Comme vous avez spécifié "launching user", essayez voir avec Interactive User. Sinon, avec un autre compte dont vous êtes sûre qu'il a les permissions requises.
Il me semble que c'est par là que ça se passe. Lisez SVP dans le MSDN, l'article intitulé "COM Security Frequently Asked Questions", sections "Q4 I get E_ACCESSDENIED from CoCreateInstanceEx. Why?" et surtout "Q10 What are the limitations of RunAs the Launching User?".
Vous tournez tout ça sous quel OS au fait?
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
mc
>Mais quand vous dîtes que c'est pareil avec un chemin
mappé, cela
veut-il dire que sur toutes les machines le mapping des
drives est
exactement identique? Et même, comment-cela est-il
possible si PC2
envoit à PC1 le nom d'un fichier local? C: ne peut pas
être mappé sur le
serveur.
Cela ne peut pas fonctionner, évidemment, à moins de
savoir quel drive
mappé utiliser pour que le serveur ait un chemin d'accès
valide ou de ne
passer que le nom de fichiers non locaux.
En fait mes affirmations viennent des tests que j'ai effectués. Afin de trouver ce qui clochait, j'ai "développé" une application client qui se contente de passer le chemin & nom du fichier à traiter et d'appeler la méthode de traitement. Dans mes tests j'ai donc essayé plusieurs fichiers que je savais pouvoir trouver depuis le PC "serveur". Cette application client test, quant à elle, ne contrôle pas l'existance de ces fichiers.
Je suis en train de réaliser qu'il y a un point que je dois peut-être éclaircir, je ne sais pas du tout si ça peut être important... Mon PC "serveur" n'est pas un serveur de domaine ou quoi que ce soit du genre, c'est un autre PC client de ce domaine mais qui me sert de serveur pour cette application client. Ce PC n'est pas équipé d'une version Server de Windows. Ces 2 PC ont Windows XP SP1.
>Mais quand vous dîtes que c'est pareil avec un chemin
mappé, cela
veut-il dire que sur toutes les machines le mapping des
drives est
exactement identique? Et même, comment-cela est-il
possible si PC2
envoit à PC1 le nom d'un fichier local? C: ne peut pas
être mappé sur le
serveur.
Cela ne peut pas fonctionner, évidemment, à moins de
savoir quel drive
mappé utiliser pour que le serveur ait un chemin d'accès
valide ou de ne
passer que le nom de fichiers non locaux.
En fait mes affirmations viennent des tests que j'ai
effectués. Afin de trouver ce qui clochait,
j'ai "développé" une application client qui se contente
de passer le chemin & nom du fichier à traiter et
d'appeler la méthode de traitement. Dans mes tests j'ai
donc essayé plusieurs fichiers que je savais pouvoir
trouver depuis le PC "serveur". Cette application client
test, quant à elle, ne contrôle pas l'existance de ces
fichiers.
Je suis en train de réaliser qu'il y a un point que je
dois peut-être éclaircir, je ne sais pas du tout si ça
peut être important... Mon PC "serveur" n'est pas un
serveur de domaine ou quoi que ce soit du genre, c'est un
autre PC client de ce domaine mais qui me sert de serveur
pour cette application client. Ce PC n'est pas équipé
d'une version Server de Windows.
Ces 2 PC ont Windows XP SP1.
>Mais quand vous dîtes que c'est pareil avec un chemin
mappé, cela
veut-il dire que sur toutes les machines le mapping des
drives est
exactement identique? Et même, comment-cela est-il
possible si PC2
envoit à PC1 le nom d'un fichier local? C: ne peut pas
être mappé sur le
serveur.
Cela ne peut pas fonctionner, évidemment, à moins de
savoir quel drive
mappé utiliser pour que le serveur ait un chemin d'accès
valide ou de ne
passer que le nom de fichiers non locaux.
En fait mes affirmations viennent des tests que j'ai effectués. Afin de trouver ce qui clochait, j'ai "développé" une application client qui se contente de passer le chemin & nom du fichier à traiter et d'appeler la méthode de traitement. Dans mes tests j'ai donc essayé plusieurs fichiers que je savais pouvoir trouver depuis le PC "serveur". Cette application client test, quant à elle, ne contrôle pas l'existance de ces fichiers.
Je suis en train de réaliser qu'il y a un point que je dois peut-être éclaircir, je ne sais pas du tout si ça peut être important... Mon PC "serveur" n'est pas un serveur de domaine ou quoi que ce soit du genre, c'est un autre PC client de ce domaine mais qui me sert de serveur pour cette application client. Ce PC n'est pas équipé d'une version Server de Windows. Ces 2 PC ont Windows XP SP1.
Patrick Philippot
mc wrote:
Je suis en train de réaliser qu'il y a un point que je dois peut-être éclaircir, je ne sais pas du tout si ça peut être important... Mon PC "serveur" n'est pas un serveur de domaine ou quoi que ce soit du genre, c'est un autre PC client de ce domaine mais qui me sert de serveur pour cette application client. Ce PC n'est pas équipé d'une version Server de Windows. Ces 2 PC ont Windows XP SP1.
Ce n'est pas important pour faire tourner un "serveur" COM. C'est peut-être important pour les problèmes de permissions. Vous devriez creuser le problème du compte sous lequel tourne le composant serveur, ça me paraît être le plus important.
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
mc wrote:
Je suis en train de réaliser qu'il y a un point que je
dois peut-être éclaircir, je ne sais pas du tout si ça
peut être important... Mon PC "serveur" n'est pas un
serveur de domaine ou quoi que ce soit du genre, c'est un
autre PC client de ce domaine mais qui me sert de serveur
pour cette application client. Ce PC n'est pas équipé
d'une version Server de Windows.
Ces 2 PC ont Windows XP SP1.
Ce n'est pas important pour faire tourner un "serveur" COM. C'est
peut-être important pour les problèmes de permissions. Vous devriez
creuser le problème du compte sous lequel tourne le composant serveur,
ça me paraît être le plus important.
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
Je suis en train de réaliser qu'il y a un point que je dois peut-être éclaircir, je ne sais pas du tout si ça peut être important... Mon PC "serveur" n'est pas un serveur de domaine ou quoi que ce soit du genre, c'est un autre PC client de ce domaine mais qui me sert de serveur pour cette application client. Ce PC n'est pas équipé d'une version Server de Windows. Ces 2 PC ont Windows XP SP1.
Ce n'est pas important pour faire tourner un "serveur" COM. C'est peut-être important pour les problèmes de permissions. Vous devriez creuser le problème du compte sous lequel tourne le composant serveur, ça me paraît être le plus important.
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
>Ce n'est pas important pour faire tourner un "serveur"
COM. C'est
peut-être important pour les problèmes de permissions.
Vous devriez
creuser le problème du compte sous lequel tourne le
composant serveur,
ça me paraît être le plus important.
Oui, grâce à votre aide, j'ai décidé de concentrer les recherches sur les droits d'accès. J'ai tout simplement essayé en me loggant sur le "serveur" en tant qu'admin réseau et en définissant que l'utilisateur qui crée le process de mon applic est l'utilisateur interactif (soit l'admin), et ça marche! Il ne me reste plus qu'à trouver comment définir les droits sur ce poste pour que l'utilisateur soit l'appelant.
>Ce n'est pas important pour faire tourner un "serveur"
COM. C'est
peut-être important pour les problèmes de permissions.
Vous devriez
creuser le problème du compte sous lequel tourne le
composant serveur,
ça me paraît être le plus important.
Oui, grâce à votre aide, j'ai décidé de concentrer les
recherches sur les droits d'accès. J'ai tout simplement
essayé en me loggant sur le "serveur" en tant qu'admin
réseau et en définissant que l'utilisateur qui crée le
process de mon applic est l'utilisateur interactif (soit
l'admin), et ça marche!
Il ne me reste plus qu'à trouver comment définir les
droits sur ce poste pour que l'utilisateur soit
l'appelant.
>Ce n'est pas important pour faire tourner un "serveur"
COM. C'est
peut-être important pour les problèmes de permissions.
Vous devriez
creuser le problème du compte sous lequel tourne le
composant serveur,
ça me paraît être le plus important.
Oui, grâce à votre aide, j'ai décidé de concentrer les recherches sur les droits d'accès. J'ai tout simplement essayé en me loggant sur le "serveur" en tant qu'admin réseau et en définissant que l'utilisateur qui crée le process de mon applic est l'utilisateur interactif (soit l'admin), et ça marche! Il ne me reste plus qu'à trouver comment définir les droits sur ce poste pour que l'utilisateur soit l'appelant.
ng
Parce que c'est fait pour le scripting et que c'est lent, de plus en early binding on peut avoir de nombreux problèmes de compatibilités : http://faq.vb.free.fr/index.php?question6
Sinon pour tester l'existance d'un fichier utilisez plutot une fonction comme celle ci :
Private Function FileExists(ByRef strPath As String) As Boolean On Error Resume Next FileExists = ((GetAttr(strPath) And vbDirectory) = 0) End Function
On gardera Dir$() pour lister les fichiers (et si on doit faire plusieurs listes en mm temps ou si on utilise la recursivité on utilisera les APIs FindFirstFile(), FindNextFile() et FindClose()).
-- Nicolas G. FAQ VB : http://faq.vb.free.fr API Guide : http://www.allapi.net Google Groups : http://groups.google.fr/ MZ-Tools : http://www.mztools.com/ http://apisvb.europe.webmatrixhosting.net/
mc a écrit :
Il est fortement déconseillé d'utiliser FSO en VBde toute facon, utilisez plutot les fonctions implantées ou les APIs.
La fonction Dir() ne trouve pas mon fichier non plus.
Pour ma culture: pourquoi est-il déconseillé d'utiliser FSO? Je l'utilise déjà depuis pas mal de temps et n'ai jamais rencontré de problème (à part celui de ce thread, mais à priori le problème n'a rien à voir avec FSO...)
Parce que c'est fait pour le scripting et que c'est lent, de plus en early
binding on peut avoir de nombreux problèmes de compatibilités :
http://faq.vb.free.fr/index.php?question6
Sinon pour tester l'existance d'un fichier utilisez plutot une fonction
comme celle ci :
Private Function FileExists(ByRef strPath As String) As Boolean
On Error Resume Next
FileExists = ((GetAttr(strPath) And vbDirectory) = 0)
End Function
On gardera Dir$() pour lister les fichiers (et si on doit faire plusieurs
listes en mm temps ou si on utilise la recursivité on utilisera les APIs
FindFirstFile(), FindNextFile() et FindClose()).
--
Nicolas G.
FAQ VB : http://faq.vb.free.fr
API Guide : http://www.allapi.net
Google Groups : http://groups.google.fr/
MZ-Tools : http://www.mztools.com/
http://apisvb.europe.webmatrixhosting.net/
mc <anonymous@discussions.microsoft.com> a écrit :
Il est fortement déconseillé d'utiliser FSO en VBde toute facon,
utilisez plutot les fonctions implantées ou les APIs.
La fonction Dir() ne trouve pas mon fichier non plus.
Pour ma culture: pourquoi est-il déconseillé d'utiliser
FSO? Je l'utilise déjà depuis pas mal de temps et n'ai
jamais rencontré de problème (à part celui de ce thread,
mais à priori le problème n'a rien à voir avec FSO...)
Parce que c'est fait pour le scripting et que c'est lent, de plus en early binding on peut avoir de nombreux problèmes de compatibilités : http://faq.vb.free.fr/index.php?question6
Sinon pour tester l'existance d'un fichier utilisez plutot une fonction comme celle ci :
Private Function FileExists(ByRef strPath As String) As Boolean On Error Resume Next FileExists = ((GetAttr(strPath) And vbDirectory) = 0) End Function
On gardera Dir$() pour lister les fichiers (et si on doit faire plusieurs listes en mm temps ou si on utilise la recursivité on utilisera les APIs FindFirstFile(), FindNextFile() et FindClose()).
-- Nicolas G. FAQ VB : http://faq.vb.free.fr API Guide : http://www.allapi.net Google Groups : http://groups.google.fr/ MZ-Tools : http://www.mztools.com/ http://apisvb.europe.webmatrixhosting.net/
mc a écrit :
Il est fortement déconseillé d'utiliser FSO en VBde toute facon, utilisez plutot les fonctions implantées ou les APIs.
La fonction Dir() ne trouve pas mon fichier non plus.
Pour ma culture: pourquoi est-il déconseillé d'utiliser FSO? Je l'utilise déjà depuis pas mal de temps et n'ai jamais rencontré de problème (à part celui de ce thread, mais à priori le problème n'a rien à voir avec FSO...)
Patrick Philippot
wrote:
Il ne me reste plus qu'à trouver comment définir les droits sur ce poste pour que l'utilisateur soit l'appelant.
Pour éviter de vous compliquer la vie, dans DCOMCNFG, vous pouvez utiliser "This user" au lieu de "Interactive User". Dans "This user", vous spécifiez un compte que vous aurez créé rien que pour cet usage et qui aura les droits appropriés et rien que ceux-là. De cette manière, sauf contre-indication applicative, quel que soit l'utilisateur appelant, vous utiliserez le même compte pour exécuter la requête.
Cette approche n'est bien sûr pas appropriée si le comportement du serveur varie en fonction des droits de l'utilisateur appelant ou si le service ne doit pas être accessible à certains utilisateurs.
Maintenant que le problème est identifié, je vous conselle de lire ce document
qui va vous aider à définir la meilleure stratégie en fonction de vos besoins applicatifs, de la configuration de votre domaine, etc. Je ne peux pas préconiser un choix plus qu'un autre sans connaître votre environnement et vos besoins. Mais je pense que vous avez maintenant tous les éléments (ou presque :-) ) en main.
Bon courage.
Une dernière remarque: En DCOM, le plus pénible, vous l'avez remarqué, ce sont les réglages sécurité. C'est pour cela qu'en matière de services distribués, la tendance est désormais à l'utilisation de Web Services via le protocole SOAP, même sur un Intranet. Avec la technologie .Net, c'est très facile à mettre en oeuvre, côté client comme côté serveur. Si vous êtes coincée avec VB6, il y a un toolkit qui permet d'interagir avec un Web Service: le SOAP tookit (http://www.microsoft.com/downloads/details.aspx?FamilyIDÉ43c0dd-ceec-4088-9753-86f052ec8450&displaylang=en), un ensemble de composants COM clients qui vous facilite la tâche de programmation du client d'un Web Service.
Si vos essais actuels sont du simple maquettage et si rien n'est fixé en matière de design, je vous conseille fortement l'approche Web Service plutôt que DCOM. Ceci étant, sur un Intranet, DCOM fonctionne bien une fois que tout est réglé correctement. Mais si le service doit être un jour distribué à l'extérieur (via Internet), ce n'est pas la bonne approche.
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
anonymous@discussions.microsoft.com wrote:
Il ne me reste plus qu'à trouver comment définir les
droits sur ce poste pour que l'utilisateur soit
l'appelant.
Pour éviter de vous compliquer la vie, dans DCOMCNFG, vous pouvez
utiliser "This user" au lieu de "Interactive User". Dans "This user",
vous spécifiez un compte que vous aurez créé rien que pour cet usage et
qui aura les droits appropriés et rien que ceux-là. De cette manière,
sauf contre-indication applicative, quel que soit l'utilisateur
appelant, vous utiliserez le même compte pour exécuter la requête.
Cette approche n'est bien sûr pas appropriée si le comportement du
serveur varie en fonction des droits de l'utilisateur appelant ou si le
service ne doit pas être accessible à certains utilisateurs.
Maintenant que le problème est identifié, je vous conselle de lire ce
document
qui va vous aider à définir la meilleure stratégie en fonction de vos
besoins applicatifs, de la configuration de votre domaine, etc. Je ne
peux pas préconiser un choix plus qu'un autre sans connaître votre
environnement et vos besoins. Mais je pense que vous avez maintenant
tous les éléments (ou presque :-) ) en main.
Bon courage.
Une dernière remarque:
En DCOM, le plus pénible, vous l'avez remarqué, ce sont les réglages
sécurité. C'est pour cela qu'en matière de services distribués, la
tendance est désormais à l'utilisation de Web Services via le protocole
SOAP, même sur un Intranet. Avec la technologie .Net, c'est très facile
à mettre en oeuvre, côté client comme côté serveur. Si vous êtes coincée
avec VB6, il y a un toolkit qui permet d'interagir avec un Web Service:
le SOAP tookit
(http://www.microsoft.com/downloads/details.aspx?FamilyIDÉ43c0dd-ceec-4088-9753-86f052ec8450&displaylang=en),
un ensemble de composants COM clients qui vous facilite la tâche de
programmation du client d'un Web Service.
Si vos essais actuels sont du simple maquettage et si rien n'est fixé en
matière de design, je vous conseille fortement l'approche Web Service
plutôt que DCOM. Ceci étant, sur un Intranet, DCOM fonctionne bien une
fois que tout est réglé correctement. Mais si le service doit être un
jour distribué à l'extérieur (via Internet), ce n'est pas la bonne
approche.
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
Il ne me reste plus qu'à trouver comment définir les droits sur ce poste pour que l'utilisateur soit l'appelant.
Pour éviter de vous compliquer la vie, dans DCOMCNFG, vous pouvez utiliser "This user" au lieu de "Interactive User". Dans "This user", vous spécifiez un compte que vous aurez créé rien que pour cet usage et qui aura les droits appropriés et rien que ceux-là. De cette manière, sauf contre-indication applicative, quel que soit l'utilisateur appelant, vous utiliserez le même compte pour exécuter la requête.
Cette approche n'est bien sûr pas appropriée si le comportement du serveur varie en fonction des droits de l'utilisateur appelant ou si le service ne doit pas être accessible à certains utilisateurs.
Maintenant que le problème est identifié, je vous conselle de lire ce document
qui va vous aider à définir la meilleure stratégie en fonction de vos besoins applicatifs, de la configuration de votre domaine, etc. Je ne peux pas préconiser un choix plus qu'un autre sans connaître votre environnement et vos besoins. Mais je pense que vous avez maintenant tous les éléments (ou presque :-) ) en main.
Bon courage.
Une dernière remarque: En DCOM, le plus pénible, vous l'avez remarqué, ce sont les réglages sécurité. C'est pour cela qu'en matière de services distribués, la tendance est désormais à l'utilisation de Web Services via le protocole SOAP, même sur un Intranet. Avec la technologie .Net, c'est très facile à mettre en oeuvre, côté client comme côté serveur. Si vous êtes coincée avec VB6, il y a un toolkit qui permet d'interagir avec un Web Service: le SOAP tookit (http://www.microsoft.com/downloads/details.aspx?FamilyIDÉ43c0dd-ceec-4088-9753-86f052ec8450&displaylang=en), un ensemble de composants COM clients qui vous facilite la tâche de programmation du client d'un Web Service.
Si vos essais actuels sont du simple maquettage et si rien n'est fixé en matière de design, je vous conseille fortement l'approche Web Service plutôt que DCOM. Ceci étant, sur un Intranet, DCOM fonctionne bien une fois que tout est réglé correctement. Mais si le service doit être un jour distribué à l'extérieur (via Internet), ce n'est pas la bonne approche.
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
mc
>Pour éviter de vous compliquer la vie, dans DCOMCNFG,
vous pouvez
utiliser "This user" au lieu de "Interactive User".
Dans "This user",
vous spécifiez un compte que vous aurez créé rien que
pour cet usage et
qui aura les droits appropriés et rien que ceux-là. De
cette manière,
sauf contre-indication applicative, quel que soit
l'utilisateur
appelant, vous utiliserez le même compte pour exécuter
la requête.
Il semble que l'utilisateur qui appelle l'application doit être l'utilisateur loggué (Interactive User), sinon l'application AutoCAD que j'appelle ne fonctionne pas (appel d'une application tierce marche donc ainsi)
Il faut aussi que cet utilisateur (celui loggué sur le PC "serveur") ait les droits admin sur le PC serveur (le pourquoi je sais pas trop, mais ça semble nécessaire....).
Ouf! Ca marche maintenant, je vous remercie vraiment beaucoup, je ne sais pas si je m'en serais sortie toute seule (surtout depuis le temps que je cherchais, je commencais à manquer furieusement de recul...)
Merci, je l'ai imprimé et vais cogiter ça tout à l'heure, voire ce soir. Maintenant que je sais que le système marche, il y a moins d'urgence pour "fignoler" la question des droits. Je vais finir de débugguer l'applic client d'abord!
Bon courage.
Merci! ;)
Une dernière remarque: En DCOM, le plus pénible, vous l'avez remarqué, ce sont
les réglages
sécurité. C'est pour cela qu'en matière de services
distribués, la
tendance est désormais à l'utilisation de Web Services
via le protocole
SOAP, même sur un Intranet. Avec la technologie .Net,
c'est très facile
à mettre en oeuvre, côté client comme côté serveur. Si
vous êtes coincée
avec VB6, il y a un toolkit qui permet d'interagir avec
un Web Service:
le SOAP tookit (http://www.microsoft.com/downloads/details.aspx?
un ensemble de composants COM clients qui vous facilite
la tâche de
programmation du client d'un Web Service.
Encore un sujet que je cogiterais, peut-être pas pour cette fois, mais pour l'avenir. L'application actuelle est un "one shot" que je ne pense pas devoir distribuer ailleurs. Ce serveur est vraiment très spécifique, alors je pense que la solutiona actuelle convient. Mais comme déjà dit, si une situation semblable se représente je regarderai pour la faire en soap...
Salutations, Marina
>Pour éviter de vous compliquer la vie, dans DCOMCNFG,
vous pouvez
utiliser "This user" au lieu de "Interactive User".
Dans "This user",
vous spécifiez un compte que vous aurez créé rien que
pour cet usage et
qui aura les droits appropriés et rien que ceux-là. De
cette manière,
sauf contre-indication applicative, quel que soit
l'utilisateur
appelant, vous utiliserez le même compte pour exécuter
la requête.
Il semble que l'utilisateur qui appelle l'application
doit être l'utilisateur loggué (Interactive User), sinon
l'application AutoCAD que j'appelle ne fonctionne pas
(appel d'une application tierce marche donc ainsi)
Il faut aussi que cet utilisateur (celui loggué sur le
PC "serveur") ait les droits admin sur le PC serveur (le
pourquoi je sais pas trop, mais ça semble nécessaire....).
Ouf! Ca marche maintenant, je vous remercie vraiment
beaucoup, je ne sais pas si je m'en serais sortie toute
seule (surtout depuis le temps que je cherchais, je
commencais à manquer furieusement de recul...)
Merci, je l'ai imprimé et vais cogiter ça tout à l'heure,
voire ce soir. Maintenant que je sais que le système
marche, il y a moins d'urgence pour "fignoler" la
question des droits. Je vais finir de débugguer l'applic
client d'abord!
Bon courage.
Merci! ;)
Une dernière remarque:
En DCOM, le plus pénible, vous l'avez remarqué, ce sont
les réglages
sécurité. C'est pour cela qu'en matière de services
distribués, la
tendance est désormais à l'utilisation de Web Services
via le protocole
SOAP, même sur un Intranet. Avec la technologie .Net,
c'est très facile
à mettre en oeuvre, côté client comme côté serveur. Si
vous êtes coincée
avec VB6, il y a un toolkit qui permet d'interagir avec
un Web Service:
le SOAP tookit
(http://www.microsoft.com/downloads/details.aspx?
un ensemble de composants COM clients qui vous facilite
la tâche de
programmation du client d'un Web Service.
Encore un sujet que je cogiterais, peut-être pas pour
cette fois, mais pour l'avenir.
L'application actuelle est un "one shot" que je ne pense
pas devoir distribuer ailleurs. Ce serveur est vraiment
très spécifique, alors je pense que la solutiona actuelle
convient. Mais comme déjà dit, si une situation semblable
se représente je regarderai pour la faire en soap...
>Pour éviter de vous compliquer la vie, dans DCOMCNFG,
vous pouvez
utiliser "This user" au lieu de "Interactive User".
Dans "This user",
vous spécifiez un compte que vous aurez créé rien que
pour cet usage et
qui aura les droits appropriés et rien que ceux-là. De
cette manière,
sauf contre-indication applicative, quel que soit
l'utilisateur
appelant, vous utiliserez le même compte pour exécuter
la requête.
Il semble que l'utilisateur qui appelle l'application doit être l'utilisateur loggué (Interactive User), sinon l'application AutoCAD que j'appelle ne fonctionne pas (appel d'une application tierce marche donc ainsi)
Il faut aussi que cet utilisateur (celui loggué sur le PC "serveur") ait les droits admin sur le PC serveur (le pourquoi je sais pas trop, mais ça semble nécessaire....).
Ouf! Ca marche maintenant, je vous remercie vraiment beaucoup, je ne sais pas si je m'en serais sortie toute seule (surtout depuis le temps que je cherchais, je commencais à manquer furieusement de recul...)
Merci, je l'ai imprimé et vais cogiter ça tout à l'heure, voire ce soir. Maintenant que je sais que le système marche, il y a moins d'urgence pour "fignoler" la question des droits. Je vais finir de débugguer l'applic client d'abord!
Bon courage.
Merci! ;)
Une dernière remarque: En DCOM, le plus pénible, vous l'avez remarqué, ce sont
les réglages
sécurité. C'est pour cela qu'en matière de services
distribués, la
tendance est désormais à l'utilisation de Web Services
via le protocole
SOAP, même sur un Intranet. Avec la technologie .Net,
c'est très facile
à mettre en oeuvre, côté client comme côté serveur. Si
vous êtes coincée
avec VB6, il y a un toolkit qui permet d'interagir avec
un Web Service:
le SOAP tookit (http://www.microsoft.com/downloads/details.aspx?
un ensemble de composants COM clients qui vous facilite
la tâche de
programmation du client d'un Web Service.
Encore un sujet que je cogiterais, peut-être pas pour cette fois, mais pour l'avenir. L'application actuelle est un "one shot" que je ne pense pas devoir distribuer ailleurs. Ce serveur est vraiment très spécifique, alors je pense que la solutiona actuelle convient. Mais comme déjà dit, si une situation semblable se représente je regarderai pour la faire en soap...
