This fix applies to legacy ASP.NET Web Forms or ASP.NET MVC applications running on .NET Framework and using DotNetOpenAuth. If you are building a new application on ASP.NET Core, use the built-in external authentication providers instead of this older pattern.
Problem
I was helping a friend wire up Facebook OAuth login in an older ASP.NET application using the DotNetOpenAuth extensions installed from NuGet.
The code looked like this:
Uri ui = new Uri("~/Login.aspx", UriKind.Relative);
var fbClient = new DotNetOpenAuth.AspNet.Clients.FacebookClient("***", "***********");
fbClient.RequestAuthentication(context, ui);
The problem is that RequestAuthentication expects an instance of HttpContextBase.
If you try to pass HttpContext.Current directly, it fails because HttpContext.Current is a HttpContext, not a HttpContextBase.
Why This Happens
HttpContextBase was introduced as an abstraction over HttpContext. This makes ASP.NET code easier to test and easier to work with in components that should not depend directly on the concrete runtime context.
To bridge the gap between the two types, ASP.NET provides HttpContextWrapper.
Solution
Wrap HttpContext.Current in a HttpContextWrapper before calling RequestAuthentication:
var httpContextBase = new HttpContextWrapper(HttpContext.Current);
fbClient.RequestAuthentication(httpContextBase, ui);
Explanation
HttpContextWrapper acts as an adapter. It takes the current ASP.NET request context and exposes it as a HttpContextBase, which is exactly what the DotNetOpenAuth API expects.
So if you are maintaining a legacy ASP.NET application and run into a type mismatch between HttpContext and HttpContextBase, this wrapper is the correct fix.
Modern Note
For new applications, this is no longer the recommended approach. In modern ASP.NET Core applications, external login providers such as Facebook are configured through the built-in authentication middleware, and System.Web, HttpContextBase, and HttpContextWrapper are not part of that model.
