Asynchronous callback method: Thread.CurrentPrincipal roles empty

  • Thread starter Thread starter =?ISO-8859-15?Q?Roland_M=FCller?=
  • Start date Start date
?

=?ISO-8859-15?Q?Roland_M=FCller?=

Hello,

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
 
Roland Müller said:
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?
Click to expand...

You can't. The point of Thread.CurrentPrincipal is that it's 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.
 
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.
 
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> You can't. The point of Thread.CurrentPrincipal is that it's 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 said:
Thus why code below works fine? Threads are different, but Principal is the
same
Click to expand...

<snip>

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.
 
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> <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
 
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 said:
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> <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
Click to expand...
 
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 said:
Thus why code below works fine? Threads are different, but
Principal is the same
Click to expand...
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
Click to expand...
Click to expand...
---
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,

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 said:
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>
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
Click to expand...
Click to expand...
---
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
Click to expand...
 
Back
Top