C# How can I persist Session or Cookie information after an OAuth redirect?

I'm having users login to my site using Facebook. They are sent away from my site to Facebook and then redirected back after they have given the site permission. The problem I'm facing is accessing the Session variables I set before they left the site. When the user returns to the site an entirely new Session is created. The strange thing is if the user navigates the site, some pages the original session will be accessible, and sometimes the newly created session. I've tried creating cookies: Response.Cookies["user"]["LoggedIn"] = "true"; As long as t开发者_JAVA技巧he user hasn't left the site I'm able to access those cookies fine, but as soon as soon as they leave and come back I don't seem to be able to access those either. So my question is what is the best way to persist data from before before a user is sent away from the site to when then are redirected back?

AccountController:

public void Login()
{
    Session["BeforeLogin"] = "foo";
    redirect(FacebookUrl);
}

//Where Facebook redirects the user back to
public ActionResult OAuth(string code, string state)
{
    if (LoginSuccessful)
    {
        Session["LoggedIn"] = true;
    }
    return View();
}

HomeController:
    public HomeController()
{
    setLoggedInSession();
}

public void setLoggedInSession()
{
    //This is where I'm having the inconsistency
    string foo = Session["BeforeLogin"];
    ViewData["LoggedIn"] = Session["LoggedIn"];
    //It'll either be BeforeLogin is null and LoggedIn is true
    //or BeforeLogin will be "foo" and LoggedIn will be null
}

EDIT: Some new information about this issue. Doing some testing I've found that the Session seems to work fine when I'm only using a single instance. When I do high availability though (running 5 instances) is when I start experiencing the issues. Most noticeably in IE. My hypothesis is that when you're redirected back to the site from Facebook you're getting a different instance than you left and it creates a new session before it manages retrieves the original one.

My guess is you are using the default mode for the session state, which is cookie based in proc mode.

With default mode the behaviour you describe is expected. You are setting values in memory of a single process of a single VM, which will not magically go to another VM or process. And since Azure is free to route your requests to any instance, it is only by luck you can get the same session value you set. Actually if you try long enough you should see that even with a single instance your session values would disappear as VM reboots, or IIS recycles your worker process.

There is quite a bit of informatin in http://msdn.microsoft.com/en-us/library/ms178586.aspx on session state modes.

But my recommendation is avoid using sessions state. By the time you master sessions you would be well familiar with the http processing in IIS pipeline, that you will not need this abstraction anymore.

AppFabric Caching: "Consistent development model across both Windows Azure AppFabric and Windows Server AppFabric. Secured access and authorization provided by the Access Control service." It's non-resident to any one instance.

If you want to use a persistent cookie, you want something like this:

Response.Cookies.Add(new HttpCookie("name", "value") { Expires = DateTime.UtcNow + TimeSpan.FromDays(7) });

If the cookies are breaking, you could solve this by adding a query string parameter in the callback Url, then stuff it back into your session data if the query string parameter is present.

The Facebook app callback doesn't fail validation when dynamic query string parameters are sent, and passes them back the same as they are sent in.

The trouble is when Facebook makes the callback there is no session cookie passed in the request, so .Net creates a new one. You should see this if you debug whilst running fiddler.

If you want to pass a variable put it in the callback QueryString, or use ajax to make the request. Social Plugins are great for this kind of thing.

Btw hope you are aware storing any kind of authentication/authorisation in session is totally insecure. I think your code is just for debug, but thought I'd mention it.