I am new to unit testing and I am trying to test some of my .NET membership stuff I been writing.
So I am trying to check my VerifyUser method that checks if the users credentials are valid or not.
So this is what it looks like:
public bool VerifyUser(string userName, string password)
{
bool valid = Membership.ValidateUser(userName, password);
return valid;
}
And now every time I run my unit test it fails. I know I am passing in the right credentials and stuff. Then it dawned on me that maybe my Test Project(that is under the same Solution as my real project) might need its own web.config file with the connection string and stuff. Or an app config file maybe since it is a Application Library project.
So do I just copy the web.config file from my real project and call it a day? Or should I only be taking parts from it? Or am I just way off.
My database is using a custom database with the .net membership merged with my database. So in my config file I had to specify a ManagerProvider and a roleProvider.
This is how my unit test looks like
[Test]
public void TestVerifyUser()
{
AuthenticateUser authenitcate = new AuthenticateUser();
bool vaild = authenitcate.VerifyUser("chobo3", "1234567");
Assert.That(vaild, Is.True);
}
Also later on I have in one of my asp.net mvc ActionResult Methods(the Login View to be exact) I have this:
FormsAuthentication.RedirectFromLoginPage(loginValidation.UserName, rememberMe);
So now how can I write a unit test that would do what a user would do. Say they start at the Home page then click on the login page and log in successfully. I want them to be redirect to the home page.
I am not sure how to represent that in code. I am pretty sure that the RedirectFromLoginPage works and thats now what I am really testing. I am testing the fact that I have 3 things that can happen in the login ActionResult method.
User logs in and gets sent back where they came from.
User fails to login and gets sent back to the LoginView and sees error messages.
User has tried to go to a secure and has been redirect to the login page. If the login successfully the will be redirect back to the secure page via the ReturnUrl.
So I want to do a test to see if these work as they should. So thats why I need to have the user coming from like the home page to see if they get redirected back to it later and if they come from a secure page they get redirect back to that later on.
I am also by the way using NUnit 2.5 and VS2008 Pro.
This is what I am trying to test. I am at the part where I am trying to see if the user is valid or not(the if statement). I have no clue how to test it.
public ActionResult Login(string returnUrl, FormCollection form, bool rememberMe)
{
LoginValidation loginValidation = new LoginValidation();
try
{
UpdateModel(loginValidation, form.ToValueProvider());
}
catch
{
return View("Login");
}
if (ModelState.IsValid == true)
{
bool valid = authenticate.VerifyUser(loginValidation.UserName, loginValidation.Password);
if (valid == false)
{
ModelState.AddModelError("frm_Login", "Either the Password or UserName is invalid");
}
else if (string.IsNullOrEmpty(returnUrl) == false)
{
/* if the user has been sent away from a page that requires them to login and they do
* login then redirect them back to this area*/
return Redirect(returnUrl);
}
else
{
FormsAuthentication.RedirectFromLoginPage(loginValidation.UserName, rememberMe);
}
}
return View("Login");
}
You can test your controllers and much of your custom provider by refactoring your custom membership code into a two layers: a data access repository that only interacts with the database, and a service layer that uses repository components to provide the Membership API. The service layer is where you would validate arguments, hold and enforce parameters like EnablePasswordReset and translate any database exceptions or status codes into a form suitable for controller consumption.
When you specify each layer with its own interface, consumers can write to that interface regardless of how its implemented. When your app is running your provider is of course talking to the database through these interfaces but for testing you can mock the repository or service interfaces. You can test your service layer by mocking the repository level without have to mess with the database or the web.config file, and you can test your controllers by mocking the service layer. If you don't want to refactor the whole provider, you can still test your controllers if you only create the service interface and have your controllers use it.
To be specific, if a little verbose, your repository and service interfaces might look something like:
namespace Domain.Abstract {
public interface IRepository {
string ConnectionString { get; }
}
}
namespace Domain.Abstract {
public interface IUserRepository : IRepository {
MembershipUser CreateUser(Guid userId, string userName, string password, PasswordFormat passwordFormat, string passwordSalt,
string email, string passwordQuestion, string passwordAnswer, bool isApproved,
DateTime currentTimeUtc, bool uniqueEmail);
MembershipUser GetUser(Guid userId, bool updateLastActivity, DateTime currentTimeUtc);
PasswordData GetPasswordData(Guid userId, bool updateLastLoginActivity, DateTime currentTimeUtc);
void UpdatePasswordStatus(Guid userId, bool isAuthenticated, int maxInvalidPasswordAttempts, int passwordAttemptWindow,
DateTime currentTimeUtc, bool updateLastLoginActivity, DateTime lastLoginDate, DateTime lastActivityDate);
//....
}
}
namespace Domain.Abstract {
public interface IUserService {
bool EnablePasswordRetrieval { get; }
bool EnablePasswordReset { get; }
bool RequiresQuestionAndAnswer { get; }
bool RequiresUniqueEmail { get; }
//....
MembershipUser CreateUser(string applicationName, string userName, string password, string email, string passwordQuestion, string passwordAnswer, bool isApproved);
MembershipUser GetUser(Guid userId, bool userIsOnline);
bool ValidateUser(Guid userId, string password);
//...
}
}
namespace Domain.Concrete {
public class UserService : IUserService {
private IUserRepository _userRepository;
public UserService(IUserRepository userRepository) {
_userRepository = userRepository;
}
//...
public bool ValidateUser(Guid userId, string password) {
// validate applicationName and password here
bool ret = false;
try {
PasswordData passwordData;
ret = CheckPassword(userId, true, true, DateTime.UtcNow, out passwordData);
}
catch (ObjectLockedException e) {
throw new RulesException("userName", Resource.User_AccountLockOut);
}
return ret;
}
private bool CheckPassword(Guid userId, string password, bool updateLastLoginActivityDate, bool failIfNotApproved,
DateTime currentTimeUtc, out PasswordData passwordData) {
passwordData = _userRepository.GetPasswordData(userId, updateLastLoginActivityDate, currentTimeUtc);
if (!passwordData.IsApproved && failIfNotApproved)
return false;
string encodedPassword = EncodePassword(password, passwordData.PasswordFormat, passwordData.PasswordSalt);
bool isAuthenticated = passwordData.Password.Equals(encodedPassword);
if (isAuthenticated && passwordData.FailedPasswordAttemptCount == 0 && passwordData.FailedPasswordAnswerAttemptCount == 0)
return true;
_userRepository.UpdatePasswordStatus(userId, isAuthenticated, _maxInvalidPasswordAttempts, _passwordAttemptWindow,
currentTimeUtc, updateLastLoginActivityDate,
isAuthenticated ? currentTimeUtc : passwordData.LastLoginDate,
isAuthenticated ? currentTimeUtc : passwordData.LastActivityDate);
return isAuthenticated;
}
}
The Asp.Net Membership system is designed to work in the context of an Asp.Net request. So, you have three options here.
Most people when faced with such a dependency would write a thin wrapper around it. The wrapper doesn't do anything, just redirects all calls to the underlying dependency. So, they just don't test it. Your AuthenticateUser is such a wrapper. You should probably make all methods virtual or extract an interface in order to make it mockable, but that's another story.
Use TypeMock Isolator and mock Membership.
Use the Ivonna framework and run your test in the Asp.Net context (that would be an integration test).
Unfortunately you can't just copy your web.config or your app.config and have it work that way. The reason is that your assembly is running inside of the NUnit process, not under your application.
To remedy your situation, you're probably going to have to Mock or Stub the Membership members you're calling, or follow a Convention over Configuration approach to the settings you have stored in your web.config.
There are many mocking frameworks out there, but here are a couple: Rhino Mocks, Moq
Also, to follow the Convention over Configuration approach, you could do something like this:
static ConfigurationSettings
{
static String SomeSetting
{
get
{
var result = "HARDCODEDVALUE";
if (ConfigurationManager.AppSettings["SOMEKEY"] != null)
result = ConfigurationManager.AppSettings["SOMEKEY"];
return result;
}
}
You could then use this code like this:
//this is how the old code might look
var mySetting = ConfigurationManager.AppSettings["SOMEKEY"];
//use the setting
//this is how the new code would look
var mySetting = ConfigurationSettings.SomeSetting;
//use the setting
This way your test will work, and when you run it under your application it will use whatever configuration settings you've stored.
Related
I am migrating users from a legacy user store to ASP.NET Identity 2.0 in my ASP.NET 5.0 web application. I have a means of verifying legacy hashes, but I want to upgrade them at login-time to ASP.NET Identity 2.0 hashes.
I've created a custom IPasswordHasher that is able to detect and verify legacy hashes, and return PasswordVerificationResult.SuccessRehashNeeded at the appropriate time. (If it detects that the hash is not legacy, it simply falls through to the built-in ASP.NET Identity hash verification.)
However, returning PasswordVerificationResult.SuccessRehashNeeded doesn't seem to cause ASP.NET Identity to actually do anything. Is there a configuration option somewhere that would cause the system to re-hash the passwords when IPasswordHasher returns this result?
If the answer is no to the above, then is it recommended that I simply re-hash and update the user manually? Where would I do this? I don't see any place at the controller level where I can see the PasswordVerificationResult.
I'm new to ASP.NET Identity so I'm sure I'm missing something simple. Thank you in advance for any pointers.
It seems rehashing mechanism is not implemented in the built-in user manager. But hopefully you could easily implemented. consider this:
public class ApplicationUserManager : UserManager<ApplicationUser>
{
protected override async Task<bool> VerifyPasswordAsync(
IUserPasswordStore<ApplicationUser, string> store,
ApplicationUser user, string password)
{
var hash = await store.GetPasswordHashAsync(user);
var verifyRes = PasswordHasher.VerifyHashedPassword(hash, password);
if (verifyRes == PasswordVerificationResult.SuccessRehashNeeded)
await store.SetPasswordHashAsync(user, PasswordHasher.HashPassword(password));
return verifyRes != PasswordVerificationResult.Failed;
}
}
If you have implemented IPasswordHasher correctly, when returning a PasswordVerificationResult.SuccessRehashNeeded result, ASP.NET Core Identity will call the HashPassword method automatically for you, successfully authenticating the user and updating the hash in the database.
The class would look something like this:
public class PasswordHasherWithOldHashingSupport : IPasswordHasher<ApplicationUser>
{
private readonly IPasswordHasher<ApplicationUser> _identityPasswordHasher;
public PasswordHasherWithOldHashingSupport()
{
_identityPasswordHasher = new PasswordHasher<ApplicationUser>();
}
public string HashPassword(ApplicationUser user, string password)
{
return _identityPasswordHasher.HashPassword(user, password);
}
public PasswordVerificationResult VerifyHashedPassword(ApplicationUser user, string hashedPassword, string providedPassword)
{
var passwordVerificationResult = _identityPasswordHasher.VerifyHashedPassword(user, hashedPassword, providedPassword);
if (passwordVerificationResult == PasswordVerificationResult.Failed)
{
/* Do your custom verification logic and if successful, return PasswordVerificationResult.SuccessRehashNeeded */
passwordVerificationResult = PasswordVerificationResult.SuccessRehashNeeded;
}
return passwordVerificationResult;
}
}
I am developing an application on ASP.NET MVC 4. I am using a TDD approach to develop my application. Initially, I am trying to implement a login module for the application. Technically in order to login,it requires to follow these steps:
Verify user account is not locked and its a valid user. (If user attempt to login multiple times, it must lock the account after 5 unsuccessful attempt. To achieve this, I have a LoginAttempt field in my database, that I update after every unsuccessful attempt)
If account is verified, Validate the user with loginId and password using a third party service.
If verified, User must be redirected to Index page.
To achieve these task, I have created:
// Interface, Controller will interact with
public Interface IAuthenticate
{
bool ValidateUser(string UserId,string Password);
}
// Class that implement IAuthenticate
public class Authenticate : IAuthenticate
{
private IVerifyUser loginVerify;
private IThirdPartyService thirdpartyService;
public Authenticate(IVerifyUser user,IThirdPartyService thirdparty)
{
this.loginVerify=user;
this.thirdpartyService=thirdparty;
}
public bool ValidateUser(string userId,string password)
{
if(loginVerify.Verify(userId))
{
if(thirdpartyService.Validate(userId,password))
return true;
else
return false;
}
else
return false;
}
}
To test my controller Login, DO I have to just create a mock for IAuthenticate or do I have to create mock for IVerifyUser and IThirdPartyService ??
[TestMethod]
public void Login_Rerturn_Error_If_UserId_Is_Incorrect()
{
Mock<IAuthenticate> mock1 = new Mock<IAuthenticate>();
mock1.Setup(x => x.ValidateUser("UserIdTest", "PasswordTest"))
.Returns(false);
var results = controller.Login();
var redirect = results as RedirectToRouteResult;
Assert.IsNotNull(results);
Assert.IsInstanceOfType(results, typeof(RedirectToRouteResult));
controller.ViewData.ModelState.AssertErrorMessage("Provider", "User Id and Password is incorrect");
Assert.AreEqual("Index", redirect.RouteValues["action"], "Wrong action");
Assert.AreEqual("Home", redirect.RouteValues["controller"], "Wrong controller");
}
If you're testing your controller and your controller has a dependency on an instance of IAuthenticate then that is all your have to mock. By mocking it, you are disregarding any actual implementation within it. You are only testing the behaviour of the controller given the end behaviour occuring using IAuthenticate.
In your unit tests tests for your implementation of IAuthenticate you would then mock its dependencies (IVerifyUser and IThirdPartyService) to test how it behaves given a certain end result from either of their methods.
If you need any clarification, please comment! :)
I have MVC5 project and I don't have direct access to user database instead I was provided with web services, for example:
bool register (string username, string password, string email) //password is plain text
bool login (string username, string password)
My problem is that I have no idea how to implement IUserPasswordStore because ASP Identity force me to use Hash while I'm not allowed to store hashed password because this web services will be used not just by me.
My UserStore.cs:
public Task<string> GetPasswordHashAsync(TUser user)
{
//I'm suppose to provide hashed password here, but since I don't have any hashed password stored, I have no idea how to implement this method
string passwordHash = userTable.GetPassword(user.Id);
return Task.FromResult<string>(passwordHash);
}
public Task<bool> HasPasswordAsync(TUser user)
{
var hasPassword = !string.IsNullOrEmpty(userTable.GetPassword(user.Id));
return Task.FromResult<bool>(Boolean.Parse(hasPassword.ToString()));
}
public Task SetPasswordHashAsync(TUser user, string passwordHash)
{
//do nothing since I don't need to hash the password
return Task.FromResult<Object>(null);
}
And I was told not to implement IUserPasswordStore because of this and just either use SignInAsync or override PasswordSignInAsync in SignInManager, this is working fine however I ran into another problem which is I need to lockout user if they failed several login attempt and it is not possible to implement IUserLockoutStore without implement IUserPasswordStore.
Found the answer: I create a new class that implements IPasswordHasher ...
public class CustomPasswordHasher : IPasswordHasher
{
public string HashPassword(string password)
{
return password; //return password as is
}
public PasswordVerificationResult VerifyHashedPassword(
string hashedPassword,
string providedPassword)
{
if (hashedPassword.Equals(providedPassword)) {
return PasswordVerificationResult.Success;
}
return PasswordVerificationResult.Failed;
}
}
... and register it in IdentityConfig:
manager.PasswordHasher = new CustomPasswordHasher();
I have to implement an interface like this:
interface IMembershipWrapper
{
Guid GetUserId();
Guid GetUserId(string username, bool userIsOnline);
bool ValidateUser(string userName, string password);
…
}
against active directory and inject it using Unity.
I might get away with throwing a NotImplementedException exception for certain methods but do you think it is generally possible? What strategy do you recommend?
I understand that I can configure 'active directory asp.net forms authentication' via the web.config as described here. Unfortunately, this is not an option.
This should be completely possible without changing your authentication system in the web.config. Especially if you're using .NET 3.5+. Take a look at System.DirectoryServices.AccountManagement.
To implement GetUserId(string username, bool userIsOnline) you may want to try something like:
public Guid GetUserId(string username, bool userIsOnline) {
using(PrincipalContext pc = new PrincipalContext(ContextType.Domain, "[active directory domain here]")) {
var user = UserPrincipal.FindByIdentity(pc, IdentityType.SamAccountName, username);
if(user != null)
return user.Guid.Value;
else
return null;
}
}
To implement ValidateUser(string userName, string password) use ValidateCredentials() on the PrinicalContext
public bool ValidateUser(string userName, string password) {
using (PrincipalContext pc = new PrincipalContext(ContextType.Domain, "[active directory domain here]"))
{
return pc.ValidateCredentials(userName, password);
}
}
Without more information about your implementation, I'm not sure how to go about implementing GetUserId(), since it seems like you wouldn't have enough information to go to Active Directory with.
Despite the fact that I've been on here for a while, this is my first ever question on SO, so please be gentle with me.
I'm using ASP.NET MVC 3 and I want to create a custom Principal so I can store a bit more info about the current user than is standard thus not have to go to the database too often. It's fairly standard stuff that I'm after. Let's just say email address and user id in the first instance.
I have decided to store the object in the cache as I am aware that it is not advised to store it in the session.
I also don't want to have to keep casting the User object, so I wanted to override the User object in the controller. So I can just go User.UserId and be guaranteed of something.
So I created a custom principal like this:
public class MyPrincipal : IPrincipal
{
public MyPrincipal(IIdentity ident, List<string> roles, string email, Guid userId)
{
this._identity = ident;
this._roles = roles;
this._email = email;
this._userId = userId;
}
IIdentity _identity;
public IIdentity Identity
{
get { return _identity; }
}
private List<string> _roles;
public bool IsInRole(string role)
{
return _roles.Contains(role);
}
private string _email;
public string Email
{
get { return _email; }
}
private Guid _userId;
public Guid UserId
{
get { return _userId; }
}
}
And I have a Base Controller like this:
public class BaseController : Controller
{
protected virtual new MyPrincipal User
{
get
{
if (base.User is MyPrincipal)
{
return base.User as MyPrincipal;
}
else
{
return new MyPrincipal(base.User.Identity, new List<string>(0), "", Guid.Empty );
}
}
}
protected override void OnAuthorization(AuthorizationContext filterContext)
{
if (User != null)
{
if (User.Identity.IsAuthenticated)
{
if (User.Identity is FormsIdentity)
{
FormsIdentity id = base.User.Identity as FormsIdentity;
MyPrincipal principal = (MyPrincipal)filterContext.HttpContext.Cache.Get(id.Name);
if (principal == null)
{
MembershipUser user = Membership.GetUser();
// Create and populate your Principal object with the needed data and Roles.
principal = new MyPrincipal(id, Roles.GetRolesForUser(id.Name).ToList(), user.Email, (Guid)user.ProviderUserKey);
filterContext.HttpContext.Cache.Add(
id.Name,
principal,
null,
System.Web.Caching.Cache.NoAbsoluteExpiration,
new System.TimeSpan(0, 30, 0),
System.Web.Caching.CacheItemPriority.Default,
null);
}
filterContext.HttpContext.User = principal;
System.Threading.Thread.CurrentPrincipal = principal;
base.OnAuthorization(filterContext);
}
}
}
}
}
If you have a look you will quickly realise that if the user has not logged in then any call to the User object will have to run through this bit of code:
return new MyPrincipal(base.User.Identity, new List<string>(0), "", Guid.Empty );
and this feels terribly inefficient to me, although it's only creating empty objects for the missing stuff.
It works fine.
So I guess I want to know if this is actually okay and I should stop being so anal about performance and efficiency, or if my fears are correct, in which case what should I be doing instead? [Please don't say "Getting a life, mate!"]
No - there is nothing specifically wrong with this code from a performance stand point that stands out. PLENTY of objects are creating on the back end in ASP.NET, your single object is a drop in the bucket. Since class instantiation is extremely fast I wouldn't be concerned about it.
Why are you ignoring sessions here? Session information doesn't have expiration dates, so there is no extra check behind the scenes. Unless you are using an out of proc session server, there is no serialization of your object (none with the cache either).
The cache is for every user - so you right a chance (albeit slight) of a code error returning the wrong principal where a cache being per user - does not run the risk of that.
If you want this available for all requests there (not just MVC based) I would consider setting this in Application_PostAuthenticateRequest
This post may be of use. Notice the use of userdata in the authentication ticket.
ASP.NET MVC - Set custom IIdentity or IPrincipal