MVC: The default ITempDataProvider is now CookieTempDataProvider

[ryanbrandenburg]

Summary

The default ITempDataProvider is now CookieTempDataProvider (previously it was SessionStateTempDataProvider). This was done to avoid having to configure session state for basic usage.

As is usual with our announcements, this thread is locked to avoid spamming users subscribed to aspnet/Home. Use aspnet/Mvc#5893 for discussion and questions.

Impact

We expect that for most usage of TempData this will be a relatively seemless change, however if you make heavy use of TempData you may want to consider using SessionStateTempDataProvider.

If you wish to keep using SessionStateTempDataProvider then you must include the SessionStateTempDataProvider services and Session middleware as in the snippet below.

public void ConfigureServices(IServiceCollection services)
{
    service.AddMvc()
           .AddSessionStateTempDataProvider();
    services.AddSession(o =>
    {
        ...
    });
}

public void Configure(IApplicationBuilder app)
{
    // UseSession must appear before UseMvc
    app.UseSession();
    app.UseMvc();
}

Choosing between cookie and session

CookieTempDataProvider is simple to set up, but browsers put limits on the size of cookies and on the number of cookies that can be stored per-site. If you're storing lots of data you may want to use SessionStateTempDataProvider.

We do not recommend storing sensitive information in TempData. As defense in depth, CookieTempDataProvider uses DataProtection to encrypt the values stored in TempData. SessionStateTempDataProvider is the most secure option since it keeps data on the server.