Hello,
I was wondering if there are any downsides of storing a custom Principal in httpcontext.current.items instead of the httpcontext.current.user. I know you need to set it for each request but I have to do that with httpcontext.current.user also.
thanks in advance,
Pickels
Why wouldn't you put it where the principal lives?
http://msdn.microsoft.com/en-us/library/system.threading.thread.currentprincipal(v=VS.100).aspx
Hi, HttpContext.Current.User is the location where the "authorization infrastructure" expects the Principal to be, and will look for him here. So, when he is there, many authorization-related features (based on IsInRole for example) will work automatically, when you store him on some other place, you will have to "hack" them to do their work.
Roman
This is some extra information that might help others. It actually answers my own question.
In this project they seem to do what I wondered before. They don't use a class that implements IPrincipal but they just store their own user object inside the HttpContext.Current.Items. How they maintain it between requests I still have to figure out. It seems that they use some kind of depedency injection for that.