title: mvc form submits as get instead of post
body: <p>Clients report the search function in my mvc application is returning no results on first attemps yet gives results on a second search with the same searchstring.</p>
  
  <p>After some digging I found that if you leave a page open for a few minutes (2-5min) the search function would submit a GET request instead of a POST request, resulting in a searchstring with value NULL.</p>
  
  <p>After extended searching I have yet to find an answer to this. The search function works and posts when actively working with the application, but leaving a page idle for a while and it no longer posts which is greatly annoying my clients.</p>
  
  <p>here's the form:</p>
  
  <pre><code>@using (Html.BeginForm("Search", "Student", FormMethod.Post, new { @class = "navbar-form-custom", style = "width:350px;" }))
                          {
                                  &lt;input type="text" id="search" name="search" class="form-control" style="height: 43px; width: 300px; border-radius: 5px; padding: 5px; height: 40px; margin-top:5px; border: 2px solid #e6e6e6;" placeholder="Search student" required&gt;
                          }
  </code></pre>
  
  <p>and the action:</p>
  
  <pre><code>public ActionResult Search(string search)
      {
          return View(_repo.SearchStudent(search));
      }
  </code></pre>
  
  <p>I've added [HttpPost] to the action, which just results in a 404 error when the GET triggers.</p>
  
  <p>For now I've 'solved' the issue by switching the form to FormMethod.Get, which seems to work, though the addition of a query string isn't ideal.</p>
  
  <p>I'm still looking for a proper solution as I suspect other forms on the application of showing similar behavior (bug reports of changes going unsaved without errors, other actions throwing null exceptions when they really shouldn't, etc)</p>
  
  <p>I've made similar projects before and never encountered this behavior. Could this be an IIS issue or settings related?</p>
  
  <p>Edit: Found the culprit. Apparently the user's session times out. which results in a redirect to '\Account\Login?ReturnUrl="Student/Search"'. Since the application uses a SSO session the user gets logged back in immediatly and never notices. the return URL is then accessed as a GET request which explains the sudden switch from POST to GET. Switching the form to GET fixed the issue as the searchterm gets passed as a querystring and therefor doesn't get lost after logging in. this does however pose a serious issue and explains a lot of bugreports concerning unsaved data.</p>
  
  <p>never had such an issue before, but somehow the session length seems very short on this application. been looking for a setting but haven't found any in the config file (initial stages of the project were made together with an ex-coworker and hosting isn't managed by me)</p>
  
  <p>Edit 2: Well, now I just feel like an idiot. Ignored the default Startup.Auth.cs file</p>
  
  <pre><code>app.UseCookieAuthentication(new CookieAuthenticationOptions
          {
              AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie,
              LoginPath = new PathString("/Account/Login"),
              Provider = new CookieAuthenticationProvider
              {
                  // Enables the application to validate the security stamp when the user logs in.
                  // This is a security feature which is used when you change a password or add an external login to your account.  
                  OnValidateIdentity = SecurityStampValidator.OnValidateIdentity&lt;ApplicationUserManager, ApplicationUser&gt;(
                      validateInterval: TimeSpan.FromMinutes(30),
                      regenerateIdentity: (manager, user) =&gt; user.GenerateUserIdentityAsync(manager))
              },
              ExpireTimeSpan = TimeSpan.FromMinutes(5) //&lt;&lt;DUH OBVIOUSLY
          });            
          app.UseExternalSignInCookie(DefaultAuthenticationTypes.ExternalCookie);
  </code></pre>
  
  <p>should've been the first place I looked when I noticed the problem occurred after a set time.</p>
  
  <p>my bad</p>