I have a WPF application using the latest CSLA 3.5
When I first log in and open a form the principal settings are correctly set for the user.
HOWEVER when I next open a form the credentials are not on the same thread and the UI acts as if I am not authentiacated and they are reset in DataPortal_DataPortalInitInvoke.
HOWEVER if I save an item that does not check to see if I can save, the credentials from that point forward are reporting the correct user.
I do have AddHandler Csla.DataPortal.DataPortalInitInvoke, AddressOf DataPortal_DataPortalInitInvoke in the constructor of the main window's constructor as well the approproate method.
Putting a stop in DataPortal_DataPortalInitInvoke shows the principal has to be reset each time UNTIL THE FIRST SAVE then it is retained (AKA executing on the same thread)
Any help would be appreciated
The only solution I've found is the one in the 3.0 ebook -
Ugly and hacky, but WPF explicitly clears the principal following some arcane (and apparently intentional, and even worse seemingly undocumented) rules. The WPF team told me this was intentional and somehow enhances security - but it seems totally messed up to me... Honestly it makes no sense to me at all - but it is what it is...
However, if you allow the multi-threaded nature of using a data provider to enter the picture then it makes some sense. I still don't know why they clear the main thread - but data providers loading data on a worker thread is a known issue - the worker thread needs your principal and doesn't have it - so the DP_DPInitInvoke can be used to set the principal on that thread.
Thanks for the reply
I was using the model you had from your 3.0 which was still loosing it somehow. I was setting the principle, as you described and illustrated, in the Main window. This exhibited the behavior I described, which still "misplaced" the thread until the first save is successful.
My solution was to take the login/out functionality out of the main window and into a user control which updated the shared/static filed on the Main window. This seems to address the issue.
The question still remains WHY
On another note, I have been an avid reader and "implementor" of your framework since (are I say) VB6 and it keeps getting better!
This stuff is great and makes developement of serious applications interesting and profitable.
Thanks for everything you have contrubuted to th ecommunity
Rocky,
I have found that if you set the principle on the AppDomain i.e.
AppDomain.CurrentDomain.SetThreadPrincipal(principal);
You can avoid this bug. Do you see any issues with doing it that way?
Thanks,
Brette
SetThreadPrincipal() has some consequences.
It controls the principal set on threads created from that point forward. And it can only be called once per AppDomain lifetime.
So if your user must log in before doing anything in the app. And if logging out occurs by shutting down the app. Then this is a good answer.
However, if your user can interact with the app (possibly creating threads in the threadpool) before logging in, then those threads wouldn't get the right principal.
Or if your user can log out and another user log in while the app is running, then this approach won't work.
So yes, it is a good answer for some apps, but it is not a general solution.
Copyright (c) Marimer LLC