I am having an issue with the GenericPrincipal popping up when it should not. Heres the scenario:
I log in like normal (using MyCustomPrincipal and MyCustomIdentity). Authentication works and I set the Csla.ApplicationContext.User accoringly. Everything is good. As soon as I click on anything (actually as soon as another line of code executes), my Csla.ApplicationContext.User is now set to a System.Security.Principal.GenericPrincipal. If I repeat the process, only this when I log in, I IMMEDIATELY log back out, and then log in again. The issue goes away. I have tried analyzing my Login() and Logout() functions but they are fine. The kicker is, the code worked fine with Csla 2.0 but began behaving irregularly when I upgraded to Csla 2.0.1. I have made some minor changes to the framework including implementing TcpChannel as well as a change to allow multiple portals in one application. However, like I said this was working correctly in 2.0. Any ideas? Thanks in advance.
From what I have seen, calling AppDomain.CurrentDomain.SetThreadPrincipal is designed to set the default principal, not the current principal. However, I am calling this on start of my application with a empty MyCustomPrincipal which has now eliminated my casting error from the GenericPrincipal object. However, I am still having the issue with reverting back to the original principal state (now a empty MyCustomPrincipal).
As to your other question, the reason I am even looking at Thread.CurrentPrincipal is because ApplicationContext.User was returning that anyway. I am just trying to find the soure of the problem, which seems at this point to have nothing to do with Csla.
Furthermore, I have been doing some research and the problem I am experiencing seems to be the exact problem that happens on an ASP.NET site when running Cassini, but that is just a guess. Let me further explain the ONLY place my timer is running (also note that I have tried commenting this out to isolate the problem). My timer runs like this:
The StatusBusy object that comes with the ProjectTracker solution I have modified. It can be created as an instance or called via a static method. In the end, both methods create an instace of "StatusBusy" and launch a timer to display a message "Im busy doing something" at the bottom of the screen in a status bar. On timer tick, three seconds or so later, StatusBusy.Dispose() is called and the object is destroyed, unsubscribing timer events and setting the status message back to blank.
When removing that functionality totally, my problem still occurs.
On logout, are you calling SetThreadPrincipal and giving it the GenericPrinpal? If not, new threads will continue to use the custom principal.poindexter12:
From what I have seen, calling AppDomain.CurrentDomain.SetThreadPrincipal is designed to set the default principal, not the current principal. However, I am calling this on start of my application with a empty MyCustomPrincipal which has now eliminated my casting error from the GenericPrincipal object. However, I am still having the issue with reverting back to the original principal state (now a empty MyCustomPrincipal).
As to your other question, the reason I am even looking at Thread.CurrentPrincipal is because ApplicationContext.User was returning that anyway. I am just trying to find the soure of the problem, which seems at this point to have nothing to do with Csla.
Oh, i see. I haven't really studied that code yet in detail (very slowly working through the book).
Furthermore, I have been doing some research and the problem I am experiencing seems to be the exact problem that happens on an ASP.NET site when running Cassini, but that is just a guess.
I'm not familar with that problem; still haven't gotten into an Asp.Net 2.0 project yet. I'll likely start tinkering with it home in my free time (so who knows when ![Wink [;)]](/emoticons/emotion-5.gif)
).
I'm not sure if follow (again, not that far in the book); are you removing the use of a timer at all? If you remove your functionality but still use a timer, its likely the Timer's Elasped event is running from a ThreadPoolThread. If that's the case, it may still use the 'default'. You may have to dispose of and recreate the timer for it to use the new principal.. I'm not sure how the Timer works behind the scenes though. I'm also not sure how SetThreadPrincipal affects ThreadPoolThreads, if this is where the timer is in fact getting its threads.Let me further explain the ONLY place my timer is running (also note that I have tried commenting this out to isolate the problem). My timer runs like this:The StatusBusy object that comes with the ProjectTracker solution I have modified. It can be created as an instance or called via a static method. In the end, both methods create an instace of "StatusBusy" and launch a timer to display a message "Im busy doing something" at the bottom of the screen in a status bar. On timer tick, three seconds or so later, StatusBusy.Dispose() is called and the object is destroyed, unsubscribing timer events and setting the status message back to blank.
When removing that functionality totally, my problem still occurs.
Copyright (c) Marimer LLC