views:

284

answers:

2

Maybe I'm mis-remembering how Winforms works or I'm overcomplicating the hell out of this, but here's my problem.

I have a WPF client app application that talks to a server over WCF. The current user may "log out" of the WPF client, which closes all open screens, leaves only the navigation pane, and minimizes the program window. When the user re-maximizes the program window, they are prompted to log in. Simple.

But sometimes things happen on background threads - like every 5 minutes the client tries to make a WCF calls that refreshes some cached data. And what if the user is logged out when this 5 minute timer triggers? Well, then the user should be prompted to log back in...and this must of course happen on the UI thread.

    private static ISecurityContext securityContext;
    public static ISecurityContext SecurityContext
    {
        get
        {
            if (securityContext == null)
            {
                // Login method shows a window and prompts the user to log in
                Application.Current.Dispatcher.Invoke((Action)Login); 
            }
            return securityContext;
        }
    }

    private static void Login()
    {
       if (securityContext == null) { \
         /* show login window and set securityContext */ 
         var w = new LoginWindow();
         w.ShowDialog();
         securityContext = w.GetSecurityContext();
       }
    }

So far so good, right? But what happens when multiple threads hit this spot of code?

Well, my first intuition was that since I'm syncrhonizing across the Application.Current.Dispatcher, I should be fine, and whichever thread hit first would be responsible for showing the login form and getting the user logged in...

Not the case...

  1. Thread 1 will hit the code and call ShowDialog on the login form

  2. Thread 2 will also hit the code and will call Login as soon as Thread 1 has called ShowDialog, since calling ShowDialog unblocked Thread 1 (I believe because of the way the WPF message pump works)

...the end effect being that I have multiple login forms popped up to the user at once.

All I want is a synchronized way of getting the user logged back into the application...what am I missing here?

Thanks in advance.

+1  A: 

Perhaps a little locking?

You can monitor the entries and perhaps ignore (not block) the other polling actions. Use the single entry point to display the login form only once and wait...

http://msdn.microsoft.com/en-us/library/system.threading.readerwriterlockslim.aspx

Also, consider caching the users credentials rather than re-prompting them, e.g. SecureString:

http://msdn.microsoft.com/en-us/library/system.security.securestring.aspx

PK :-)

Paul Kohler
to add a little more detail to Paul's answer, I believe he's saying you should lock securityContext. This way, once one thread has accessed and modified securityContext (presumably, logged in), then the other following threads will not pop up the login dialog since securityContext will have been set by the time they get access.
Dave
Good point. I should have mentioned I tried that....so consider the following please: 1. A background thread comes in and invokes onto the Application Dispatcher thread, while locking a securityContextLock object. 2. The user clicks to maximize the application and the real UI thread comes in and tries to get at the securityContext...but it's locked....so the entire UI thread freezes...and even thought guy in step 1 managed to show the login form, the UI thread is frozen and the user can't interact with the login form. So we have a deadlock.
JeffN825
I should also mention that ignoring instead of blocking isn't an option, becuase any thread that's asking for the securityContext will need it immediately in order to create the WCF channel credentials.
JeffN825
Perhaps only display the login from the background process if the application is "active"?
Paul Kohler
But this doesn't accomplish the goal of prompting the user to log back in...or am I misunderstanding?
JeffN825
I would use the lock to ensure that threads are not blocked. My reasoning behind not prompting for login if inactive is that the app is not being used at that time any way (a lot of assumptions there ok!) The other suggestion I was going to make was caching the credentials via http://msdn.microsoft.com/en-us/library/system.security.securestring.aspx for example.
Paul Kohler
+1  A: 

Sorry for the delayed follow-up.

I fixed the blocking problem a few days ago on the UI thread by basically implementing DoEvents for WPF: http://khason.net/blog/how-to-doevents-in-wpf/

So now, many threads, both background and UI can invoke onto the UI thread, and if the window is already shown, will "emulate" the behavior of ShowDialog, but not block and not show a second Login window... Hope that makes sense to anyone reading.

void ShowLoginWindow(Window window) 
          {
                if (window != null )
                {
                    if (window.Visibility != Visibility.Visible)
                    {
                        try
                        {
                            result = window.ShowDialog();
                        }
                        catch (Exception ex)
                        {
                        }
                    }
                    else
                    {
                        // don't block the UI thread, but wait till the dialog window returns 
                        while(window.Visibilit y== Visibility.Visible)
                        {
                            DoEvents();
                        }
                        return window.DialogResult;
                    }
                }
                return result;
        }

        void DoEvents()
        {
            DispatcherFrame f = new DispatcherFrame();
            Dispatcher.CurrentDispatcher.BeginInvoke(DispatcherPriority.Background,
            (SendOrPostCallback)delegate(object arg)
            {
                DispatcherFrame fr = arg as DispatcherFrame;
                fr.Continue = false;
            }, f);
            Dispatcher.PushFrame(f);
        }
JeffN825