I am building a ASP.NET MVC4 Internet website using Visual Studio 2012.
VS2012 generated a template website by default, with SimpleMembership implemented.
The SimpleMembership feature is quite convinient, expect that there is one thing very confusing to me:
For example, I create a user account, with the user name say "Miles", and then login using the name "Miles", everthing is fine. Then I logout and login using the name "miles"(all lower case), the login is also sucessful, however, the user name reads "miles". To be more specific, the value of User.Identity.Name is "miles", instead of "Miles" in the database.
Likewise, I can use "miLes", "mILes", "MILES", etc. to login, and the user name will be the same. The common sense is that if the authentication is case-insensitve, the user name should be exactly the same as the one in database, in my case "Miles", not as what I type in the login textbox.
Does anyone know how to solve this problem? Thanks!
Reason
In your AccountController you probablay see something like this by default:
[HttpPost]
[AllowAnonymous]
[ValidateAntiForgeryToken]
public ActionResult Login(LoginModel model, string returnUrl)
{
if (ModelState.IsValid && WebSecurity.Login(model.UserName, model.Password, persistCookie: model.RememberMe))
{
return RedirectToLocal(returnUrl);
}
// If we got this far, something failed, redisplay form
ModelState.AddModelError("", "The user name or password provided is incorrect.");
return View(model);
}
WebSecurity.Login() is called (passing in the exact string on the model that you typed in your form).
If you look at the source code of WebSecurity.cs you'll see that FormsAuthentication.SetAuthCookie() is called (again, still passing the exact typed string). Before this methods actually sets the cookie in the response, it executes GetAuthCookie(), still passing in the exact string you typed when logging in.
This method actually builds out the authentication HttpCookie object once again using the data you typed in.
Solution
If you need the name to match exactly what's in your database, then you need to query for the record from the database and pass that value into WebSecurity.Login().
Related
When I decorate a method with an Authorize roles attribute it returns false everytime. I'm trying to limit access to an admin page for users in the "Admin" role only.
I have verified that the user im currently logged in as is in fact in the "Admin" role.
I have tried to use a custom authorization attribute. Same result. I can add the code if needed.
I have found that the authorization attribute works for Users but not for Roles.
I believe this problem is somehow tied into the fact that the following does not work in my application:
User.IsInRole("Admin").
However, this statement does work:
userManager.IsInRole(user.Id, "Admin")
Here is my code:
public class AdminController : Controller
{
//[AuthLog(Roles = "Admin")] //Custom authorization attribute
[Authorize(Roles = "Admin")]
public ActionResult Users()
{
return View();
}
}
Maybe this can help with debugging:
Microsoft.AspNet.Identity.Core: V.2.1.0
Microsoft.AspNet.Identity.EntityFramework: V.2.1.0
I am open to suggestions on anything else I can post from my project in order to debug easier. I have scoured the stack for 2 weeks now.
Update 1: How user is logged in
// POST: /account/login
[HttpPost]
[AllowAnonymous]
[ValidateAntiForgeryToken]
public async Task<ActionResult> Login(AccountLoginModel viewModel)
{
// Ensure we have a valid viewModel to work with
if (!ModelState.IsValid)
return View(viewModel);
// Verify if a user exists with the provided identity information
var user = await _manager.FindByEmailAsync(viewModel.Email);
// If a user was found
if (user != null)
{
// Then create an identity for it and sign it in
await SignInAsync(user, viewModel.RememberMe);
// If the user came from a specific page, redirect back to it
return RedirectToLocal(viewModel.ReturnUrl);
}
// No existing user was found that matched the given criteria
ModelState.AddModelError("", "Invalid username or password.");
// If we got this far, something failed, redisplay form
return View(viewModel);
}
private async Task SignInAsync(IdentityUser user, bool isPersistent)
{
// Clear any lingering authencation data
FormsAuthentication.SignOut();
// Create a claims based identity for the current user
var identity = await _manager.CreateIdentityAsync(user, DefaultAuthenticationTypes.ApplicationCookie);
// Write the authentication cookie
FormsAuthentication.SetAuthCookie(identity.Name, isPersistent);
}
The
FormsAuthentication.SetAuthCookie(identity.Name, isPersistent);
unfortunately doesn't store any roles with the identity. Thus, when the identity is recreated from the cookie, you have no roles. To verify try
this.User.IsInRole("Admin")
and you'll get false, even though the userManager tells you otherwise.
There are multiple workarounds.
You could for example switch to any other identity persistor, like the SessionAuthenticationModule which could store your username and roles in the cookie. You could follow my tutorial on that.
Another approach would be to have an explicit role manager and use its feature that automatically causes your roles to be stored in another cookie, separate from the forms authentication cookie. This involves configuring the role provider and writing your own role provider that would be an adapter over the user manager.
Finally, you could forget forms authentication and use Identity's native way of issuing cookies, which would involve calling SignInAsync on the authentication manager.
I'm using the default login module in ASP.NET MVC 4. I did not change any code in the default application and i hosted it on a shared server.
After i logged in using default login page. i kept the browser idle for some time. Then obviously application redirected to the login page when i try to perform any controller action with [Authorize] attribute.
Then i try to login again and it gives an error when i click on login button.
The anti-forgery cookie token and form field token do not match.
LogIn action
// POST: /Account/Login
[HttpPost]
[AllowAnonymous]
[ValidateAntiForgeryToken]
public ActionResult Login(LoginModel model, string returnUrl)
{
if (ModelState.IsValid && WebSecurity.Login(model.UserName, model.Password, persistCookie: model.RememberMe))
{
return RedirectToLocal(returnUrl);
}
// If we got this far, something failed, redisplay form
ModelState.AddModelError("", "The user name or password provided is incorrect.");
return View(model);
}
I resolved the issue by explicitly adding a machine key in web.config.
Note: For security reason don't use this key. Generate one from https://support.microsoft.com/en-us/kb/2915218#AppendixA. Dont use online-one, details, http://blogs.msdn.com/b/webdev/archive/2014/05/07/asp-net-4-5-2-and-enableviewstatemac.aspx
<machineKey validationKey="971E32D270A381E2B5954ECB4762CE401D0DF1608CAC303D527FA3DB5D70FA77667B8CF3153CE1F17C3FAF7839733A77E44000B3D8229E6E58D0C954AC2E796B" decryptionKey="1D5375942DA2B2C949798F272D3026421DDBD231757CA12C794E68E9F8CECA71" validation="SHA1" decryption="AES" />
Here's a site that generates unique Machine Keys:
http://www.developerfusion.com/tools/generatemachinekey/
Another reason for having this error is if you are jumping between [Authorize] areas that are not cached by the browser (this would be done on purpose in order to block users from seeing protected content when they sign out and using the back button for example).
If that's case you can make your actions non cached, so if someone click the back button and ended up on a form with #Html.AntiForgeryToken() the token will not be cached from before.
See this post for how to add [NoCache] ActionFilterAttribute:
How to handle form submission ASP.NET MVC Back button?
make sure you put the #Html.AntiForgeryToken() in your page's form
I had this problem for a long time and assumed it was something wrong with ASP.NET.
In reality, it was the server. I was with WinHost then, and they have a 200MB memory limit. As soon as I had ~20 users on at the same time, my limit was reached. At this point, everyone was logged out and yielded these issues.
For me, this was caused by submitting a form using a button tag. Changing this to an input submit tag resolves the issue.
In My case "We found that the Site cache was enabled and due to this “anti-forgery” token value was not updating every time, after removing this cache
form is submitting."
In my case it was related to multiple cookie values set by domain site and subdomain site.
main.com set __RequestVerificationToken = 1
sub.main.com set __RequestVerificationToken = 2
but when request to sub.main.com was sent it used __RequestVerificationToken = 1 value from main.com
I have a asp.net MVC website that I've recently published on a web hosting service. Almost everything works great, the information that I get from my msSQL db is shown on the pages etc etc. But there's one problem. When I try to log in to my website, it won't work. Before I explain any further, you'll have to take a look at the following code which is how I authenticate a user login:
public ActionResult Login()
{
return View();
}
[HttpPost, ValidateAntiForgeryToken]
public ActionResult Login(LoginModel model)
{
if (ModelState.IsValid)
{
if (Repository.AuthenticateLogin(model.Username, model.Password.GetHashCode().ToString()))
{
FormsAuthentication.SetAuthCookie(model.Username, false);
return RedirectToAction("Index", "Home");
}
else
{
TempData["WrongLogin"] = "The username or password you've entered is wrong. Please try again!";
return View(model);
}
}
else
{
return View(model);
}
}
And the method "AuthenticateLogin(string username, string password) that is used in the if-statement above looks like this:
public static bool AuthenticateLogin(string username, string password)
{
using (var context = new SHultEntities())
{
return (from u in context.User
where u.Username == username && u.Password == password
select u).Any();
}
}
Now, as you can see, to authenticate a user, I am checking the entered username and password against any user in the database's user-table. If there is a match, the method returns "true", or else it returns "false". Yeah, you get it.
Well, the problem is, when I try to log in on my site I get the TempData["WrongLogin"] text, which means my AuthenticateLogin method must've returned false, which means that there must not have been any matches. But when I try this on my local project on my computer, with the same username and password, the AuthenticateLogin returns true.
If the problem was the connection to the database, the headers and contents that I retrieve from my database would not appear on the site. But it does. Also, when I update something from my local project and then go on my website, the updated information appears. So, the only problem is that I can't log in.
This is driving me crazy and I would really appreciate some help.
EDIT: Could be worth mentioning that I have to log in to my website to edit any content/information. That's why I mentioned that I can log in and change from my local project, and then the changes appear on the website.
FOUND PROBLEM: I tried creating a user with a non-hashed password and deleted the .GetHashCode.ToString() from the AuthenticateLogin on the password. Then i re-published. It works. The problem is the hashing.
How can I solve this? I need hashed passwords in the db...
How did you seed the username and password in your database? If the implementation of password.GetHashCode() is machine specific (i.e. relies on a machine specific salt) then this could be why it cannot match against any users. On the other hand if the users were created via the remote (hosted) environment, this should not be a problem.
The problem was caused by my hashing. Apprenatly, two strings that looks exactly the same can produce different values when hashed, with standard framework implementation of .GetHashCode(), on different machines (even though the machines are using the same version of the framework).
For more information, click here!
I Solved my problem by using a customized Hashing-class.
I am using ASP.NET MVC4 SimpleMembership and SimpleRoleProvider to determine authorization before exposing certain methods.
For example:
[Authorize(Roles = "Admin,Corporate")]
public ActionResult Edit(int id = 0)
{
//some code
return View(model)
}
If the user is not in the "Admin" or "Corporate" role (or their session has expired), they are correctly sent to the /Account/Login page.
However, one tester brought up a good point that once on this Login page, there is no hint as to why the user was sent here. If they simply aren't authorized to access the page they are trying to access, they keep logging in again and again and thinking the site is broken.
Ordinarily, I would add a property to the model or pass an optional parameter in the url with a message such as,
You do not have adequate permissions to access that page.
Please log in as an administrator.
or something to that effect. However, because the filter happens before they enter the method, where / how would I add the message?
I have a site where I allow some users to proxy in as an other user. When they do, they should see the entire site as if they where the user they proxy in as. I do this by changing the current user object
internal static void SetProxyUser(int userID)
{
HttpContext.Current.User = GetGenericPrincipal(userID);
}
This code works fine for me.
On the site, to proxy in, the user selects a value in a dropdown that I render in my _layout file as such, so that it appears on all pages.
#Html.Action("SetProxyUsers", "Home")
The SetProxyUsers view looks like this:
#using (#Html.BeginForm("SetProxyUsers", "Home")) {
#Html.DropDownList("ddlProxyUser", (SelectList)ViewBag.ProxyUsers_SelectList, new { onchange = "this.form.submit();" })
}
The controller actions for this looks like this
[HttpGet]
public ActionResult SetProxyUsers()
{
ViewBag.ProxyUsers_SelectList = GetAvailableProxyUsers(originalUserID);
return PartialView();
}
[HttpPost]
public ActionResult SetProxyUsers(FormCollection formCollection)
{
int id = int.Parse(formCollection["ddlProxyUser"]);
RolesHelper.SetProxyUser(id);
ViewBag.ProxyUsers_SelectList = GetAvailableProxyUsers(originalUserID);
return Redirect(Request.UrlReferrer.ToString());
}
All this works (except for the originalUserID variable, which I put in here to symbolize what I want done next.
My problem is that the values in the dropdown list are based on the logged in user. So, when I change user using the proxy, I also change the values in the proxy dropdown list (to either disappear if the "new" user isn't allowed to proxy, or to show the "new" user's list of available proxy users).
I need to have this selectlist stay unchanged. How do I go about storing the id of the original user? I could store it in a session variable, but I don't want to mess with potential time out issues, so that's a last resort.
Please help, and let me know if there is anything unclear with the question.
Update
I didn't realize that the HttpContext is set for each post. I haven't really worked with this kind of stuff before and for some reason assumed I was setting the values for the entire session (stupid, I know). However, I'm using windows authentication. How can I change the user on a more permanent basis (as long as the browser is open)? I assume I can't use FormAuthentication cookies since I'm using windows as my authentication mode, right?
Instead of faking the authentication, why not make it real? On a site that I work on we let admins impersonate other users by setting the authentication cookie for the user to be impersonated. Then the original user id is stored in session so if they ever log out from the impersonated users account, they are actually automatically logged back in to their original account.
Edit:
Here's a code sample of how I do impersonation:
[Authorize] //I use a custom authorize attribute; just make sure this is secured to only certain users.
public ActionResult Impersonate(string email) {
var user = YourMembershipProvider.GetUser(email);
if (user != null) {
//Store the currently logged in username in session so they can be logged back in if they log out from impersonating the user.
UserService.SetImpersonateCache(WebsiteUser.Email, user.Email);
FormsAuthentication.SetAuthCookie(user.Email, false);
}
return new RedirectResult("~/");
}
Simple as that! It's been working great. The only tricky piece is storing the session data (which certainly isn't required, it was just a nice feature to offer to my users so they wouldn't have to log back in as themselves all the time). The session key that I am using is:
string.Format("Impersonation.{0}", username)
Where username is the name of the user being impersonated (the value for that session key is the username of the original/admin user). This is important because then when the log out occurs I can say, "Hey, are there any impersonation keys for you? Because if so, I am going to log you in as that user stored in session. If not, I'll just log you out".
Here's an example of the LogOff method:
[Authorize]
public ActionResult LogOff() {
//Get from session the name of the original user that was logged in and started impersonating the current user.
var originalLoggedInUser = UserService.GetImpersonateCache(WebsiteUser.Email);
if (string.IsNullOrEmpty(originalLoggedInUser)) {
FormsAuthentication.SignOut();
} else {
FormsAuthentication.SetAuthCookie(originalLoggedInUser, false);
}
return RedirectToAction("Index", "Home");
}
I used the mvc example in the comments on this article http://www.codeproject.com/Articles/43724/ASP-NET-Forms-authentication-user-impersonation to
It uses FormsAuthentication.SetAuthCookie() to just change the current authorized cookie and also store the impersonated user identity in a cookie. This way it can easily re-authenticate you back to your original user.
I got it working very quickly. Use it to allow admin to login as anyone else.