Asynchronous callback method: Thread.CurrentPrincipal roles empty

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Roland Müller - 08 Mar 2006 12:24 GMT

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

Reply to this Message

Michael Nemtsev - 08 Mar 2006 17:16 GMT

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

Reply to this Message

Roland Müller - 09 Mar 2006 08:19 GMT

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:

> Hello Roland,
>
[quoted text clipped - 16 lines]
> "At times one remains faithful to a cause only because its opponents do
> not cease to be insipid." (c) Friedrich Nietzsche

Reply to this Message

Jon Skeet [C# MVP] - 08 Mar 2006 19:31 GMT

> we load data asynchron.
> We have some user roles defined in Thread.CurrentPrincipal!
[quoted text clipped - 6 lines]
> How would you access the Roles of Thread.CurrentPrincipal so that it
> works in every thread?

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.

Signature

Jon Skeet - <skeet@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

Reply to this Message

Michael Nemtsev - 09 Mar 2006 17:40 GMT

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.mueller@flad.de> wrote:
J>

>> we load data asynchron.
>> We have some user roles defined in Thread.CurrentPrincipal!
[quoted text clipped - 5 lines]
>> How would you access the Roles of Thread.CurrentPrincipal so that it
>> works in every thread?

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

Reply to this Message

Jon Skeet [C# MVP] - 09 Mar 2006 17:54 GMT

> Thus why code below works fine? Threads are different, but Principal is the
> same

<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.

Signature

Jon Skeet - <skeet@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

Reply to this Message

Michael Nemtsev - 09 Mar 2006 18:21 GMT

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 <nemtsev@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

Reply to this Message

Roland Müller - 10 Mar 2006 07:45 GMT

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:

> Hello Jon Skeet [C# MVP],
>
[quoted text clipped - 22 lines]
> "At times one remains faithful to a cause only because its opponents do
> not cease to be insipid." (c) Friedrich Nietzsche

Reply to this Message

Michael Nemtsev - 11 Mar 2006 08:22 GMT

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],
>>
[quoted text clipped - 25 lines]
>> "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

Reply to this Message

Roland Müller - 13 Mar 2006 09:40 GMT

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:

> Hello Roland,
>
[quoted text clipped - 64 lines]
> "At times one remains faithful to a cause only because its opponents do
> not cease to be insipid." (c) Friedrich Nietzsche

Reply to this Message

Asynchronous callback method: Thread.CurrentPrincipal roles empty

Free Magazines