Method SetThreadPrincipal

17 May 2005 1:55 PM

Oriane

Hi,

after attaching a principal to an AppDomain with SetThreadPrincipal, is it
possible to undo this setting in order to set another principal ?
The method AppDomain.SetThreadPrincipal doesn't accept NULL as an argument,
so what ?

Oriane

17 May 2005 2:16 PM

Nicole Calinoiu

Oriane,

The CurrentPrincipal property of the Thread type may be used for this
purpose. However, the SetThreadPrincipal method of AppDomain, which
specifies the default principal used for new threads, may only be called
once.

HTH,
Nicole

Show quoteHide quote

"Oriane" <Ori***@Guermantes.com> wrote in message
news:%23LXAjguWFHA.2740@TK2MSFTNGP14.phx.gbl...
> Hi,
>
> after attaching a principal to an AppDomain with SetThreadPrincipal, is it
> possible to undo this setting in order to set another principal ?
> The method AppDomain.SetThreadPrincipal doesn't accept NULL as an
> argument,
> so what ?
>
> Oriane
>
>

17 May 2005 2:56 PM

Oriane

Hi Nicole,

"Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message
news:OovqHsuWFHA.2740@TK2MSFTNGP14.phx.gbl...
> Oriane,
>
> The CurrentPrincipal property of the Thread type may be used for this
> purpose.

But if we want to reset all the threads of the thread pool ? Do we have to
use a sort of foreach loop ?

> However, the SetThreadPrincipal method of AppDomain, which
> specifies the default principal used for new threads, may only be called
> once.

By the way, I'm currently modifying my code, and the fact is that after what
appears as minor modifications, it seems that the SetThreadPrincipal doesn't
attach anymore the principal to the the current thread. However no exception
is thrown. I don't really understand...

If you don't have any idea, I will have to extract old files from VSS...:-((

17 May 2005 4:48 PM

Nicole Calinoiu

"Oriane" <Ori***@Guermantes.com> wrote in message
news:%23Xu1uCvWFHA.1468@tk2msftngp13.phx.gbl...
> Hi Nicole,
>
> "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message
> news:OovqHsuWFHA.2740@TK2MSFTNGP14.phx.gbl...
>> Oriane,
>>
>> The CurrentPrincipal property of the Thread type may be used for this
>> purpose.
> But if we want to reset all the threads of the thread pool ?

Why would you want to do this, particularly given that you're probably not
actually using all threads in the pool? Perhaps if you could describe the
scenario in which this principal change is being made, someone might be able
to suggest a better mechanism...

> Do we have to
> use a sort of foreach loop ?

You would need to set the CurrentPrincipal for each active thread before the
next read of the principal against that thread. Looping through the thread
pool (assuming that's even possible, which I suspect is not the case) is
probably not the best way to go about this.

>> However, the SetThreadPrincipal method of AppDomain, which
>> specifies the default principal used for new threads, may only be called
>> once.
> By the way, I'm currently modifying my code, and the fact is that after
> what
> appears as minor modifications, it seems that the SetThreadPrincipal
> doesn't
> attach anymore the principal to the the current thread. However no
> exception
> is thrown. I don't really understand...
>
> If you don't have any idea, I will have to extract old files from
> VSS...:-((

No idea why this might be happening. However, you might want to run a
differences verification against the old versions in VSS before you resort
to rolling back since the relevant change is presumably somewhere in the
difference set...

Show quoteHide quote

>
>

17 May 2005 4:59 PM

Oriane

> Why would you want to do this, particularly given that you're probably not
> actually using all threads in the pool? Perhaps if you could describe the
> scenario in which this principal change is being made, someone might be
able
> to suggest a better mechanism...

It's very simple indeed. An applicative user logs in on my application,
which has of course many threads, and I use the .NET mechanism for the .NET
role based security, base on a generic principal, that I set with
SetThreadPrincipal. It seemed to me that it was the "canonical" process.

A user may want to log out. I agree that a logout could be seen as en
applicatin exit. But the people from the business layer ask me for a logout
function.

Anyway if this is impossible, I suppose this is for good reasons and I don't
want to waste my time trying to bypass the standard mechanism.

Thanks a lot

17 May 2005 6:16 PM

Nicole Calinoiu

I'm guessing that there's probably no reason for more than one thread to be
running after the user logs off since the applicaiton is presumably just
sitting around waiting for another user to log in. If I'm right about this,
your best bet may simply be to explicitly set the principal for each thread
as you initialize it in your code. If there's some additional requirement
that would make this impractical, could you please explain?

Show quoteHide quote

"Oriane" <Ori***@Guermantes.com> wrote in message
news:e7c%23PHwWFHA.3324@TK2MSFTNGP09.phx.gbl...
>> Why would you want to do this, particularly given that you're probably
>> not
>> actually using all threads in the pool? Perhaps if you could describe
>> the
>> scenario in which this principal change is being made, someone might be
> able
>> to suggest a better mechanism...
> It's very simple indeed. An applicative user logs in on my application,
> which has of course many threads, and I use the .NET mechanism for the
> .NET
> role based security, base on a generic principal, that I set with
> SetThreadPrincipal. It seemed to me that it was the "canonical" process.
>
> A user may want to log out. I agree that a logout could be seen as en
> applicatin exit. But the people from the business layer ask me for a
> logout
> function.
>
> Anyway if this is impossible, I suppose this is for good reasons and I
> don't
> want to waste my time trying to bypass the standard mechanism.
>
> Thanks a lot
>
>

18 May 2005 7:44 AM

Oriane

Hi Nicole,

we finaly agree that the log out functionnality was not required.

Thank you

"Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message
news:uE1%23gywWFHA.1148@tk2msftngp13.phx.gbl...
> I'm guessing that there's probably no reason for more than one thread to
be
> running after the user logs off since the applicaiton is presumably just
> sitting around waiting for another user to log in. If I'm right about
this,
> your best bet may simply be to explicitly set the principal for each
thread
> as you initialize it in your code. If there's some additional requirement
> that would make this impractical, could you please explain?

This would have been the best solution.