开发者

.Net Ramifications of changing Thread.CurrentPrincipal

开发者 https://www.devze.com 2023-01-01 12:25 出处:网络
I\'ve got a simple WPF 4.0 app that currently has no concept of user security. I need to add some very simple username/password based security and access the credentials in just a couple of spots, and

I've got a simple WPF 4.0 app that currently has no concept of user security. I need to add some very simple username/password based security and access the credentials in just a couple of spots, and want to utilize Thread.CurrentPrincipal. I am wondering what the ramifications of simply changing this property are? Will it affect the .Net Framework or limit the application in any way? Or, as I suspect, will it have zero effect until I utilize开发者_如何学Python it elsewhere in my app?


You should be fine changing Thread.CurrentPrincipal, as it is a standard mechanism for using principals within .Net, especially as you have a WPF application.

Be careful when dealing with ThreadPool threads though - don't change it on a thread from the thread pool unless you also set it back to its original value before you let the thread die. Thread pool threads can be reused and are not "reset", so any principal you set on the thread will remain when/if the thread is obtained again from the thread pool - you don't know what could obtain this thread.

This is actually how Windows and IIS deal with authentication with .Net. If you call

AppDomain.CurrentDomain.SetPrincipalPolicy(PrincipalPolicy.WindowsPrincipal);

in your code, the currently logged-on user will be populated into Thread.CurrentPrincipal for you.

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号