Use Cookies and Session To Store TempData In ASP.NET Core
If you ever used TempData in ASP.NET MVC, you are probably aware that by
default TempData is stored in Session state. This means the web application must
have sessions enabled. Luckily, ASP.NET Core 2.0 provides two TempData providers
- Cookie based and Session State based. To that end this article shows how to
use both of them in an ASP.NET Core application.
If you are unfamiliar with TempData dictionary consider reading
this and
this
first.
Cookie based TempData
By default, ASP.NET Core 2.0 uses cookies based TempData provider. This means
TempData values are stored in cookies on the client machine. Since TempData is
stored in cookies you don't need Session state enabled through the session state
middleware. Storing TempData in cookies can be useful when :
- The data being stored in TempData is small in size.
- Web application is part of web farm and you don't want sticky sessions.
Since cookie based TempData is used by default you don't need to do any
configuration to use it. Just store and retrieve TempData key-value pairs as you
normally do. An example follows :
public IActionResult Index1()
{
TempData["message"] = DateTime.Now;
return View();
}
public IActionResult Index2()
{
return View();
}
The above code shows two actions - Index1 and Index2 - of HomeController. The
Index1() action stores a date-time stamp in TempData dictionary with a key name
of message. The Index1 view simply offers a hyperlink to navigate to
Home/Index2. The Index2() action returns Index2 view. The Index2 view reads
TempData and shows the value of message to the user.
Index1 view is shown below :
<h1>Index 1</h1>
@if (TempData.Peek("message") == null)
{
<h2>TempData has not been set.</h2>
}
else
{
<h2>TempData has been set.</h2>
}
<br />
<a asp-controller="home" asp-action="index2">
Go to Index2
</a>
As you can see, the Razor code checks whether message has been stored in
TempData or not. It does so using the Peek() method of TempData. Since we use
Peek() the key won't be removed from TempData. Accordingly a message is
displayed in the browser informing the status of message key.
An anchor tag helper renders a hyperlink that points to the Index2() action
of HomeController.
The following figure shows a sample successful run of this view :

When user clicks on the hyperlink rendered by Index1. The value of message is
outputted in the browser. Markup of Index2 is shown below.
<h1>Index 2</h1>
<h2>@TempData["message"]</h2>
<br />
<a asp-controller="home" asp-action="index1">
Go to Index1
</a>
Index2 simply reads the TempData dictionary and outputs the date-time stamp
value in the browser. A hyperlink allows the user to go back to Index1. The
following figure shows a sample run of Index2.

How do we know that TempData is really using cookies. Run the application
with F12 tools and locate the cookies option. The following figure (FireFox)
shows the cookie used by TempData for storing the values.

The cookie value is Base64 encoded. As you might have guessed, since a
cookies are being used to store TempData all the limitations of cookie storage
apply (browser support, size etc.).
Let's now see how to use Session State based TempData instead of cookie
based.
Session state based TempData
To enable Session state based TempData storage you need to enable sessions
using middleware and you also need to change the default provider. The following
code shows how :
public void ConfigureServices(IServiceCollection
services)
{
services.AddMvc().AddSessionStateTempDataProvider();
services.AddSession();
}
public void Configure(IApplicationBuilder app,
IHostingEnvironment env)
{
app.UseSession();
app.UseMvcWithDefaultRoute();
}
The ConfigureServices() calls AddSessionStateTempDataProvider() to
switch the default TempData provider to SessionStateTempDataProvider. It also
calls AddSession() to enable in-memory session state for the application. The
Configure() calls UseSession() to use the session state middleware.
The HomeController and its actions - Index1() and Index2() - remain
unchanged. If you run the application the final outcome will be the same as
before. This time, however, there won't be CookieTempDataProvider cookie.
Instead, you will have Session cookie as shown below :

Session state based TempData can come handy when your application is already
using session state for other purposes. Also, if you intend to store bigger
chunks of data in TempData cookie based storage might not serve the purpose and
you may want to switch to session based TempData. To read more about TempData
and TempData providers go
here.
That's it for now ! Keep coding !!