|
dev
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Asynchronous callback method: Thread.CurrentPrincipal roles emptyHello,
we load data asynchron. We have some user roles defined in Thread.CurrentPrincipal! But if we want to check using IsInRole in the callback of the delegate the roles are empty!! Is this normal? Is it another thread? How would you access the Roles of Thread.CurrentPrincipal so that it works in every thread? Thanks, Roland Hello Roland,
Could you show a sample? Because in my case it worked normally RM> Hello, RM> RM> we load data asynchron. RM> We have some user roles defined in Thread.CurrentPrincipal! RM> But if we want to check using IsInRole in the callback of the RM> delegate the roles are empty!! RM> RM> Is this normal? Is it another thread? RM> RM> How would you access the Roles of Thread.CurrentPrincipal so that it RM> works in every thread? RM> RM> Thanks, Roland RM> --- WBR, Michael Nemtsev :: blog: http://spaces.msn.com/laflour "At times one remains faithful to a cause only because its opponents do not cease to be insipid." (c) Friedrich Nietzsche Hi Michael,
just i wanted to search in the webreferences for the code. It is /// <remarks/> public System.IAsyncResult BeginLoadUpstairsProductGroup(int productGroupId, System.AsyncCallback callback, object asyncState) { return this.BeginInvoke("LoadUpstairsProductGroup", new object[] { productGroupId}, callback, asyncState); } I set breakpoints to this method (A) and to the callback method (B) to see the thread-IDs. And now the surprise: the Roles of Thread.CurrentPrincipal aren't empty any more! Thats so crazy!?!?!? Yesterday they were empty stepping in the method (C) after the callback method. Now in C the Roles of Thread.CurrentPrincipal are set..... I use MS Visual Studio 2005 - perhaps something got wrong or cached with the webreferences........... My problem is gone now, just through stepping in the webreference............. I am lucky but also shocked about this situation. Michael Nemtsev schrieb: Show quote > Hello Roland, > > Could you show a sample? Because in my case it worked normally > > RM> Hello, > RM> RM> we load data asynchron. > RM> We have some user roles defined in Thread.CurrentPrincipal! > RM> But if we want to check using IsInRole in the callback of the > RM> delegate the roles are empty!! > RM> RM> Is this normal? Is it another thread? > RM> RM> How would you access the Roles of Thread.CurrentPrincipal so > that it > RM> works in every thread? > RM> RM> Thanks, Roland > RM> --- > WBR, > Michael Nemtsev :: blog: http://spaces.msn.com/laflour > > "At times one remains faithful to a cause only because its opponents do > not cease to be insipid." (c) Friedrich Nietzsche > > Roland Müller <roland.muel***@flad.de> wrote:
> we load data asynchron. You can't. The point of Thread.CurrentPrincipal is that it's thread-> We have some user roles defined in Thread.CurrentPrincipal! > > But if we want to check using IsInRole in the callback of the delegate > the roles are empty!! > > Is this normal? Is it another thread? > > How would you access the Roles of Thread.CurrentPrincipal so that it > works in every thread? specific. When you end up on a different thread, you get a different value. You can set it, however, in the new thread, if you can pass it as part of the data given to your callback. -- Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet If replying to the group, please do not mail me too Hello Jon Skeet [C# MVP],
Thus why code below works fine? Threads are different, but Principal is the same class Program { static void Main(string[] args) { string[] rolesArray = { "managers", "executives" }; Thread.CurrentPrincipal = new GenericPrincipal(new GenericIdentity("Bob", "Passport"), rolesArray); Console.WriteLine(AppDomain.GetCurrentThreadId()); Console.WriteLine(Thread.CurrentPrincipal.Identity.Name); Console.WriteLine(Thread.CurrentPrincipal.IsInRole("managers") == true ? "true" : "false"); Thread thread = new Thread(new ThreadStart(Calc)); thread.Start(); } private static void Calc() { Console.WriteLine(Thread.CurrentPrincipal.Identity.Name); Console.WriteLine(AppDomain.GetCurrentThreadId()); Console.WriteLine(Thread.CurrentPrincipal.IsInRole("managers") == true ? "true" : "false"); for (int i = 0; i < 1000; i++) { //Console.WriteLine("."); Thread.Sleep(100); } } } J> Roland Müller <roland.muel***@flad.de> wrote: J> >> we load data asynchron. J> You can't. The point of Thread.CurrentPrincipal is that it's thread->> We have some user roles defined in Thread.CurrentPrincipal! >> But if we want to check using IsInRole in the callback of the >> delegate the roles are empty!! >> >> Is this normal? Is it another thread? >> >> How would you access the Roles of Thread.CurrentPrincipal so that it >> works in every thread? >> J> specific. When you end up on a different thread, you get a different J> value. J> J> You can set it, however, in the new thread, if you can pass it as J> part of the data given to your callback. J> --- WBR, Michael Nemtsev :: blog: http://spaces.msn.com/laflour "At times one remains faithful to a cause only because its opponents do not cease to be insipid." (c) Friedrich Nietzsche Michael Nemtsev <nemt***@msn.com> wrote:
> Thus why code below works fine? Threads are different, but Principal is the <snip>> same Hmm. I have no idea. I suspected that the principal was copied for newly created threads, but it appears to work for QueueUserWorkItem too. Maybe it's okay for *some* kinds of callbacks, but not all. (For instance, does it work with Socket.BeginAccept? No idea.) There must be *something* copying the principal though... I believe that when you start a new thread, the principal is copied when you call Start. I don't know about the other situations though. -- Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet If replying to the group, please do not mail me too Hello Jon Skeet [C# MVP],
I had the same thoughs, but being experimenting a bit with new thread and async calls found nothing strange. Roland need to give more extending source code to determin the reason J> Michael Nemtsev <nemt***@msn.com> wrote: J> >> Thus why code below works fine? Threads are different, but Principal J> <snip>>> is the same >> J> J> Hmm. I have no idea. I suspected that the principal was copied for J> newly created threads, but it appears to work for QueueUserWorkItem J> too. Maybe it's okay for *some* kinds of callbacks, but not all. (For J> instance, does it work with Socket.BeginAccept? No idea.) J> J> There must be *something* copying the principal though... I believe J> that when you start a new thread, the principal is copied when you J> call Start. I don't know about the other situations though. J> --- WBR, Michael Nemtsev :: blog: http://spaces.msn.com/laflour "At times one remains faithful to a cause only because its opponents do not cease to be insipid." (c) Friedrich Nietzsche Situation has changed a bit; this problem does only occur for one website:
There are 2 websites (lets say "A" and "B") based on the same code of a project just with other custominzing etc. Both .net framework 2.0! I deploy the code to the same server but the code exists in 2 seperate directories and 2 IIS webs. So far so good. There is a client component that loads data asynchronly from a webservic e on that server, with SSL encrypted! After the asynchon callback another method uses Thread.CurrentPrincipal to check some roles. (The roles are set after the user logged in to the client component). The problem now is: consuming the webservices in "A" works fine and the check for the roles in Thread.CurrentPrincipal works also in the callback of an asynchron method. But not with "B"! There the roles are emtpy and i don't know why. I have checked nearly everything (web.config, filesystem, iis config etc) but i cannot find a difference. My question on you is: what can cause that the roles are empty/not transmitted during an asynchon method call? Can this be a thing in IIS? Or even a bug in framework? Or some issue with SSL? Michael Nemtsev schrieb: Show quote > Hello Jon Skeet [C# MVP], > > I had the same thoughs, but being experimenting a bit with new thread > and async calls found nothing strange. > > Roland need to give more extending source code to determin the reason > > J> Michael Nemtsev <nemt***@msn.com> wrote: > J> >>> Thus why code below works fine? Threads are different, but Principal >>> is the same >>> > J> <snip> > J> J> Hmm. I have no idea. I suspected that the principal was copied for > J> newly created threads, but it appears to work for QueueUserWorkItem > J> too. Maybe it's okay for *some* kinds of callbacks, but not all. (For > J> instance, does it work with Socket.BeginAccept? No idea.) > J> J> There must be *something* copying the principal though... I believe > J> that when you start a new thread, the principal is copied when you > J> call Start. I don't know about the other situations though. > J> --- > WBR, > Michael Nemtsev :: blog: http://spaces.msn.com/laflour > > "At times one remains faithful to a cause only because its opponents do > not cease to be insipid." (c) Friedrich Nietzsche > > Hello Roland,
U mean that the same code works different in the separate webSites? RM> Situation has changed a bit; this problem does only occur for one RM> website: RM> RM> There are 2 websites (lets say "A" and "B") based on the same code RM> of a RM> project just with other custominzing etc. RM> Both .net framework 2.0! RM> I deploy the code to the same server but the code exists in 2 RM> seperate directories and 2 IIS webs. So far so good. RM> RM> There is a client component that loads data asynchronly from a RM> webservic RM> e on that server, with SSL encrypted! RM> After the asynchon callback another method uses RM> Thread.CurrentPrincipal RM> to check some roles. (The roles are set after the user logged in to RM> the RM> client component). RM> The problem now is: consuming the webservices in "A" works fine and RM> the RM> check for the roles in Thread.CurrentPrincipal works also in the RM> callback of an asynchron method. RM> But not with "B"! There the roles are emtpy and i don't know why. RM> I have checked nearly everything (web.config, filesystem, iis config RM> etc) but i cannot find a difference. RM> My question on you is: what can cause that the roles are empty/not RM> transmitted during an asynchon method call? Can this be a thing in RM> IIS? Or even a bug in framework? Or some issue with SSL? RM> RM> Michael Nemtsev schrieb: RM> Show quote >> Hello Jon Skeet [C# MVP], Michael Nemtsev :: blog: http://spaces.msn.com/laflour>> >> I had the same thoughs, but being experimenting a bit with new thread >> and async calls found nothing strange. >> >> Roland need to give more extending source code to determin the reason >> >> J> Michael Nemtsev <nemt***@msn.com> wrote: >> J> >>>> Thus why code below works fine? Threads are different, but >>>> Principal is the same >>>> >> J> <snip> >> J> J> Hmm. I have no idea. I suspected that the principal was copied >> for >> J> newly created threads, but it appears to work for >> QueueUserWorkItem >> J> too. Maybe it's okay for *some* kinds of callbacks, but not all. >> (For >> J> instance, does it work with Socket.BeginAccept? No idea.) >> J> J> There must be *something* copying the principal though... I >> believe >> J> that when you start a new thread, the principal is copied when you >> J> call Start. I don't know about the other situations though. >> J> --- >> WBR, >> Michael Nemtsev :: blog: http://spaces.msn.com/laflour >> "At times one remains faithful to a cause only because its opponents >> do not cease to be insipid." (c) Friedrich Nietzsche >> --- WBR, "At times one remains faithful to a cause only because its opponents do not cease to be insipid." (c) Friedrich Nietzsche Hi Michael,
i did think so but the problem was another: Before we set the roles in Thread.CurrentPrincipal we had on that "problem website" another asynchron webservice call. This webservice call isn't called on the other website ("A"). So there is a callback with empty roles!!! That "reset" the roles. The solution was to set the roles in Thread.CurrentPrincipal before any asynchron webservice calls! Michael Nemtsev schrieb: Show quote > Hello Roland, > > U mean that the same code works different in the separate webSites? > > RM> Situation has changed a bit; this problem does only occur for one > RM> website: > RM> RM> There are 2 websites (lets say "A" and "B") based on the same code > RM> of a > RM> project just with other custominzing etc. > RM> Both .net framework 2.0! > RM> I deploy the code to the same server but the code exists in 2 > RM> seperate directories and 2 IIS webs. So far so good. > RM> RM> There is a client component that loads data asynchronly from a > RM> webservic > RM> e on that server, with SSL encrypted! > RM> After the asynchon callback another method uses > RM> Thread.CurrentPrincipal > RM> to check some roles. (The roles are set after the user logged in to > RM> the > RM> client component). > RM> The problem now is: consuming the webservices in "A" works fine and > RM> the > RM> check for the roles in Thread.CurrentPrincipal works also in the > RM> callback of an asynchron method. > RM> But not with "B"! There the roles are emtpy and i don't know why. > RM> I have checked nearly everything (web.config, filesystem, iis config > RM> etc) but i cannot find a difference. > RM> My question on you is: what can cause that the roles are empty/not > RM> transmitted during an asynchon method call? Can this be a thing in > RM> IIS? Or even a bug in framework? Or some issue with SSL? > RM> RM> Michael Nemtsev schrieb: > RM> >>> Hello Jon Skeet [C# MVP], >>> >>> I had the same thoughs, but being experimenting a bit with new thread >>> and async calls found nothing strange. >>> >>> Roland need to give more extending source code to determin the reason >>> >>> J> Michael Nemtsev <nemt***@msn.com> wrote: >>> J> >>>>> Thus why code below works fine? Threads are different, but >>>>> Principal is the same >>>>> >>> J> <snip> >>> J> J> Hmm. I have no idea. I suspected that the principal was copied >>> for >>> J> newly created threads, but it appears to work for >>> QueueUserWorkItem >>> J> too. Maybe it's okay for *some* kinds of callbacks, but not all. >>> (For >>> J> instance, does it work with Socket.BeginAccept? No idea.) >>> J> J> There must be *something* copying the principal though... I >>> believe >>> J> that when you start a new thread, the principal is copied when you >>> J> call Start. I don't know about the other situations though. >>> J> --- >>> WBR, >>> Michael Nemtsev :: blog: http://spaces.msn.com/laflour >>> "At times one remains faithful to a cause only because its opponents >>> do not cease to be insipid." (c) Friedrich Nietzsche >>> > --- > WBR, > Michael Nemtsev :: blog: http://spaces.msn.com/laflour > > "At times one remains faithful to a cause only because its opponents do > not cease to be insipid." (c) Friedrich Nietzsche > >  |
|||||||||||||||||||||||
Other interesting topics