Code et traçabilité.

Bonjour,

Dans le cadre d'une application, dans certaines classes, je souhaite vérifier la présence d'attributs spécifiques sur l'appelant du code.

Je m'explique... J'ai une classe A avec une méthode public alpha().
Cette méthode peut etre appelée depuis plusieurs classes, B, C, D...
chaque classe qui l'appelle est suceptible de porter des Attributs spécifiques.

Ce qui m'intéresse c'est au niveau de A.alpha() récupéré au moment de l'exécution, quelle classe et a priori quelle méthode, a fait cet appel, pour pouvoir extraire les attributs custom de cette classe/méthode. (en gros je veux tracer l'appelant... pour vérifier qui a fait cet appel... ca me sert également à déterminer quelle confiance je peux accorder aux données fournie à A.alpha.. et le mettre en internal ne règlerais pas mon problème)

Tu envoie une référence sur l'appelant dans ton appel et tu test si il est de tel ou tel type après tu fais ton traitement.

ex dans B tu fais A.alpha(this, args);

Je crois meme qu'il y a une fonction en dotnet pour récuperer dans quel bloc tu te trouve donc tu envoi aussi l'info de la fonction en question.

a voir dans le System.Runtime

oui ce serait une solution, mais c'est pas tellement le but :)

car je peux pas forcément avoir confiance dans le développeur qui peut choisir de mettre une référence d'une instance systeme qui elle a un niveau d'approbation maximale.

quand on développe une api, framework, on ne doit pas partir du principe qu'on peut faire confiance au developpeur final, car s'il y a une connerie à faire, tu peux etre sure qu'il la fera...
je le sais, j'ai été dans le cas, une développeur a utiliser le framework et la première chose qu'il a faite, c'est justement ce qu'il ne devait pas faire...

je dois vraiment traquer l'appelant automatiquement sans avoir à faire appel à la responsabilité du développeur

Bon alors au fil de mes recherches dans la doc du framework, j'ai fini par trouver un début de solution.

Code:

---

public string Environment.StackTrace { get; }

---

Permet de récupèrer la trace de la pile d'exécution.
une fois la quatrième ligne récupérée et correctement parsée, il y a moyen de récupèrer le nom (namespace compris) du type responsable de l'appel.
A partir de là grâce au mécanisme de reflexion on peut facilement obtenir le type de l'objet dont on à le nom complet, et de là extraire les informations que l'on souhaite dessus (les attributs prédéfinis et custom)

Si toutefois quelqu'un voie une solution plus simple et plus efficace, je reste ouvert, toute proposition, surtout d'une solution ne mettant pas en cause du parsing de chaine qui peut d'une langue à l'autre changer complètement.

Si ca intéresse quelqu'un j'ai encore trouvé beaucoup mieux :)

et oui, en cherchant pas mal,

Dans "System.Diagnostics" on trouve une classe StackTrace collection de StackFrame, et cette classe StackTrace permet d'obtenir l'état de la pile d'appel au moment où on lui demande.

Ainsi, le premier élément que l'on sort de la pile d'appel c'est le code où stackstrace est instancié, au niveau juste en dessous, la méthode appelante, de là on peut extraire le type d'où sort la méthode et donc en extraire les attributs :)

Voila fini par trouver une solution qui permet de ne pas faire une confiance aveugle dans la responsabilité des developpeurs générallements irresponsables...

Merci à tous.

Jouer avec StackTrace est très lent cela dit.
Tu peux aussi jeter un oeil du côté des attributs de sécurité dans System.Security.Permissions. C'est fait pour ce genre de choses à la base.


Après, Murphy oblige, tu peux blinder autant que tu veux mais tu tomberas toujours sur un boulet qui te cassera tout :)

oui le boulet est partout :bug: et tant que l'on aura pas inventé un pc qui fait exactement ça : :bug: on ne sera pas a l'abri

oui c'est vrai aussi... enfin cela dit j'ai d'autres intentions, aussi.

pour la sécurité les permissions c pas mal mais ya d'autres choses également.

Je manipule des tonnes d'attributs avec des tas de métadonnées à l'intérieur :)
Ca me permet de controler ce que je dois activer comme mécanisme ou pas, (si ta pas mis que t'utilise un service du noyau... il est pas chargé, et zou .... un gros message d'erreur te rappel que tu es un gros boulet qui ferait mieux de changer de métier)

Car mine de rien, la reflection non plus n'est pas des plus rapides. Charger dynamiquement et instancier un type à la volée (surtout dans une assembly chargée àla volée) c'est lent.
Bon c sur ya la mise en cache mais a règle pas tout.

Question bête : avec tout le temps que tu a l'air de passer pour contrôler que personne ne fait n'importe quoi, est-ce qu'il reste encore du temps pour faire ce dont le client a besoin ?

Parce que bon, mis à part le fait que peu importe la quantité de contrôle dans le code, quelqu'un passera toujours (toujours) au travers des mailles du filet, il y a déjà un truc qui existe pour s'assurer que le code fait bien ce qu'il faut : les tests unitaires. Ça ne demande quasiment aucun temps de mise en place, ça n'alourdit pas le code et ça fait gagner du temps au final plutôt que l'inverse.
Et il y a déjà les outils qu'il faut pour vérifier que le code fait par d'autres est correctement couvert par les tests.
Et il y a aussi le test-driven development pour s'assurer que l'intégralité du code écrit correspond aux besoins et est automatiquement validé par les tests. C'est plus difficile à maîtriser par contre.

Enfin bref. Quitte à passer un temps monstre à empêcher les dévs de faire n'importe quoi, autant le passer à les 'obliger' à faire des tests unitaires sur leur code plutôt que d'attendre qu'ils mettent n'importe quoi et de faire planter à l'exécution.