Konieczność impersonacji (użycia poświadczeń innego uprawnionego użytkownika) w kodzie plug-in’ów jest dość powszechna. Często bowiem zdarza się, że kod uruchamiany wewnątrz plug-in’u powinien być uruchamiany za pomocą konkretnego konta (np. dlatego, że konto to ma dostęp do zewnętrznego systemu).
Sytuacja domyślna:
Należałoby zacząć od kontekstu w jakim uruchamiane są plug-in’y. Otóż, plug-in’y zawsze domyślnie uruchamiają się w kontekście konta, na którym działa pula aplikacji serwera CRM. To znaczy, że w większości wypadków kod będzie działał wykorzystując konto „NETWORK SERVICE”, które w Dynamics CRM reprezentowane jest jako użytkownik „SYSTEM”.
Impersonacja innego użytkownika:
Aby użyć poświadczeń innego użytkownika, możemy zmienić konto, na którym zadziałają plug-in’y. Możemy to zrobić podczas rejestracji plug-in’u. Operacja polega na wybraniu w narzędziu do rejestracji plug-in’ów konta, które ma być użyte do wykonania kodu albo ustawienie tego konta jako wartości pola impersonatinguserid:
Aby użyć wybranego podczas rejestracji konta w plug-in’ie musimy utworzyć proxy usługi sieciowej, wykorzystując metodę obiektu context:
ICrmService naszWebService = (ICrmService)context.CreateCrmService(true);
Jeśli zostawimy puste pole impersonatinguserid i wywołamy powyższą metodę, użyjemy poświadczeń aktualnie zalogowanego użytkownika, a więc tego, którego działanie wywołało plug-in. Jeśli w czasie działania (runtime plug-in impersonation) chcielibyśmy zmienić poświadczenia z wybranego podczas rejestracji konta na użytkownika, który uruchomił plug-in, możemy utworzyć web service z następującym parametrem:
ICrmService naszWebService = (ICrmService)context.CreateCrmService(context.InitiatingUserId);
Polski blog o Microsoft Dynamics 365 
Z jakiego narzędzia do rejestracji plug-inow korzystasz? Moje niestety nie daje tej funkcjonalności. Zazwyczaj eksportuje xmla, zmieniam w edytorze i spowrotem importuje.
Z Plug-in Registration Tool dostępnego w SDK albo tutaj: http://code.msdn.microsoft.com/crmplugin 🙂 I wtedy ekran wygląda jak na screenie załączonym do posta. Ty pewnie korzystasz z Developer Tool, skoro importujesz XML, czy nie?
Dokladnie Microsoft CRM 4.0 Developers Tool ze strony http://www.patrickverbeeten.com. Strasznie narzekam na to narzedzie. Nie importuje nowych dllek do bazy i musze za pierwszym razem importowac dllke z kodu .netowego, pozniej jestem zadowolony z nawigacji. W sumie podoba mi sie to ze mam dostep do xmla i widze co sie tam dzieje. Wersja 2.1 (byc moze jeszcze 2.0 registration toola) wywalala mi caly czas bledy. Pewnie warto zainteresowac sie 2.2. Chyba przeszla face lifting bo nie poznalem ze screen shota. Ostatnio dostalem namiary na to http://ryandev.com/wp-content/uploads/2008/12/pluginregistration.zip, masz jakies z tym doswiadczenia?
aa i madrze zrobiles ustawiajac nofollow do externali na blogu!
Inaczej podnosiłbym pagerank spamerom (i innym 😉 ). Dlatego musiałem.
Co oznacza „To znaczy, że w większości wypadków kod będzie działał wykorzystując konto “NETWORK SERVICE”, które w Dynamics CRM reprezentowane jest jako użytkownik “SYSTEM”.”
w jakich wypadkach nie bedzie to w/w uzytkownik? W SDK jest napisane, ze czasami bedzie to uzytkownik, ktory wykonuje plugin… ale nie moge sie doszukac od czego to zalezy… 😀
a zalezy mi na tym wlasnie, aby wykonywac plugina w kontekscie SYSTEM (operacje, ktorych uzytkownik normalnie nie moze przeprowadzic z UI, musza byc zrobione przez ‚platforme’)…
Wiem, ze istnieje opcja podrejestrowania pluginu wprost do wykonywania w kontekscie uzytkownika SYSTEM… ale jest to uzytkownik ‚for internal use’ wiec nie wiem, czy to supportowalne 😀
Dzieki za ciekawe informacje