In A Simple Custom Sql Membership Provider Part 1, I talked about how to create a new Sql Membership Provider in order to modify the behavior of the default provider, without having to write your own provider from scratch.
In this part, I'll show you how to further extend the provider to give the appearance of case-insensitivity for passwords. Please note, when passwords are configured to be hashed (not retrievable), you cannot provide true case-insensitivity.
To provide the desired behavior, we can essentially force all passwords to lowercase. We need to do this when they are set initially, when they are reset, when they are changed, and when they are validated during login. Any gaps in this logic may result in the inability to login.
Here is the code to do this...
private bool CaseSensitive;
string CaseSensitiveConfig = config["caseSensitive"];
if (CaseSensitiveConfig != null)
{
// Have to remove the config entry as the provider we are
// inheriting from doesn't understand it and will throw an
// exception
config.Remove("caseSensitive");
if (!bool.TryParse(CaseSensitiveConfig, out CaseSensitive))
{
// Have to reset to default as TryParse will set it to
// false if the value can't be parsed
CaseSensitive = true;
}
}
else
{
// Default to case sensitive
CaseSensitive = true;
}
#region Override Password logic for case-insensitive functionality
//Override the default logic for creating users, changing passwords,
//and logging in; in order to give the effect of case-insensitivity.
// For every call that uses password, force the user input to lower case
//as well.
//Although this is configurable via the provider's configuration
//section, this setting should not be changed after users have been
//live on the system. If any passwords get into the system with
//upper case characters, that user will be unable to login.
public override bool ChangePassword(string username,
string oldPassword, string newPassword)
{
if (!CaseSensitive)
{
oldPassword = oldPassword.ToLower();
newPassword = newPassword.ToLower();
}
return base.ChangePassword(username, oldPassword,
newPassword);
}
public override MembershipUser CreateUser(string username,
string password, string email, string passwordQuestion,
string passwordAnswer, bool isApproved, object providerUserKey,
out MembershipCreateStatus status)
{
if (!CaseSensitive)
{
password = password.ToLower();
}
return base.CreateUser(username, password, email, passwordQuestion,
passwordAnswer, isApproved, providerUserKey, out status);
}
public override bool ValidateUser(string username, string password)
{
if (!CaseSensitive)
{
password = password.ToLower();
}
return base.ValidateUser(username, password);
}
#endregion
I want to discuss a concept I first read about when going through the
"Pragmatic Programmer" book. By the way this is an awesome book I
recommend for every programmer. The book has tons of nuggets of helpful
tidbits that every developer will find useful.
The term Design By Contract (DBC) is a term coined by Bertrand Meyer in
connection with the Eiffel programming language but can be applied to any object oriented programming language including .NET. although not
as elegantly as Eiffel since DBC is built right into that language. It
is a technique that focuses on documenting and agreeing to the rights
and responsibilities of software modules to ensure program correctness
- doing no more or no less than a program claims to do. The
documentation and verification is at the heart of Design by Contract.
Every method has some functionality. The method may have some
expectation of the state of the world before it is called as well as
make some conclusion about the state of the world after being called.
The 3 components of DBC is as follows:
Preconditions: These must be true in order by the routine to be
called: These form the conditions or obligations to be guaranteed on
entry by any client module that calls the method. A routine should thus
never be called when its preconditions would be violated. It is the
caller's responsibility to pass good data or set the conditions
required before calling the routine.
Post Conditions: This describes what the routine is guaranteed to
do and this describes the state of the world when the routine is done.
This in essence describes what the callee is expected to do and what
the caller should expect after calling the routine.
Class Invariants: A class ensures that this condition is always
true from the perspective of the caller. While processing the routine,
this invariant may temporarily not hold, but by the time the routine
exits and returns control, the invariant must be true.
The contract between a routine and any potential caller can thus be read thus:
If
all the routine's preconditions are met by the caller, the routine
shall guarantee that all post conditions and invariants will be true
when it completes.
Below is a DBC example of a routine that inserts a data value into a unique ordered list. In the example below:
public void insertNode(Node aNode)
The precondition might be that it does not already contain aNode i.e. Contains(aNode) == false;
Post condition might be that it will contain aNode i.e. Contains(aNode) == true;
The invariant could be
foreach( Node n in nodes)
if ( node.Prev() != null ) {
Implies that ( n.value CompareTo (n.Prev().value) > 0 )
A failure of the precondition indicates a bug in the caller,
the client. A failure of the postcondition indicates a bug in the
routine, the supplier. These conditions, or specifications, are
implemented by assertion statements. In C/C++ code the assert macro is
used for these purposes. The .NET Framework Class Library uses
assertion functions available in the System.Diagnostics namespace. By
default these generate an "abort, ignore, retry" message box on
assertion failure. These assertions should not have side effects.
Unlike Effiel which has DBC built into the language, C# implements DBC via assertions or exception handling.
The
library provides a set of static methods for defining preconditions,
postconditions, class invariants and general assertions and the
exception classes that represent them. Methods are also provided that
invoke the .NET System.Diagnostics.Trace() assertions as an
alternative to throwing exceptions.
The implementation of the DBC for C# could be such.
public void insertNode( Node aNode) {
// precondition
Trace.Assert( nodes.Contains(aNode) == false )
... code logic to insert the node into the list in a unique ordered fashion
// post condition
Trace.Assert( nodes.Contains(aNode) == true )
}
The invariant can be tested by the caller of the routine.
foreach( Node n in nodes) {
if ( node.Prev() != null ) {
Trace.Assert ( n.value.CompareTo (n.Prev().value) > 0 )
}
}
If
either party fails to live up to the terms of the contract then a
remedy ( which was previously agreed to ) is invoked - an exception is
raised or the program terminates for instance.