We Keep Coding

ASP.NET MVC 5 Keeping old input between requests

I need feature that is something similar to Laravel's old input helper but in MVC 5.
https://laravel.com/docs/5.6/requests#old-input
If validation fails, I need to reload all my model data as it was in the previous request except those inputs where user entered something wrong.
The problem is that my form has many disabled inputs and fields that program is fetching within [HttpGet] method, and they're getting lost during submission. So I need to store them in session.
The code below seems to work but is there any more efficient and beautiful way to do so with a less amount of code within each controller?
[HttpGet]
[Route(#"TaskManagement/Edit/{guid}")]
public async Task<ActionResult> Edit(Guid guid)
{
var model = new EditTaskViewModel();
model.Guid = guid;
await model.GetTaskFromRemoteService(new UserInfo(User));
ControllerHelpers.DisplayAlerts(model, this);
TempData["OldModel"] = model;
return View(model);
}
[HttpPost]
[ValidateAntiForgeryToken]
[Route(#"TaskManagement/Edit/{guid}")]
public async Task<ActionResult> Edit(EditTaskViewModel model, Guid guid, string submit)
{
model.Guid = guid;
if (ModelState.IsValid) {
await model.UpdateTaskInRemoteService(new UserInfo(User), submit);
ControllerHelpers.DisplayAlerts(model, this, "Task successfully updated");
if (model.ErrorCode == null)
return RedirectToAction("Edit", new { guid = model.Guid });
return RedirectToAction("Index");
}
if (TempData["OldModel"] != null) {
model = (EditTaskViewModel)TempData["OldModel"];
}
return View(model);
}

Using session state (including TempData) like this may break when you have multiple copies of the page open. You can work around this by generating a unique ID for the session key and storing it in a hidden field.
However, I would try to avoid using session altogether.
A simple approach is to use hidden fields to store the values that aren't sent to the server because they are in disabled fields.
A more robust approach is a separate class (or at least a private method) that knows how to setup your model for the first time and in transition (e.g. failed server validation). I call these classes "composers" and I describe the approach here.
Pseudocode for how an action method with a composer might look:
if( ModelState.IsValid ){
return Redirect();
}
var rebuiltModel = _composer.ComposeEdit( incomingModel );
return View( rebuiltModel );

I think the answer was quite simple. The shortest and easiest way is to populate the object from the database\remote service once more.
The fields that user entered whether they're valid or not will stay as they were before. The rest of them will load once again.

Avoid fast post on webapi c#

I have problem in when user post the data. Some times the post run so fast and this make problem in my website.
The user want to register a form about 100$ and have 120$ balance.
When the post (save) button pressed sometimes two post come to server very fast like:
2018-01-31 19:34:43.660 Register Form 5760$
2018-01-31 19:34:43.663 Register Form 5760$
Therefore my client balance become negative.
I use If in my code to check balance but the code run many fast and I think both if happen together and I missed them.
Therefore I made Lock Controll class to avoid concurrency per user but not work well.
I made global Action Filter to control the users this is my code:
public void OnActionExecuting(ActionExecutingContext context)
{
try
{
var controller = (Controller)context.Controller;
if (controller.User.Identity.IsAuthenticated)
{
bool jobDone = false;
int delay = 0;
int counter = 0;
do
{
delay = LockControllers.IsRequested(controller.User.Identity.Name);
if (delay == 0)
{
LockControllers.AddUser(controller.User.Identity.Name);
jobDone = true;
}
else
{
counter++;
System.Threading.Thread.Sleep(delay);
}
if (counter >= 10000)
{
context.HttpContext.Response.StatusCode = 400;
jobDone = true;
context.Result = new ContentResult()
{
Content = "Attack Detected"
};
}
} while (!jobDone);
}
}
catch (System.Exception)
{
}
}
public void OnActionExecuted(ActionExecutedContext context)
{
try
{
var controller = (Controller)context.Controller;
if (controller.User.Identity.IsAuthenticated)
{
LockControllers.RemoveUser(controller.User.Identity.Name);
}
}
catch (System.Exception)
{
}
}
I made list static list of user and sleep their thread until previous task happen.
Is there any better way to manage this problem?

So the original question has been edited so this answer is invalid.
so the issue isn't that the code runs too fast. Fast is always good :) The issue is that the account is going into negative funds. If the client decides to post a form twice that is the clients fault. It maybe that you only want the client to pay only once which is an other problem.
So for the first problem, I would recommend a using transactions (https://en.wikipedia.org/wiki/Database_transaction) to lock your table. Which means that the add update/add a change (or set of changes) and you force other calls to that table to wait until those operations have been done. You can always begin your transaction and check that the account has the correct amount of funds.
If the case is that they are only ever meant to pay once then.. then have a separate table that records if the user has payed (again within a transaction), before processing the update/add.
http://www.entityframeworktutorial.net/entityframework6/transaction-in-entity-framework.aspx
(Edit: fixing link)

You have a few options here
You implement ETag functionality in your app which you can use for optimistic concurrency. This works well, when you are working with records, i.e. you have a database with a data record, return that to the user and then the user changes it.
You could add an required field with a guid to your view model which you pass to your app and add it to in memory cache and check it on each request.
public class RegisterViewModel
{
[Required]
public Guid Id { get; set; }
/* other properties here */
...
}
and then use IMemoryCache or IDistributedMemoryCache (see ASP.NET Core Docs) to put this Id into the memory cache and validate it on request
public Task<IActioNResult> Register(RegisterViewModel register)
{
if(!ModelState.IsValid)
return BadRequest(ModelState);
var userId = ...; /* get userId */
if(_cache.TryGetValue($"Registration-{userId}", register.Id))
{
return BadRequest(new { ErrorMessage = "Command already recieved by this user" });
}
// Set cache options.
var cacheEntryOptions = new MemoryCacheEntryOptions()
// Keep in cache for 5 minutes, reset time if accessed.
.SetSlidingExpiration(TimeSpan.FromMinutes(5));
// when we're here, the command wasn't executed before, so we save the key in the cache
_cache.Set($"Registration-{userId}", register.Id, cacheEntryOptions );
// call your service here to process it
registrationService.Register(...);
}
When the second request arrives, the value will already be in the (distributed) memory cache and the operation will fail.
If the caller do not sets the Id, validation will fail.
Of course all that Jonathan Hickey listed in his answer below applies to, you should always validate that there is enough balance and use EF-Cores optimistic or pessimistic concurrency

Losing Cookies and Session Variables during AuthorizeCore

I'm currently working on getting a test environment stood up (it is currently called DEV) and am experiencing some weird issues.
When you first come to the site, we have an agreement page. Hitting the "I Agree" button will force the user through an Action to check to see if they are a member of the site already or not. We do use a demo mode also, but that is not part of the issue.
The issue I'm currently experiencing is the following. Initially in the Action, we create a Cookie called "siteaccept". Once that is created, we determine if the site is in demo mode or not, then move on to getting the user (actual user or demo user). Once the user is found, we log their Id in a Cookie called "cntPOC", and also create a Session variable by the same name with the same data (original developers wrote much of this convoluted logic which I want to change before someone asks why keep a Session and Cookie). We then do a RedirectToAction to the Action to bring up the main page of the site.
Here is where the issue comes into play. The main page of the site's Action has a CustomAuthorizeAttribute decoration on it. In our CustomAuthorizeAttribute class, we have OnAuthorizion and AuthorizeCore being overrode. OnAuthorizion fires off first, however, it uses base.OnAuthorization. Once that is called, AuthorizeCore is called. In AuthorizeCore, we check for the "siteaccept" Cookie, followed by a check on the "cntPOC" Session variable. If both are there, we return true, otherwise false if either fails.
On not only my local environment but the DBA's, this works without a hitch. I see our Cookies and Session variable. However, on our DEV environment, both the Cookies and Session variable are missing. We have IE 11 configured to allow Cookies, yet we cannot get them once we leave the Action and proceed into the CustomAuthorizeAttribute.
I did find I can find the Cookie today if I check HttpContext.Current.Response instead of HttpContext.Current.Request, but that is the incorrect way to do it obviously.
Below is my code. I'm fairly certain since the code works on my local environment, it should be fine in our DEV environment. Also a quick note, our production environment does work, so the code obviously functions. It's a question now of why does the DEV environment not.
MainController.cs
[HttpPost]
public ActionResult Index(FormCollection frmCollection)
{
try
{
Response.Cookies.Remove("bracmisaccept");
HttpCookie cookie = new HttpCookie("bracmisaccept");
cookie.Value = "true";
Response.Cookies.Add(cookie);
...
//Demo Mode
var poc = new HttpCookie("cntPOC");
cookie.Value = "7578";
Response.Cookies.Add(poc);
Session["cntPOC"] = 7578;
return RedirectToAction("ApplicationSelection");
}
catch (Exception ex)
{
logger.LogError("Main Index", ex);
return PartialView(#"../Error/ExceptionHandling");
}
}
[CustomAuthorizeAttribute]
public ActionResult ApplicationSelection()
{
return View();
}
CustomAuthorizeAttribute.cs
public string RedirectUrl = "~/Main/SessionTimeout";
public string CookieExpiredRedirectUrl = "~/Main/Index";
public string AjaxRedirectUrl = "~/Error/AjaxError";
private bool _isAuthorized;
private bool _isCookieExpired;
protected override bool AuthorizeCore(HttpContextBase httpContext)
{
if (HttpContext.Current.Request.Cookies["siteaccept"] == null)
{
_isAuthorized = false;
_isCookieExpired = true;
return false;
}
if (HttpContext.Current.Session["cntPOC"] == null)
{
_isAuthorized = false;
return false;
}
return true;
}
public override void OnAuthorization(AuthorizationContext filterContext)
{
base.OnAuthorization(filterContext);
if (!_isAuthorized)
{
if (filterContext.RequestContext.HttpContext.Request.IsAjaxRequest())
{
filterContext.HttpContext.Response.StatusCode = 401;
filterContext.HttpContext.Response.End();
}
else
{
if(_isCookieExpired)
filterContext.RequestContext.HttpContext.Response.Redirect(CookieExpiredRedirectUrl);
else
filterContext.RequestContext.HttpContext.Response.Redirect(RedirectUrl);
}
}
}
I'm fairly certain the code is fine, but I did read in a few articles that AuthorizeCore may or may not have the Cookies and Session variables at times. I just wanted to find out if I'm wasting my time with changing the code or if it's the box we have this site on. The server is super locked down, so yeah, kind of annoying...
Edit: I have yet to figure out how to fix this yet, however, I did find if I do a publish on this code, I can enter into the site properly. I still cannot run localhost to inspect the site, but a publish fixes a few minor issues of whether things will work on this site.

Session Manager will not log me out when session expires, HTTPContext.Current is Null

I'm having this issue with my current session manager, when the session expires it will not log off the user.
At random intervals while user is logged in the HttpContext.Current is NULL causing the site to generate many errors. I've tried a couple of techniques to redirect user to login upon session expiration, with no success.
Under Global.asax I'm making use of Session_End can attempted to
call LogOut method but this gets executed even before user logs
in.
Under Global.asax I added Application_AcquireRequestState, but sadly this makes way to many calls to the SSO Service. Also, it never redirected to login upon session expiration. I tested it with the following FormsAuthentication.RedirectToLoginPage(); No luck.
I found this answer by Lex Li "Why HttpContext.Current be null?" - it gave me some insight on what my problem could be, even-though my application doesn't make use of background-threads, my HttpContext.Current comes back Null with some random requests, doesn't always happen.
Session Manager
public class SessionManager
{
private const string SessionKey = "AppSession";
private SessionManager()
{
GUID = new Guid();
FirstName = String.Empty;
LastName = String.Empty;
Email = String.Empty;
SessionExpiration = new DateTime();
}
// Gets the current session.
public static SessionManager Current
{
get
{
if(HttpContext.Current != null)
{
if (HttpContext.Current.Session[SessionKey] == null)
{
var model = new SessionManager();
HttpContext.Current.Session[SessionKey] = model;
}
return (SessionManager)HttpContext.Current.Session[SessionKey];
}
else
{
return null;
}
}
}
public static void LogOffUser()
{
//SSO is a seperate service, I need to stay insync.
var ssoAuth = new SSOAuth();
if(Current != null)
ssoAuth.SSOLogoffUser(Current.GUID);
FormsAuthentication.SignOut();
FormsAuthentication.RedirectToLoginPage();
}
public Guid GUID { get; set; }
public string FirstName { get; set; }
public string LastName { get; set; }
public string Email { get; set; }
public DateTime SessionExpiration { get; set; }
}
Login Controller
[HttpPost]
[AllowAnonymous]
public JsonResult Login(LoginViewModel user)
{
var ssoAuth = new SSOAuth();
var sessionObject = ssoAuth.SSOLoginUser(user.Email, user.Password);
if (sessionObject != null && sessionObject.SessionId != Guid.Empty)
{
SessionManager.Current.Email = sessionObject.UserId;
SessionManager.Current.GUID = sessionObject.SessionId;
SessionManager.Current.FirstName = sessionObject.FirstName;
SessionManager.Current.LastName = sessionObject.LastName;
SessionManager.Current.SessionExpiration = sessionObject.SessionExpiration;
//Grab difference in time to get session timeout in minutes.
var differenceInTime = SessionManager.Current.SessionExpiration - DateTime.Now;
Session.Timeout = differenceInTime.Minutes;
//Authenticate user
FormsAuthentication.SetAuthCookie(user.Email, false);
//We return JSON, Its an AJAX Call.
return Json(new
{
redirectUrl = "/Home.mvc/Home/Index",
isRedirect = true
});
}
return Json(new
{
redirectUrl = string.Empty,
isRedirect = false
});
}

As confirmed in the comments, you're setting your application pool's Maximum number of worker processes to a value higher than 1 and use In-Process Mode for session state.
I'm pretty sure this is the problem of HttpContext.Current.Session being null randomly instead of HttpContext.Current.
InProc session state and multiple working processes are not compatible. With InProc session state, your session state is stored in worker processes memory and is not shared between worker processes => that results in session state being lost randomly when your requests are served by different processes.
In your case, setting Maximum number of worker processes to 1 should fix the issue.
If you're looking for a multiple working processes solution, you should store your session state out of process using either a session state service or a database: http://tutorials.csharp-online.net/ASP.NET_State_Management%E2%80%94Storing_Session_State_out_of_Process

This sounds suspiciously like it may be a session vs. forms authentication timing issue similar to
Forms Authentication Timeout vs Session Timeout
Make sure your Forms timeout is at least 2x your session timeout.

I think that you may need to verify that you have this set in your web.config
<httpRuntime targetFramework="4.5" />
It seems that you may not have the task friendly awaits and that will cause unexpected behaviors such as this. You may refer to the similar problem posed here and the solution.
Now, you may not be using Asynchronous code in your soution, but that doesn't mean that it isn't being used by the framework. Regardless, I think it is worth a shot.

MVC4 Forms Authentication Auto Login

So, what I am trying to accomplish is a basic "remember me" style action for users of my application.
I have completed writing everything so far, and it is working as expected most of the time. Occasionally though, the method to check for the persistent Forms Authentication ticket doesn't auto login, and I can't figure out why it is only happening occasionally.
To test my code, what I have done is start the debugger, manually kill my session cookie in chrome's dev tools, then reload the page. Stepping through the code, it enters into the auto login method as expected and proceeds to reset my session data. However, if I wait an inordinate amount of time, like 4 hours perhaps, and try the same thing it does not auto reset my session. (Assuming that i've left the debugger running for that amount of time).
EDIT: For clarity's sake, when this error is happening, I can open the dev tools and see that the authentication ticket is still available. It's just the code to reset my session is either not running, for erroring out somewhere. Due to the infrequency in which this is happening, it's hard to track down.
So, onto the code.
I'm calling the static void auto login method in the controller's constructor, and passing the httpcontext into the auto login method.
Controller
public class SiteController : Controller
{
public SiteController()
{
this.UserAutoLogin(System.Web.HttpContext.Current);
}
// GET: /Site/
public ActionResult Index()
{
ViewBag.CatNav = this.RenderNavCategories();
return View();
}
}
Auto Login Code
public static void UserAutoLogin(this Controller Controller, System.Web.HttpContext context)
{
HttpCookie cookie = HttpContext.Current.Request.Cookies.Get(FormsAuthentication.FormsCookieName);
if (cookie != null)
{
FormsAuthenticationTicket ticket = FormsAuthentication.Decrypt(cookie.Value);
if (ticket != null)
{
if (ticket.Name.Length > 0)
{
try
{
if (context.Session["UserName"] == null)
{
//get user from db
PersonRepository PersonRepo = new PersonRepository();
PersonModel Member = PersonRepo.GetUserUserName(ticket.Name);
if (Member.FirstName != null) //if this is null...then the cookie is wrong, so don't do shit
{
//Set the session parameters
context.Session["FirstName"] = Member.FirstName;
context.Session["LastName"] = Member.LastName;
context.Session["UserId"] = Member.Id;
context.Session["UserName"] = Member.Username;
context.Session["Email"] = Member.Email;
context.Session["IsUser"] = 1;
context.Session["Zip"] = Member.Zip;
FormsAuthentication.SignOut();
FormsAuthentication.SetAuthCookie(Member.Username, true);
}
}
}
catch (Exception ex)
{
// don't do anything for now - do something smart later :)
Console.WriteLine(ex.ToString());
}
}
}
}
}

Because when IIS is recycling the app, a new machine key is generated. The FormsAuthentication ticket is signed using that key so when the key changes the old ticket isn't recognized. You need to use a fixed machine key.
Edit: Removed link to key generator site (now defunct)