How to change HttpApplication.User.Identity.Name on a local environment?

Question

I have a site that requires Windows Authentication the application obtains the credential from the Security.Prinicipal once the user is autenticated the problem is that my credentials on my local environment are different that the ones stored in the DB and the user preferences cannot be obtain. i am doing the following workaround in order to deal with this issue.

    #if DEBUG
      var  myUser = userBL.GetSingle(@"desiredDomain\otherUserName");
    #else 
       var myUser = userBL.GetSingle(HttpApplication.User.Identity.Name);
    #endif
     Session.Add("User",myUser);

is there any other way rather than impersonating or the above mentioned workaorund to change the the value of HttpApplication.User.Identity.Name this is beacuse I have to change my code everytime I need to commit into repository or deploy the App

Answer 1

Have you looked into using Impersonation in Web.Config to set the id to your test credentials. I would presume that you have a "test" web.config and a "production" web.config. This way you won't have to worry about removing it when you go live.

Answer 2

I've done this before by wrapping this in a utility method. If HttpContext.Current isn't null, get it from there. Otherwise get it from WindowsIdentity.GetCurrent().

Answer 3

While you could alter userBL, why wouldn't you instead alter the database records to reflect that they're in a different domain. I'm assuming you're not hitting the production database, so there should be no issues with a 'sanitizing' step that makes the database useable for dev/test.

e.g.

UPDATE Users 
SET 
    UserName = REPLACE(UserName, '\\ProductionDomain\', '\\DevDomain\')

1. using #if DEBUG is bad for this sort of thing. Someone could/should legitimately load a debug version of code on production, and all of a sudden logins are broken. These things are better controlled in a web.config when they are needed.
2. Developers should be working against a dev copy of the database. It is very typical to sanitize some aspects of the database when the copy is made. Sometimes this is for privacy regulations (e.g. obscuring users real names and logins)