Discussion :

[2020]

Bonjour,

Est il possible de transmettre ou partager un IIDentity entre plusieurs domaines?

Je m'explique : nous avons développé un logiciel dans lequel nous créons un GenericIdentity (l'authentification est faite à l'aide de la DB et non à l'aide du WindowsIdentity) que nous chargeons dans le System.Threading.Thread.CurrentPrincipal.Identity du thread principal de l'application.

Dans notre application nous utilisons aussi le CLR Add-In permettant de charger des plugins de manière isolée dans un nouveau Domaine (pour faire court).

Mon problème est que mes plugins ont besoin de connaitre l'utilisateur qui exécute l'application afin de faire différents contrôles d'accès et opérations en DB.

System.Threading.Thread. etant lié au domaine de l'application, l'information n'est donc pas disponible pour mes plugins.

De plus pour le moment je veux éviter de faire passer l'IIdentity par paramètre lors de l'appel des plugins. Je cherche donc une solution pour stocker mon IIdentity quelquepart qui serait accessible pour tout le monde plugins et Application.

Ou si quelqu'un connait bien le CLR ADD-IN me dire comment on peux gérer et partager ce type d'info entre application et plugins.

Dans le même genre une autre question : dans un même domaine lorsque l'on développe des threads, comment s'assurer que ceux-ci récupèrent bien l'IIendity dans le thread principal. Parce que là aussi a chaque thread créé de je suis obligé avant d'exécuter mon code asynchrone de redéfinir le System.Threading.Thread.CurrentPrincipal sinon je le paume, ce qui est assez fastidieux vu le nombre de traitements asynchrones que l'on fait. Y a t'il un moyen de "partager" (stocker dans le domaine ou autre ou definir par defaut pour tous les threads) cette information pour faciliter le développement ?

Merci d'avance,
2020

[lysiandad]

Est il possible de transmettre ou partager un IIDentity entre plusieurs domaines?

Theoriquement oui, puisque ce n'est qu'un cas particulier de partage d'information inter-AppDomain, qui est prévu par l'architecture .NET.

Je m'explique : [...]
De plus pour le moment je veux éviter de faire passer l'IIdentity par paramètre lors de l'appel des plugins. Je cherche donc une solution pour stocker mon IIdentity quelquepart qui serait accessible pour tout le monde plugins et Application. [...]
[...] Y a t'il un moyen de "partager" (stocker dans le domaine ou autre ou definir par defaut pour tous les threads) cette information pour faciliter le développement ?

Je ne suis pas sûr d'avoir compris tous les tenants et aboutissants de votre problematique, et pour cette raison (ou parce que j'oublie un élément de conception relatif à IIdentity et IPrincipal dans le framework...), je vais peut être dire une betise mais...

... si pour votre application vous voulez en fait partager cet IIdentity par tous les AppDomain, celui par defaut de l'appli, et ceux de plug ins, vous pouvez adresser les problemes de vos deux questions en deleguant l'implementation de des accesseurs "get" de votre GenericIdentity / IIdentity a un autre objet, qui sera "partagé" par ces AppDomains..

En clair, dans votre implementation de GenericIdentity / IIdentity, vous agregez (pattern de composition) un objet "proxy" (disons, un "SharedIdentity", p.ex, implementant IIdentity) qui ira chercher les valeurs dans l'objet partagé contenant cette "identité" unique effective.

Je suppose que ce dernier sera defini (dans le temps) par le premier AppDomain (celui par defaut de l'application) ; evidemment, si il y a mutation de l'etat concret (champs private, etc) de cet objet pour une raison X ou Y (mais je ne pense pas, pour une IIdentity, non ?) il vous faudra gerer vous meme la synchronization en accès inter thread (via bloc "lock(SyncRoot) { ... }" ou autre).

Pour un exemple "generique" d'objet partagé entre AppDomains, qui possiblement correspond a votre environnement (1 appli + n plug ins, dans m appdomains, d'un même processus local, c'est ça ?), vous avez entre autres :

http://msdn.microsoft.com/en-us/libr...refobject.aspx

(c'est l'exemple 1)

'HTH

[2020]

Bonjour,

Merci pour votre réponse.

Je vais regarder pour cet objet "Proxy", cela semble être en effet la solution recherchée.

Je suppose que ce dernier sera defini (dans le temps) par le premier AppDomain (celui par defaut de l'application) ; evidemment, si il y a mutation de l'etat concret (champs private, etc) de cet objet pour une raison X ou Y (mais je ne pense pas, pour une IIdentity, non ?) il vous faudra gerer vous meme la synchronization en accès inter thread (via bloc "lock(SyncRoot) { ... }" ou autre).

En effet il n'y aura pas de mutation de l'état de mon objet.

Je regarde et je reviendrai vers vous en cas de problème.

Merci encore.