Discussion :

[ZZZzzz2]

Bonjour,

tout est dans le titre, mais je vais tout de même donner quelques détails :

J'ai créé un serveur DCOM, hors processus, sous la forme d'un exe qui se lance dès qu'on se connecte sur un de ces objets.

Le problème est le suivant, actuellement ce serveur n'était utilisait que localement, et donc dès qu'on se connectait sur un objet, on utilise le mode "runing or new" afin de partager la même instance entre tous les clients (sauf pour un objet particulier dont chaque client garde une instance).

Seulement voilà, depuis peu nous devons nous connecter depuis un poste distant sur ces objets. La seule façon possible est alors de créer un nouvel objet (on ne peut se connecter à distance sur un objet existant, "GetActiveObject" ne fonctionne qu'en local). J'aimerai à partir de ces objets (côté serveur DCOM donc), pouvoir identifier le client se connectant. Par exemple en récupérant l'adresse IP, le nom de l'hôte, ou que sais-je encore ?

Mes clients se connectent à distance en utilisant l'API "CoCreateInstanceEx"

Est-ce possible ?

[ShaiLeTroll]

Où je travaille, on utilise aussi le DCOM, en développement, je suis en local mais tous nos clients sont en mode distant !
Je crois que tout se joue avec les options passé à Dcomcnfg
Ce n'est pas le client qui décide si il va créer le process DCOM sur le poste ou sur une machine distante mais les règles de sécurité DCOM !
Une vraie uzinagaz signé Microsoft !

Ensuite, tu peux ajouter aussi les droits par API, c'est une vrai joie avec AddAccessAllowedAce
On trouve plusieurs exemple d'utilisation pour le DCOM

[ZZZzzz2]

Où je travaille, on utilise aussi le DCOM, en développement, je suis en local mais tous nos clients sont en mode distant !
Je crois que tout se joue avec les options passé à Dcomcnfg
Ce n'est pas le client qui décide si il va créer le process DCOM sur le poste ou sur une machine distante mais les règles de sécurité DCOM !
Une vraie uzinagaz signé Microsoft !

Ensuite, tu peux ajouter aussi les droits par API, c'est une vrai joie avec AddAccessAllowedAce
On trouve plusieurs exemple d'utilisation pour le DCOM

Merci ShailLeTroll, c'est impressionnant tu réponds toujours à toutes mes questions. Je me demande comment tu fais pour être aussi présent (et en savoir autant).

A vrai dire je me suis pris la tête (et c'est pas peu dire) avec la sécurité DCOM, c'est vraiment très compliqué de trouver comment on doit paramétrer tout cela dès qu'on fait des connexions à distance. Effectivement via dcomcnfg tu peux "forcer" la connexion à distance ou pas, mais nous ne procédons pas ainsi. Notre appli décide (en fonction du contexte) soit d'utiliser son serveur DCOM local (cas habituel) soit de se connecter sur un serveur distant. J'ai (en principe) réussi à automatiser la configuration d'un poste afin qu'il accepte les connexions entrantes en tant que serveur mais aussi en tant que client (car notre serveur DCOM rebalance des événements au client, donc "connexion dans les 2 sens"), mais j'ai un doute sur le bon fonctionnement avec les postes sous Windows 7 :-/... Je peux te dire que je me suis bien "éclaté" avec tout ça (écriture d'une fonction "AddAceToObjectsSecurityDescriptor", etc...) car évidemment le but est que toutes les combinaisons fonctionne (par exemple entre 2 postes de domaines différents, avec n'importe quel utilisateur). Évidemment ce paramétrage du poste ne s'effectue en principe qu'une fois et nécessite un compte admin.

Enfin là n'est pas mon problème, actuellement au niveau du serveur DCOM, je ne sais pas identifier le client qui se connecte. Je veux dire par là que si plsuieurs clients se connectent sur mon serveur en instanciant chacun plusieurs objets à des moments différents, je suis incapable de savoir si 2 instances d'objet différents appartiennent ou non au même client. Et c'est précisément ça que j'aimerai savoir.

[ShaiLeTroll]

Tu pourrais ajouter une fonction d'identification à tes objets,
Lors du Create, tu fournis un identifiant (IP sous forme d'un integer par exemple) et un identifiant de module, ou je ne sais quoi !
tu pourrais aussi le faire par un système d'évènement à implanter par le client qui doit remplir un objet IContext contenant tout ce que tu as besoin

Dans nos programmes serveurs, il n'y a pas de tri, les objets étant abonné à des notifications de messages, reçoit le message émi par un autre programme, cela balaye tous les clients !
C'est assez costaud, presque 10 ans d'existence !
Pour les clients seven, je sais que l'on a des soucis surtout avec les clients 64Bits qui isolent leur session sur le serveur (lui étant un 32Bits encore, c++Builder oblige)

Je t'avoue pour le moment le DCOM, c'est bien obscur !
Je n'ai joué qu'avec le local !
J'en avais déjà fait ailleurs mais totalement encapsulé aussi, j'avais juste à utiliser le framework !

[ZZZzzz2]

Tu pourrais ajouter une fonction d'identification à tes objets,
Lors du Create, tu fournis un identifiant (IP sous forme d'un integer par exemple) et un identifiant de module, ou je ne sais quoi !
tu pourrais aussi le faire par un système d'évènement à implanter par le client qui doit remplir un objet IContext contenant tout ce que tu as besoin

Dans nos programmes serveurs, il n'y a pas de tri, les objets étant abonné à des notifications de messages, reçoit le message émi par un autre programme, cela balaye tous les clients !
C'est assez costaud, presque 10 ans d'existence !
Pour les clients seven, je sais que l'on a des soucis surtout avec les clients 64Bits qui isolent leur session sur le serveur (lui étant un 32Bits encore, c++Builder oblige)

Je t'avoue pour le moment le DCOM, c'est bien obscur !
Je n'ai joué qu'avec le local !
J'en avais déjà fait ailleurs mais totalement encapsulé aussi, j'avais juste à utiliser le framework !

Hum, je vais y réfléchir, mais j'ai beaucoup d'objet (une 40aine) et la connexion est implicite (appelé lors de la première utilisation de l'objet), donc ça va demander de modifier pas mal de choses j'en ai peur.
Il y a bien un objet particulier qui identifie son client dans le sens ou celui-ci envoie le nom de son module (mais pas son adresse IP par contre, ce qui pourrait être une idée), mais cela ne concerne qu'un seul des objets : celui qui chaque client instancie à nouveau (tandis que les autres sont partagés, sauf en connexion distante bien sûr). J'aurai bien aimé qu'il y ait une possibilité au niveau de la connexion entrante sur le serveur de récupérer des infos sur le client permettant de l'identifier, sans avoir à les passer explicitement.



Le problème que je rencontre sur Win 7 concerne justement des postes 64 bits, même en ayant bien paramétré le serveur DCOM et le pare-feu la connexion distantes échouent. Mais seulement entre 2 postes Windows 7 64 bits (la connexion d'un poste Windows 7 64bits vers un autre Windows semble bien fonctionner). C'est assez curieux car même en activant tous les logs possibles dans le journal des événements je ne vois rien, ou alors si mais une fois sur 20, un simple message du genre "le serveur a retourné l'erreur "accès refusé", mais côté serveur aucune explication du pourquoi du comment (pour la connexion a-t-elle été refusé). Enfin franchement ya encore des comportements parois bizarres si ce n'est obscures pour moi.