Dialog required in different parts of program - design

Question

I have a dialog, Authentication dialog, that is going to be required in different parts of my application. What would be the best design practice to be able to effeciently call the dialog and the logic behind it (seperate classes) in different points of the program?

EG:

User starts program - login required

User wants to view encrypted data - confirmation of password required

User wants to change password - confirmation of current password required.

So what would be a good way to implement this?

Any suggestions are welcome?

Answer 1

One approach could be to create a "user authenticated" method.

So when ever you need to check that the user is allowed to perform the requested action you make the call:

if (UserAuthenticated())
{
    // Perform action
}

This method would hold details of the user and prompt for the password and check them against the database. If the details match, return true and carry on.

On start up the user name wouldn't be set so the dialog could prompt for that as well.

This is an example of aspect orientated programming or cross-cutting concerns.

Answer 2

Generally speaking, there is no real difference in designing reusable Forms compared to designing any other reusable class - put the classes you want to re-use into one or more assemblies and reference them from the point where you want to reuse them. That works for Forms as well as for any other reusable class.

If you need slightly different functionality of your Form depending on the context you are calling it, you can, for example, write appropriate constructors, or initialize the dialog by appropriate methods before showing it.

Answer 3

Perhaps not the simplest solution to implement, but you could look into using Aspect Oriented Programming. You could then annotate each method which requires user login. This makes the code clean and readable.

[ConfirmUser(ErrorMethod=... RequireUsername=false, RequirePassword=true )]
public void ViewData()
{
   // your code
}

The AOP framework would weave in the required code to handle the user confirmation in your method.

Or do the same thing inside the methods manually:

public void ViewData()
{
  ConfirmUser();
   // your code
}

public void ConfirmUser()
{
   if( !DoLoginPage() ) throw new SecurityException("Incorrect credentials");
}

You could have ConfirmUser return a bool instead of an exception. That's another discussion, and depends on your application. If you deny operations in lower code layers, an exception is the way to go. A try/catch makes you put the error handling at the bottom of the function, while a returning bool requires and if statement at the top.

public void ViewData()
{
  try
  {
     ConfirmUser();
     // your code
  }
  catch( SecurityException )
  {
     //handle error
  }
}

vs

public void ViewData()
{
   if( !ConfirmUser() )
   {
      //handle error
      return;
   }
   // your code
}

You could implement both ConfirmUser and ConfirmPassword, or have both in the same method with a parameter, perhaps an enum to say what you need to verify.

[Flags]
public enum Requires
{
    Username,
    Password
}

public bool ConfirmUser( Requires requiresField )
{
}