[.NET]TraceListeners en impersonation: 1 account gebruiken?

[MrBucket]

Ik wil een stukje tracing inbouwen in mijn ASP.NET 3.5 applicatie. Dit doe ik door middel van TraceSources en TraceListeners (zie o.a. http://weblogs.asp.net/ra...personal-vade-mecum.aspx). Om precies te zijn gebruik ik de XmlWriterTraceListener om mijn traceinformatie te loggen naar een .xml-bestand in een Log directory. Op zich werkt dit als een zonnetje, en mijn messages worden keurig weggeschreven naar het log-bestand...

...mits de huidige domein-user schrijfrechten heeft in de Log-directory.

Mijn ASP.NET applicatie werkt namelijk met IIS authentication i.c.m. impersonation (zie o.a. http://msdn.microsoft.com/en-us/library/134ec8tc(VS.80).aspx), wat betekent dat de thread die de trace-messages weg moet schrijven draait onder de identiteit van de gebruiker die op dat moment de pagina bekijkt.

Nu zou ik toch graag ten alle tijden willen kunnen tracen, dus nu zie ik 2 mogelijkheden:

1) De group "Everyone" schrijfrechten geven op de Log folder
2) Bij elke TraceSource.TraceXxx() ervoor zorgen dat de thread tijdelijk onder een voorgedefinieerd account draait (mag een specifiek Trace-account zijn, maar ook Network Service), zodat ik alleen dat account schrijfrechten hoef te geven op de Log-folder.

