Both ideas are good. The CallContext should work fine, as I can under
the impersonation when the connection closes (the new
ConnectionStateChange event in 2.0). The refactoring idea is nice in
that it feels a bit more clean. However, it does involve holding a
reference to the refactored class.

I think I'm going to go with the CallContext at this point.

Thanks,
Erick


-----Original Message-----
From: Unmoderated discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] On Behalf Of Ryan Heath
Sent: Tuesday, May 24, 2005 1:01 AM
To: [email protected]
Subject: Re: [ADVANCED-DOTNET] Using Windows Impersonation on SQL
connections and losing the Context

Hi Erick,

store the context within the thread; CallContext.SetData and
CallContext.GetData.

although it will work, it couples your code to much. You will write code
that will call undo on the context save within the thread each and every
time.

Maybe refactor the SqlConnection into another class which also handles
the impersonation and undo-impersonation, in its <shrug> Dispose...

HTH
// Ryan

On 5/24/05, Erick Thompson <[EMAIL PROTECTED]> wrote:
> I'm using WindowsImpersonationContext for ADO.NET 2.0 code to do 
> integrated authentication from a web service. I'm using the 
> Impersonate method on a WindowsIdentity before opening the SQL 
> connection, and it works great. The pattern that I've seen in all 
> examples is
> 
> WindowsImpersonationContext context = identitiy.Impersonate(); // do 
> database work context.Undo();
> 
> This works fine, but it leads to a lot of code. My code uses a 
> connection factory, so I figure in my construction method, I can do 
> the impersonation then.
> 
> Public static SqlConnection GetConnection() {
>        // do connection setup
>        WindowsImpersonationContext context = identitiy.Impersonate(); 
> }
> 
> This also works fine. However, the problem is that once I've done the 
> impersonation and run my DB code, I can't undo the impersonation, as 
> I've lost the reference to the impersonation context. Given that I'm 
> using this code in a window service, it might not matter. However, I 
> don't like leaving the current thread in a different state then when I

> started. So I'm hoping for suggestions, either a way to get/store the 
> impersonation context, or confidence that I don't need to worry about 
> it.
> 
> Thanks,
> Erick
> 
> ===================================
> This list is hosted by DevelopMentor(r)  http://www.develop.com
> 
> View archives and manage your subscription(s) at 
> http://discuss.develop.com
>

===================================
This list is hosted by DevelopMentor(r)  http://www.develop.com

View archives and manage your subscription(s) at
http://discuss.develop.com

===================================
This list is hosted by DevelopMentor�  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com

Reply via email to