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� http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