De eerste optie is eigenlijk geen goede optie (althans, geen nette waar de beheerders blij van zullen worden), dus voor zover ik zie zou ik voor optie 2 moeten gaan. Nu blijkt dat het nog niet zo makkelijk is om de thread van identiteit te laten wisselen (zie o.a. http://aspalliance.com/39), dus echt aanlokkelijk is dit ook niet.

Alleen, ik kan me bijna niet voorstellen dat ik dergelijke kunstgrepen moet uithalen om wat trace-messages weg te kunnen schrijven. Zit ik inderdaad op het verkeerde pad, of...?

[H!GHGuY]

Kun je je logging niet in een ander AppDomain steken wat met andere rechten draait?

Alle clients kunnen dan van dezelfde logging facility gebruik maken.

[MrBucket]

H!GHGuY schreef op zaterdag 07 maart 2009 @ 08:40:
Kun je je logging niet in een ander AppDomain steken wat met andere rechten draait?

Alle clients kunnen dan van dezelfde logging facility gebruik maken.

Hoe zou dat in z'n werk gaan dan? Volgens mijn (niet zo uitgebreide) kennis van AppDomains hoef een appdomain geen aparte thread te hebben, maar kan het gewoon gebruikt worden door de hoofdthread van je applicatie. Is het dan niet zo dat nog steeds de identity op de thread gebruikt wordt om je rechten te bepalen, niet de rechten die je op het appdomain hebt gedefinieerd?

Overigens had ik al wel in m'n achterhoofd zitten om, als mocht blijken dat het per trace-call impersonaten van een ander account teveel overhead zou opleveren, om dan eventueel een aparte trace-thread te maken die onder dit account blijft draaien. De hoofdthread zou dan trace-messages via een queue aan de trace-thread kunnen geven, die ze vervolgens daadwerkelijk wegschrijft.

Of misschien vereis ik toch maar gewoon dat iedereen mag krassen in de Log-folder. Scheelt wel een hoop werk...

[H!GHGuY]

Een appdomain kun je eigenlijk bijna zien als een aparte applicatie. Dus ik zou gaan verwachten dat je je AppDomain als een andere user kan laten draaien. Het is qua security denk'k ook een plus om bepaalde functionaliteit in een apart AppDomain onder te brengen.

Waarschijnlijk moet je sowieso gaan werken met een aparte log-thread.

[roy-t]

Kun je niet je eigen HTTPservice maken die zich abonneert op het error event, als het goed is is het mogelijk om een service in een eigen account te laten draaien.

[Verwijderd]

Misschien kan IsolatedStorage je een oplossing bieden?
http://msdn.microsoft.com/en-us/library/bdts8hk0.asp

[MrBucket]

Verwijderd schreef op maandag 09 maart 2009 @ 12:15:
Misschien kan IsolatedStorage je een oplossing bieden?
http://msdn.microsoft.com/en-us/library/bdts8hk0.asp

Eh... The resource you are looking for has been removed, had its name changed, or is temporarily unavailable
Maar het concept van Isolated Storage is me bekend hoor.

roy-t schreef op zaterdag 07 maart 2009 @ 18:52:
Kun je niet je eigen HTTPservice maken die zich abonneert op het error event, als het goed is is het mogelijk om een service in een eigen account te laten draaien.

Nou, gaat me niet (alleen) om de errors, maar meer om welke business-methoden aangeroepen worden en welke plugins hierdoor getriggerd worden. Voor de rest heb je gelijk: een aparte trace-service zou geen rechtenissues moeten geven.

Het probleem met de meeste oplossingen die aangedragen worden is dat ze (voor mijn gevoel) allemaal behoorlijk complex zijn voor zoiets simpels als een paar trace-messages wegschrijven. Maar jullie ideeen hebben me wel geholpen om er redelijk van overtuigd te kunnen zijn dat er geen voor de hand liggende optie bestaat, anders was die ongetwijfeld al genoemd.

Ik heb nu een voorlopige trace-implementatie staan die gewoon onder de impersonated gebruiker trace-messages wegschrijft, en wat dus vereist dat 'Everyone' schrijfrechten krijgt in de Log-folder. Voorlopig zal ik het bij deze implementatie moeten laten, want er zijn meer urgente zaken die geimplementeerd moeten worden, helaas...

Mocht ik toch nog kans zien om dit probleem netjes op te lossen, dat laat ik het hier weten.

Tot zover iedereen bedankt voor het meedenken!

[Verwijderd]

MrBucket schreef op maandag 09 maart 2009 @ 19:47:
[...]

Eh... The resource you are looking for has been removed, had its name changed, or is temporarily unavailable
Maar het concept van Isolated Storage is me bekend hoor.


[...]

De x achter de url is weggevallen nu doet ie het:
http://msdn.microsoft.com/en-us/library/bdts8hk0.aspx

[roy-t]

MrBucket schreef op maandag 09 maart 2009 @ 19:47:
[...]

Eh... The resource you are looking for has been removed, had its name changed, or is temporarily unavailable
Maar het concept van Isolated Storage is me bekend hoor.


[...]

Nou, gaat me niet (alleen) om de errors, maar meer om welke business-methoden aangeroepen worden en welke plugins hierdoor getriggerd worden. Voor de rest heb je gelijk: een aparte trace-service zou geen rechtenissues moeten geven.

Het probleem met de meeste oplossingen die aangedragen worden is dat ze (voor mijn gevoel) allemaal behoorlijk complex zijn voor zoiets simpels als een paar trace-messages wegschrijven. Maar jullie ideeen hebben me wel geholpen om er redelijk van overtuigd te kunnen zijn dat er geen voor de hand liggende optie bestaat, anders was die ongetwijfeld al genoemd.

Ik heb nu een voorlopige trace-implementatie staan die gewoon onder de impersonated gebruiker trace-messages wegschrijft, en wat dus vereist dat 'Everyone' schrijfrechten krijgt in de Log-folder. Voorlopig zal ik het bij deze implementatie moeten laten, want er zijn meer urgente zaken die geimplementeerd moeten worden, helaas...

Mocht ik toch nog kans zien om dit probleem netjes op te lossen, dat laat ik het hier weten.

Tot zover iedereen bedankt voor het meedenken!

Maar als je een apparte trace service maakt en die abboneert op je website dan heb je dus de traces, maar je gewone applicatie kan daar niet bij en hoeft niet schrijfrechten te hebben alleen je trace services. Is dat niet de oplossing?

[H!GHGuY]

Er is ook zoiets als Log4Net...