Wednesday, October 29, 2014

Customised OutputCache with VaryByCustom

Customised OutputCache with VaryByCustom

In ASP.NET (MVC or not), it is possible to easily cache the rendering of a web page.
Take the case of an ASP.NET MVC project :

   1:  [OutputCache(Duration = 3600, Location = OutputCacheLocation.Client)]
   2:  public ActionResult Index()
   3:  {
   4:      return View();
   5:  }

We use the attribute "OutputCache" to cache the page. This case is very simple, the page is cached for one hour (3600 seconds) on the client side.

Now imagine that the "Index" view contains the actual time...

   1:  <p>@DateTime.UtcNow.ToLongTimeString()</p>

If you debug your website, you will see that the time is the same after a refresh. You can try this during an hour, it will still be the same.
Now we change the view's code with this:

   1:  <p>@DateTime.UtcNow.ToLongTimeString()</p>
   2:  <a href="?parameter=1">test</a><br />

And the controller's code with this:

   1:  [OutputCache(Duration = 3600, VaryByParam = "parameter", Location = OutputCacheLocation.Client)]
   2:  public ActionResult Index()
   3:  {
   4:      return View();
   5:  }

If you debug your website and you click on the link "test", you will have 2 cached versions : one with no parameter and one with "parameter=1". If you change the value of "parameter", you will have another cached version. This kind of functionality can be useful with query parameters (attention: choose the good time of caching according to your needs...). If you need to put more than one parameter, you can separate each parameters like this : VaryByParam = "parameter1;parameter2;parameter3"

When I was developing the homepage of a project (and the layout of the website), I encountered the following problem : I wanted to cache the homepage in the same way but there was the name of the current user in the top of the page (or nothing if there were not an authenticated user...).

You can see here a part of the top of the page:

   1:  @if (User.Identity.IsAuthenticated)
   2:  {
   3:      <li class="dropdown">
   4:          <a href="#" class="dropdown-toggle">@User.Identity.Name</a>
   5:          <ul class="dropdown-menu">
   6:              <li><a href="#">Account parameters</a></li>
   7:              <li><a href="@Url.Action("LogOff", "Account")">Log off</a></li>
   8:          </ul>
   9:      </li>
  10:  }
  11:  else
  12:  {
  13:      <li><a href="@Url.Action("Register", "Account")">Register</a></li>
  14:      <li><a href="@Url.Action("LogOn", "Account")">Log on</a></li>
  15:  }

If I test this code with a OutputCache attribute with a duration of one hour, I will get a bad result : imagine that I try to debug the website and the user is already authenticated... We will see his name on the top of the page and that is normal. Now I click on the logout link : the "LogOff" action will redirect me on the homepage and I will still see the name of the user on the top of the page. He is not authenticated but the homepage is in cache for one hour and I will get the same result with or without an authenticated user.

I could try a workaround with a parameter but I found a simpler and cleaner solution: theVaryByCustom parameter in OutputCache attribute.

Finally, here is the code of my controller :

   1:  [OutputCache(Duration = 3600, VaryByCustom="UserConnected", Location = OutputCacheLocation.Client)]
   2:  public ActionResult Index()
   3:  {
   4:      return View();
   5:  }



And the last thing that we need... Put the following code in Global.asax.cs:

   1:  public override string GetVaryByCustomString(HttpContext context, string arg) 
   2:  {
   3:      return arg.ToLower() == "userconnected" ? User.Identity.Name : string.Empty;
   4:  }

With this custom parameter for OutputCache attribute, we can have a cached page when there is no authenticated user and one cached page by User. It is perhaps not the solution to all your problems but it shows a nice utility of "VaryByCustom".

Facebook C# SDK and logout on Windows Phone

Facebook C# SDK and logout on Windows Phone


(Facebook C# SDK version: 5.4.1.0)

Most tutorials explain how to connect to Facebook for a Windows Phone application... But the logout is rarely mentioned while it is a very important feature for the users of your application.

So, how can you propose the possibility of logout to your users? We suppose that you already have a WebBrowser used for the login: we will call it "FacebookWebBrowser".

To make a logout from this WebBrowser, you just have to do that:

   1:  FacebookWebBrowser.Navigate(new Uri(String.Format("https://www.facebook.com/logout.php?next={0}&access_token={1}", _loginUrl, _accessToken)));

The _loginUrl comes from the "GetLoginUrl" method (from the Facebook C# SDK) and the_accessToken comes from a previous login on Facebook.

Nothing complicated but very useful to know!

Windows Azure and Application Pool Timeouts

Windows Azure and Application Pool Timeouts


This article may help you if you use Windows Azure and you want your application to always responds as quickly even after a long period without use...

With default parameters, your app pool is shut down after 20 minutes of inactivity and your application will take a bit more time to respond.

You can simply change the settings if you want your application pool is never shut down:

- First step: create a new folder called "tasks" at the root of your Web Project and add a new file called "timeout.cmd" with this line of command: 

   1:  %windir%\system32\inetsrv\appcmd set config -section:applicationPools -applicationPoolDefaults.processModel.idleTimeout:00:00:00

Once the file created, you need to put the "Copy to Output Directory" property to "Copy Always".



- Second step: add this into ServiceDefinition.csdef (at same level than "<Sites>", "<Endpoints>", ...):

   1:  <Startup>
   2:        <Task commandLine="tasks\timeout.cmd"
   3:              executionContext="elevated" />
   4:  </Startup>

Programmatically remove HTTP response headers

By default, all the responses of your server will be sent with some embarrassing details...



For an ASP.NET MVC web application, you have these headers :


  • Server: which is added by IIS.
  • X-AspNet-Version: which is added at the time of Flush in HttpResponse.
  • X-AspNetMvc-Version:which is  added by MvcHandler in System.Web.dll.
  • X-Powered-By: which is added by IIS.

Hackers will be happy to know the exact version of the used Framework: if your server has not been updated for a while and a major security vulnerability was found for the version of the Framework you are using, you will help them...

Moreover, these headers add a weight to all your responses (a few bytes, but I like optimizing...)

If you want to remove these headers, here are the steps to follow:

1) Removing the Server header: go to Global.asax.cs, add the Application_PreSendRequestHeaders event with this code:

   1:  protected void Application_PreSendRequestHeaders(object sender, EventArgs e)
   2:  {
   3:      var app = sender as HttpApplication;
   4:      if (app == null || !app.Request.IsLocal || app.Context == null)
   5:          return;
   6:      var headers = app.Context.Response.Headers;
   7:      headers.Remove("Server");
   8:  }

2) Removing the X-AspNetMvc-Version header: go to Global.asax.cs, modify theApplication_Start event with this code: 


   1:  protected void Application_Start()
   2:  {
   3:      ...
   4:      MvcHandler.DisableMvcResponseHeader = true;
   5:      ...
   6:  }

3) Removing the X-AspNet-Version header: edit the web.config and add this element in the system.web section:

   1:  <system.web>
   2:      ...
   3:      <httpRuntime enableVersionHeader="false" />
   4:      ...
   5:  </system.web>

4) Removing the X-Powered-By header: edit the web.config and add this code in the system.webServer:

   1:  <system.webServer>
   2:      ...
   3:      <httpProtocol>
   4:          <customHeaders>
   5:              <remove name="X-Powered-By" />
   6:          </customHeaders>
   7:      </httpProtocol>
   8:      ...
   9:  </system.webServer>

The work is done, the responses of your server will be lighter and will not give important information about its versions.