Related
I've modified the logic in the standard ASP.NET Core Login page POST routine (Areas/Identity/Pages/Account/Login.cshtml.cs). After the user has logged in successfully, I have additional logic that may deny the login attempt. If that additional logic denies the login attempt, I want to redisplay the login page with an appropriate message displayed on the page.
My problem is that, unlike an MVC controller, where calling return View() in a POST action redisplays the view, calling return Page() in a Razor page apparently redirects to "/" (the default page in the website).
I have two questions:
In a Razor page POST routine, how do I redisplay the Razor page?
What does return Page() actually do in a POST routine?
Here is code to reproduce the behavior I see happening:
In VS 2022, create a new ASP.NET Core Web App (Model-View-Controller) project.
Framework: .NET 6.0
Authentication Type: Individual Accounts
In the Package Manager window, type: update-database
Run the application. Create a new account and verify that you can log in.
Right-click the project in Solution Explorer and select Add>New Scaffolded Item
Select Identity and click Add
Select Account\Login and click the drop-down arrow to select the ApplicationDbContext Data context class.
In Controllers/HomeController.cs, add an [Authorize] attribute to the Index method:
using Microsoft.AspNetCore.Authorization; // Added this line
using Microsoft.AspNetCore.Mvc;
using System.Diagnostics;
using WebApplication3.Models;
namespace WebApplication3.Controllers
{
public class HomeController : Controller
{
private readonly ILogger<HomeController> _logger;
public HomeController(ILogger<HomeController> logger)
{
_logger = logger;
}
[Authorize] // Added this line
public IActionResult Index()
{
return View();
}
public IActionResult Privacy()
{
return View();
}
[ResponseCache(Duration = 0, Location = ResponseCacheLocation.None, NoStore = true)]
public IActionResult Error()
{
return View(new ErrorViewModel { RequestId = Activity.Current?.Id ?? HttpContext.TraceIdentifier });
}
}
}
Run the project. The [Authorize] attribute forces you to log in before it redirects to the Index page.
Now, open Areas/Identity/Pages/Account/Login.cshtml.cs and add some code to the OnPostAsync() routine that emulates the case where an error is detected after the user has successfully authenticated.
public async Task<IActionResult> OnPostAsync(string returnUrl = null)
{
returnUrl ??= Url.Content("~/");
ExternalLogins = (await _signInManager.GetExternalAuthenticationSchemesAsync()).ToList();
if (ModelState.IsValid) {
// This doesn't count login failures towards account lockout
// To enable password failures to trigger account lockout, set lockoutOnFailure: true
var result = await _signInManager.PasswordSignInAsync(Input.Email, Input.Password, Input.RememberMe, lockoutOnFailure: false);
if (result.Succeeded) {
// User is logged in, but we want to deny the login for some reason
ModelState.AddModelError("", "Some login error"); // <--------------
return Page(); // <--------------
// <snip>
}
// If we got this far, something failed, redisplay form
return Page();
}
Run the app. The new return Page() statement, which occurs after the user is authenticated, causes the app to happily display the Index page. It does not, as I would have expected, redisplay the login page with the model error displayed.
Just add a SignOutAsync when you want to return to the login page after a successful call to SignInAsync
var result = await _signInManager.PasswordSignInAsync(Input.Email, Input.Password, Input.RememberMe, lockoutOnFailure: false);
if (result.Succeeded) {
// User is logged in, but we want to deny the login for some reason
await _signInManager.SignOutAsync();
ModelState.AddModelError("", "Some login error");
return Page();
}
TL,DR I suppose that we should look at the expected flow when the application starts.
The startup logic tries to reach the Index page, but this page has the [Authorize] attribute, so it cannot be displayed without a logged on user whatever roles we have in place.
Logically, the code flow needs to take a detour to the Login page. Here, when it receives the POST message, it looks for the credentials given and start the Identity method that leads to a logged in or not logged in user.
Exiting from the login page with a logged in user means that we have resolved the requirements for the [Authorize] attribute, else...
Now the code above logs in the user successfully and then starts some internal logic that should result in a return to the login page. But the code exits with the user still logged in, thus the Identity engine thinks that everything is ok and goes back the Index page that has caused the start of the identification process.
So we need to add the missing SignOutAsync before calling return Page();
You said,
My problem is that, unlike an MVC controller, where calling return
View() in a POST action redisplays the view, calling return Page() in
a Razor page apparently redirects to "/" (the default page in the
website).
I would suggest you add and check your additional logic before code executes if (ModelState.IsValid).
Example:
Login.cshtml.cs
public async Task<IActionResult> OnPostAsync(string returnUrl = null)
{
returnUrl ??= Url.Content("~/");
ExternalLogins = (await _signInManager.GetExternalAuthenticationSchemesAsync()).ToList();
string str = "invalid";
ViewData["Message"] = "";
if (str=="invalid")
{
ViewData["Message"] = "Something is invalid";
}
else
{
if (ModelState.IsValid)
{
// This doesn't count login failures towards account lockout
// To enable password failures to trigger account lockout, set lockoutOnFailure: true
var result = await _signInManager.PasswordSignInAsync(Input.Email, Input.Password, Input.RememberMe, lockoutOnFailure: false);
if (result.Succeeded)
{
_logger.LogInformation("User logged in.");
return LocalRedirect(returnUrl);
}
if (result.RequiresTwoFactor)
{
return RedirectToPage("./LoginWith2fa", new { ReturnUrl = returnUrl, RememberMe = Input.RememberMe });
}
if (result.IsLockedOut)
{
_logger.LogWarning("User account locked out.");
return RedirectToPage("./Lockout");
}
else
{
ModelState.AddModelError(string.Empty, "Invalid login attempt.");
return Page();
}
}
}
// If we got this far, something failed, redisplay form
return Page();
}
Then you could display the appropriate message(which we set in the 'if' condition in the example above) on the same login page like below.
Login.cshml
<p style="color:red; font-size:larger">
#ViewData["Message"]
</p>
Output:
If everything is fine then it will log in to the site.
Further, you could modify the logic as per your own requirements.
In my following action method I'm getting following design time error on line var result = await _userManager.AddToRoleAsync(user, "AdminRole");. But if I use var user = new ApplicationUser { UserName = model.SelectedUserName to get a user then the above line does not give design time error, however; as expected, it gives run time validation error as: User someUSerName already exist. I understand the run time error is due to the fact that I'm adding a role to an existing user but passing a new instance of it. Question: How can I get an existing user as an ApplicationUser object so I can pass it to AddToRoleAsync(....) below? I'm using ASP.NET Core 1.1.1, Individual User Accounts mode, VS2017.
Error:
Cannot convert from Task<MyProj.Model.ApplicationUser> to MyProj.Model.ApplicationUser
Controller
[HttpPost]
[AllowAnonymous]
[ValidateAntiForgeryToken]
public async Task<IActionResult> AddUserToRole(RoleRelatedViewModel model, string returnUrl = null)
{
ViewData["ReturnUrl"] = returnUrl;
if (ModelState.IsValid)
{
var user = _userManager.FindByNameAsync(model.SelectedUserName); //cannot be used in AddToRoleAsync(user,"AdminRole") since FindByNameAsync returns Task<ApplicationUser>
//var user = new ApplicationUser { UserName = model.SelectedUserName };
var result = await _userManager.AddToRoleAsync(user, "AdminRole");
if (result.Succeeded)
{
return RedirectToLocal(returnUrl);
}
AddErrors(result);
}
// If we got this far, something failed, redisplay form
return View(model);
}
try var user = await _userManager.FindByNameAsync(model.SelectedUserName);
it seems like AddToRoleAsync expects ApplicationUser as first parameter, but you giving Task
So if you use await before FindByNameAsync call your user variable will be ApplicationUser.
Problem
We want to use Windows Active Directory to authenticate a user into the application. However, we do not want to use Active Directory groups to manage authorization of controllers/views.
As far as I know, there is not an easy way to marry AD and identity based claims.
Goals
Authenticate users with local Active Directory
Use Identity framework to manage claims
Attempts (Fails)
Windows.Owin.Security.ActiveDirectory - Doh. This is for Azure AD. No LDAP support. Could they have called it AzureActiveDirectory instead?
Windows Authentication - This is okay with NTLM or Keberos authentication. The problems start with: i) tokens and claims are all managed by AD and I can't figure out how to use identity claims with it.
LDAP - But these seems to be forcing me to manually do forms authentication in order to use identity claims? Surely there must be an easier way?
Any help would be more than appreciated. I have been stuck on this problem quite a long time and would appreciate outside input on the matter.
Just hit AD with the username and password instead of authenticating against your DB
// POST: /Account/Login
[HttpPost]
[AllowAnonymous]
[ValidateAntiForgeryToken]
public async Task<ActionResult> Login(LoginViewModel model, string returnUrl)
{
if (ModelState.IsValid)
{
var user = await UserManager.FindByNameAsync(model.UserName);
if (user != null && AuthenticateAD(model.UserName, model.Password))
{
await SignInAsync(user, model.RememberMe);
return RedirectToLocal(returnUrl);
}
else
{
ModelState.AddModelError("", "Invalid username or password.");
}
}
return View(model);
}
public bool AuthenticateAD(string username, string password)
{
using(var context = new PrincipalContext(ContextType.Domain, "MYDOMAIN"))
{
return context.ValidateCredentials(username, password);
}
}
On ASPNET5 (beta6), the idea is to use CookieAuthentication and Identity : you'll need to add in your Startup class :
public void ConfigureServices(IServiceCollection services)
{
services.AddMvc();
services.AddAuthorization();
services.AddIdentity<MyUser, MyRole>()
.AddUserStore<MyUserStore<MyUser>>()
.AddRoleStore<MyRoleStore<MyRole>>()
.AddUserManager<MyUserManager>()
.AddDefaultTokenProviders();
}
In the configure section, add:
private void ConfigureAuth(IApplicationBuilder app)
{
// Use Microsoft.AspNet.Identity & Cookie authentication
app.UseIdentity();
app.UseCookieAuthentication(options =>
{
options.AutomaticAuthentication = true;
options.LoginPath = new PathString("/App/Login");
});
}
Then, you will need to implement:
Microsoft.AspNet.Identity.IUserStore
Microsoft.AspNet.Identity.IRoleStore
Microsoft.AspNet.Identity.IUserClaimsPrincipalFactory
and extend/override:
Microsoft.AspNet.Identity.UserManager
Microsoft.AspNet.Identity.SignInManager
I actually have setup a sample project to show how this can be done.
GitHub Link.
I tested on the beta8 and and with some small adaptatons (like Context => HttpContext) it worked too.
Shoe your solution above pushed me toward a direction that worked for me on MVC6-Beta3 Identityframework7-Beta3 EntityFramework7-Beta3:
// POST: /Account/Login
[HttpPost]
[AllowAnonymous]
[ValidateAntiForgeryToken]
public async Task<IActionResult> Login(LoginViewModel model, string returnUrl = null)
{
if (!ModelState.IsValid)
{
return View(model);
}
//
// Check for user existance in Identity Framework
//
ApplicationUser applicationUser = await _userManager.FindByNameAsync(model.eID);
if (applicationUser == null)
{
ModelState.AddModelError("", "Invalid username");
return View(model);
}
//
// Authenticate user credentials against Active Directory
//
bool isAuthenticated = await Authentication.ValidateCredentialsAsync(
_applicationSettings.Options.DomainController,
_applicationSettings.Options.DomainControllerSslPort,
model.eID, model.Password);
if (isAuthenticated == false)
{
ModelState.AddModelError("", "Invalid username or password.");
return View(model);
}
//
// Signing the user step 1.
//
IdentityResult identityResult
= await _userManager.CreateAsync(
applicationUser,
cancellationToken: Context.RequestAborted);
if(identityResult != IdentityResult.Success)
{
foreach (IdentityError error in identityResult.Errors)
{
ModelState.AddModelError("", error.Description);
}
return View(model);
}
//
// Signing the user step 2.
//
await _signInManager.SignInAsync(applicationUser,
isPersistent: false,
authenticationMethod:null,
cancellationToken: Context.RequestAborted);
return RedirectToLocal(returnUrl);
}
You could use ClaimTransformation, I just got it working this afternoon using the article and code below. I am accessing an application with Window Authentication and then adding claims based on permissions stored in a SQL Database. This is a good article that should help you.
https://github.com/aspnet/Security/issues/863
In summary ...
services.AddScoped<IClaimsTransformer, ClaimsTransformer>();
app.UseClaimsTransformation(async (context) =>
{
IClaimsTransformer transformer = context.Context.RequestServices.GetRequiredService<IClaimsTransformer>();
return await transformer.TransformAsync(context);
});
public class ClaimsTransformer : IClaimsTransformer
{
private readonly DbContext _context;
public ClaimsTransformer(DbContext dbContext)
{
_context = dbContext;
}
public async Task<ClaimsPrincipal> TransformAsync(ClaimsTransformationContext context)
{
System.Security.Principal.WindowsIdentity windowsIdentity = null;
foreach (var i in context.Principal.Identities)
{
//windows token
if (i.GetType() == typeof(System.Security.Principal.WindowsIdentity))
{
windowsIdentity = (System.Security.Principal.WindowsIdentity)i;
}
}
if (windowsIdentity != null)
{
//find user in database by username
var username = windowsIdentity.Name.Remove(0, 6);
var appUser = _context.User.FirstOrDefault(m => m.Username == username);
if (appUser != null)
{
((ClaimsIdentity)context.Principal.Identity).AddClaim(new Claim("Id", Convert.ToString(appUser.Id)));
/*//add all claims from security profile
foreach (var p in appUser.Id)
{
((ClaimsIdentity)context.Principal.Identity).AddClaim(new Claim(p.Permission, "true"));
}*/
}
}
return await System.Threading.Tasks.Task.FromResult(context.Principal);
}
}
Do you know how to implement a custom System.Web.Security.MembershipProvider? You should be able to use this (override ValidateUser) in conjunction with System.DirectoryServices.AccountManagement.PrincipalContext.ValidateCredentials() to authenticate against active directory.
try:
var pc = new PrincipalContext(ContextType.Domain, "example.com", "DC=example,DC=com");
pc.ValidateCredentials(username, password);
I had to design a solution to this problem this way:
1. Any AD authenticated user will be able to access the application.
2. The roles and claims of the users are stored in the Identity database of the application.
3. An admin user will be able to assign roles to users (I have added this functionality to the app as well).
Read on if you want to see my complete solution. The link to the full source code is towards the end of this answer.
Basic design
1. User enters Active Directory credentials (Windows login credentials in this case).
2. The app checks if it's a valid login against AD.
2.1. If it's not valid, app returns the page with 'Invalid login attempt' error message.
2.2. If it's valid, go to next step.
3. Check if the user exists in the Identity database.
3.1. If Not, create this user in our Identity database.
3.2 If Yes, go to next step.
4. SignIn the user (using AD credentials). This is where we override UserManager.
Note: The user created in step 3.1 has no roles assigned.
An admin user (with valid AD username) is created during Db initialization. Adjust the Admin2UserName with your AD username if you want to be the admin user who will assign roles to newly added users. Don't even worry about the password, it can be anything because the actual authentication will happen through AD not through what's in Identity database.
Solution
Step 1:
Ensure that you've got Identity setup in your application. As an example, I'm taking a Blazor Server app here. If you don't have Identity setup, follow this guide from Microsoft learn.
Use my project to follow along the guide.
Step 2:
Add ADHelper static class to help with Active Directory login. In my example, it's at Areas/Identity/ADHelper.cs and has contents that look like this:
using System.DirectoryServices.AccountManagement;
namespace HMT.Web.Server.Areas.Identity
{
public static class ADHelper
{
public static bool ADLogin(string userName, string password)
{
using PrincipalContext principalContext = new(ContextType.Domain);
bool isValidLogin = principalContext.ValidateCredentials(userName.ToUpper(), password);
return isValidLogin;
}
}
}
Step 3:
Override CheckPasswordAsync method in UserManager so you can authenticate users against Active Directory. I have done this in Areas/Identity/ADUserManager.cs, the contents of which look like this:
using Microsoft.AspNetCore.Identity;
using Microsoft.Extensions.Options;
namespace HMT.Web.Server.Areas.Identity
{
public class ADUserManager<TUser> : UserManager<TUser> where TUser : IdentityUser
{
public ADUserManager(IUserStore<TUser> store, IOptions<IdentityOptions> optionsAccessor,
IPasswordHasher<TUser> passwordHasher, IEnumerable<IUserValidator<TUser>> userValidators,
IEnumerable<IPasswordValidator<TUser>> passwordValidators, ILookupNormalizer keyNormalizer,
IdentityErrorDescriber errors, IServiceProvider services, ILogger<UserManager<TUser>> logger)
: base(store, optionsAccessor, passwordHasher, userValidators, passwordValidators, keyNormalizer,
errors, services, logger)
{
}
public override Task<bool> CheckPasswordAsync(TUser user, string password)
{
var adLoginResult = ADHelper.ADLogin(user.UserName, password);
return Task.FromResult(adLoginResult);
}
}
}
Step 4:
Register it in your Program.cs
builder.Services
.AddDefaultIdentity<ApplicationUser>(options =>
{
options.SignIn.RequireConfirmedAccount = false;
})
.AddRoles<ApplicationRole>()
.AddUserManager<CustomUserManager<ApplicationUser>>() <----- THIS GUY
.AddEntityFrameworkStores<ApplicationDbContext>();
ApplicationUser, ApplicationRole and ApplicationDbContext look like this:
public class ApplicationUser : IdentityUser
{
}
public class ApplicationRole : IdentityRole
{
}
public class ApplicationDbContext : IdentityDbContext<ApplicationUser, ApplicationRole, string>
{
public ApplicationDbContext(DbContextOptions<ApplicationDbContext> options)
: base(options)
{
}
protected override void OnModelCreating(ModelBuilder builder)
{
base.OnModelCreating(builder);
// Customize the ASP.NET Identity model and override the defaults if needed.
// For example, you can rename the ASP.NET Identity table names and more.
// Add your customizations after calling base.OnModelCreating(builder);
}
}
Step 5:
Update OnPostAsync method in Areas/Identity/Pages/Account/Login.cshtml.cs to implement the authentication flow. The method looks like this:
public async Task<IActionResult> OnPostAsync(string returnUrl = null)
{
returnUrl ??= Url.Content("~/");
if (ModelState.IsValid)
{
// Step 1: Authenticate an user against AD
// If YES: Go to next step
// If NO: Terminate the process
var adLoginResult = ADHelper.ADLogin(Input.UserName, Input.Password);
if (!adLoginResult)
{
ModelState.AddModelError(string.Empty, "Invalid login attempt.");
return Page();
}
// Step 2: Check if the user exists in our Identity Db
// If YES: Proceed to SignIn the user
// If NO: Either terminate the process OR create this user in our Identity Db and THEN proceed to SignIn the user
// I'm going with OR scenario this time
var user = await _userManager.FindByNameAsync(Input.UserName);
if (user == null)
{
var identityResult = await _userManager.CreateAsync(new ApplicationUser
{
UserName = Input.UserName,
}, Input.Password);
if (identityResult != IdentityResult.Success)
{
ModelState.AddModelError(string.Empty, "The user was authenticated against AD successfully, but failed to be inserted into Application's Identity database.");
foreach (IdentityError error in identityResult.Errors)
{
ModelState.AddModelError(string.Empty, error.Description);
}
return Page();
}
}
// Step 3: SignIn the user using AD credentials
// This doesn't count login failures towards account lockout
// To enable password failures to trigger account lockout, set lockoutOnFailure: true
var result = await _signInManager.PasswordSignInAsync(Input.UserName, Input.Password, Input.RememberMe, lockoutOnFailure: false);
if (result.Succeeded)
{
_logger.LogInformation("User logged in.");
return LocalRedirect(returnUrl);
}
if (result.RequiresTwoFactor)
{
return RedirectToPage("./LoginWith2fa", new { ReturnUrl = returnUrl, RememberMe = Input.RememberMe });
}
if (result.IsLockedOut)
{
_logger.LogWarning("User account locked out.");
return RedirectToPage("./Lockout");
}
else
{
ModelState.AddModelError(string.Empty, "Invalid login attempt.");
return Page();
}
}
// If we got this far, something failed, redisplay form
return Page();
}
Basically, we're done here. 🙌
Step 6:
Now if an admin user wants to assign roles to newly added users, simply go to Manage Users page and assign appropriate roles.
Pretty easy, right? 😃
Step 7:
If you want to manage roles (add, edit, delete), simply go to manage/roles page.
Conclusion
This setup ensures that users are authenticated using Active Directory and are authorized using roles in the Identity database.
Complete source code
https://github.com/affableashish/blazor-server-auth/tree/feature/AddADAuthentication
I am not sure if I am missing something here. By Default User.IsInRole() does not work even if user DOES HAVE some roles.
I don't have my own implementation of role stores. I am assuming that the default ones should work. Is there something special that I need to do in the Startup.cs to get the roles working? I'm using mvc 6 beta 2 default template.
The User.IsInRole() does not work if I add a role like this:
await UserManager.AddToRoleAsync(user, "Admin");
But it does work if I do this:
await UserManager.AddClaimAsync(user, claim: new Claim(ClaimTypes.Role.ToString(), "Admin"));
It looks like you're using Asp.NET Identity with the latest ASP.NET 5 stuff. I'm using the same (currently using RC1). I had a similar issue, and after some digging I found a solution by using SignInManager's RefreshSignInAsync() method.
Note that to get a hold of an instance of UserManager and SignInManager I use dependency injection, so the constructor for my controller looks like this:
public MyController(
UserManager<ApplicationUser> userManager,
SignInManager<ApplicationUser> signInManager)
{
_userManager = userManager;
_signInManager = signInManager;
}
My requirement was that if a particular controller method was accessed by an authenticated user, then a role would be added to that user if the user didn't already have that role, and it needed to take effect immediately. (Subsequent calls to User.IsInRole("TheRole") in controllers and views need return true without the user having to log out and back in).
Here's the action:
[AllowAnonymous]
public async Task<IActionResult> CreateProfile()
{
if (User == null || User.Identity == null || !User.Identity.IsAuthenticated)
{
return RedirectToAction("RegisterOrSignIn", "Account");
}
else
{
if (!User.IsInRole("TheRole"))
{
ApplicationUser applicationUser =
await _userManager.FindByIdAsync(User.GetUserId());
await _userManager.AddToRoleAsync(applicationUser, "TheRole");
await _signInManager.RefreshSignInAsync(applicationUser);
}
return RedirectToAction("Index");
}
}
Note you need
using System.Security.Claims;
for the GetUserId() extension method.
So the big things that I learned was to use UserManager's AddToRoleAsync and SignInManager's RefreshSignInAsync. The first adds a row to the AspNetUserRoles table. The second refreshes the cookie that, with the next request from the browser, will show that the user is in the role.
As an aside, I added a method called EnsureRoles() to Startup.cs. I call it right after the call to app.UseIdentity() in Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory). So, here's a snipit from Configure():
...
// Add cookie-based authentication to the request pipeline.
app.UseIdentity();
#pragma warning disable CS4014 // Because this call is not awaited, execution of the current method continues before the call is completed
// Ensure roles are in DB - OK not to await this for now
EnsureRoles(app, loggerFactory);
#pragma warning restore CS4014 // Because this call is not awaited, execution of the current method continues before the call is completed
...
and here is EnsureRoles():
private async Task EnsureRoles(IApplicationBuilder app, ILoggerFactory loggerFactory)
{
ILogger logger = loggerFactory.CreateLogger<Startup>();
RoleManager<IdentityRole> roleManager = app.ApplicationServices.GetService<RoleManager<IdentityRole>>();
string[] roleNames = { "TheRole", "AnotherRole" };
foreach (string roleName in roleNames)
{
bool roleExists = await roleManager.RoleExistsAsync(roleName);
if (!roleExists)
{
logger.LogInformation(String.Format("!roleExists for roleName {0}", roleName));
IdentityRole identityRole = new IdentityRole(roleName);
IdentityResult identityResult = await roleManager.CreateAsync(identityRole);
if (!identityResult.Succeeded)
{
logger.LogCritical(
String.Format(
"!identityResult.Succeeded after
roleManager.CreateAsync(identityRole) for
identityRole with roleName {0}",
roleName));
foreach (var error in identityResult.Errors)
{
logger.LogCritical(
String.Format(
"identityResult.Error.Description: {0}",
error.Description));
logger.LogCritical(
String.Format(
"identityResult.Error.Code: {0}",
error.Code));
}
}
}
}
}
Developing a new MVC5 project. I have my scaffolding in place for CRUD functionality but there is a requirement that when data is inserted or updated, an e-signature is required. Before data can be submitted to the database the user must be presented with a page asking them to enter their username and password again to confirm the data. If the username and password entered is valid and the username matches the currently signed in user, then the original data entered can be saved to its table (for example Member) and the e-signature information is saved to a separate table (ESignature). I'd appreciate any help on the best way to go about this - a view model combining Member and ESignature, or a reuse of the LoginViewModel from the Account controller to check the authentication, or an alternative approach? I need something that I can use across half a dozen controllers where e-signatures are required.
Alright maybe my approach is not the best but I will attempt.
My solution would be to create a CustomAttribute: AuthorizeAttribute and decorate all the actions which require Esignature. In your CustomAttribute implementation you will redirect to a controller action exactly similar to Login but with slight modification.
public class CustomAuthorize : AuthorizeAttribute
{
public override void OnAuthorization(AuthorizationContext filterContext)
{
base.OnAuthorization(filterContext);
var url = filterContext.HttpContext.Request.Url;
var query = url.Query;
if (query.Contains("g="))
{
var code = query.Split(new String[] { "g=" }, StringSplitOptions.None);
//You can create time sensistive token and validate it.
}
else
{
//Redirect User to a particular page
filterContext.Result = new RedirectToRouteResult(
new RouteValueDictionary
{
{ "controller", "Account" },
{ "action", "elogin" },
{ "redirectUrl", url.AbsolutePath}
}
);
}
}
}
Then decorate for example Index() method with it.
[CustomAuthorize]
public ActionResult Index()
{
return View();
}
At first when you hit the Index() method then inside OnAuthorization method of CustomAuthorizeAttribute the else loop gets executed and re-directs you to a elogin method inside AccountController. This method is similar to the Login HttpGet method. While specifying the RedirectToResult I am specifying the redirectUrl path of the current page so when you successfully validate a user inside the elogin method then with the help of redirectUrl we can come back.
[AllowAnonymous]
public ActionResult ELogin(string returnUrl)
{
ViewBag.ReturnUrl = returnUrl;
return View("Login");
}
//
// POST: /Account/Login
[HttpPost]
[AllowAnonymous]
[ValidateAntiForgeryToken]
public async Task<ActionResult> ELogin(LoginViewModel model, string returnUrl)
{
if (ModelState.IsValid)
{
var user = await UserManager.FindAsync(model.UserName, model.Password);
if (user != null)
{
await SignInAsync(user, model.RememberMe);
var url = String.Format("{0}/?g={1}", returnUrl, "HashCode");
return RedirectToLocal(url);
}
else
{
ModelState.AddModelError("", "Invalid username or password.");
}
}
// If we got this far, something failed, redisplay form
return View(model);
}
The only difference in the HttpPost ELogin method is that before doing RedirectToLocal I append /g=HasCode. Note: Here you can append your own logic to create a time sensitive hash. When we get redirected to our home page then we can inspect inside our OnAuthorization Method if the url contains g=HashCode then don't redirect to Login Page.
This would be very basic idea on how you can approach to force users to re-sign in whenever they hit specific controllers. You will have to do additional security checks and be careful in what you are exposing via url.