David Martos


Hi,

I need to automatically sign in a user into the system the second time he enters my application. I've tried to do that by using cookies as follows:

if (Page.Request.Cookies["token"] != null)

{

NameValueCollection collection = new NameValueCollection();

collection.Add("stoken", Page.Request.Cookies["token"].Value);

collection.Add("action", "login");

collection.Add("appctx", "SendMessage.aspx");

WindowsLiveAuthLite.WindowsLiveLogin.User user = login.ProcessLogin(collection);

if (user != null)

{

authenticated = true;

}

}

The user object is correctly created but instead of having the "Sign out" hyperlink I have the "Sign in" one. It seems ProcessLogin function is not authenticating the user even the function is returning the right user information.

Any help will be apreciated,

David




Re: Maintaining state

Josh Brown - MSFT


Thanks for the message. This is an issue we are aware of and are working on a solution.





Re: Maintaining state

Sir Darquan

I don't know if this will help you out, but I believe I had that same problem and solved it.

If you are storking the stoken in your own cookie for later use, you have to make sure it is deleted when the user logs out of Windows Live Services.

Code Snippet

if (action == "clearcookie") {

/* This action is called when the user tries to log-out. */

/* insert your clear cookie logic here */

Response.Cookies.Remove("token");

// after cookies are cleared, you must reply to Windows Live ID server

// Confirm successful sign out by sending an http response.

byte[] content;

string type;

Otherwise, your site will still have the cookie with the token in it, and that will always create a valid user, because the token is specific to your site. It seems like that token we store should become invalid at some point, but it doesn't, and that's why your able to create a user when the iframe says they need to sign in. I hope I explained it clearly enough.

Also, I didn't imitate the Login Process. You should use ProcessToken(token, context) instead to create the User object.






Re: Maintaining state

David Martos

Thanks. I will try to use ProcessToken instead of creating the user. By the way, should the context string parameter be the same appctx form parameter passed to the Windows Live service

Thanks





Re: Maintaining state

Sir Darquan

Yeah, context can be the same page, but it doesn't have to be. If the user leaves your site without logging out or closing hte browser, Your token will stil be valid. So if they want to go to a specific page on your site, they should be able to, because they are still validated. While I haven't actually tested if the context needs to be the same the one from appctx, I would think it should be the page the user came back to.



Re: Maintaining state

Alex Media

I think that the content is the page the user was viewing before signing in... example:

  1. The user visits your site
  2. He browses to the forums
  3. He views a topic and clicks 'Reply' (topic.aspx tid=23452&mode=reply)
  4. He is not authenticated and is redirected to login.live(-int).com
  5. He logs in, live(-int) returns a token to the handler on your website
  6. The handler decrypts the token
  7. The handler redirects you to the page specified in the context (topic.aspx tid=23452&mode=reply in this case)

At least, I think that's what the context should do...





Re: Maintaining state

Sir Darquan

Your steps are 100% correct, for that senerio. What we were talking about was the user is already logged into the site, and we just wanted to process the stoken on another page using the ProcessToken function. In this particular case context seems out of place and that's why I wasn't sure how it should be used.



Re: Maintaining state

Josh Brown - MSFT

This issue boils down to the fact that the iFrame is being fetched from a different server, and sends a different cookie than the one your site uses to keep track of the user. To keep these cookies in sync requires that you know what kind of cookie the auth server is using and use the same kind (session vs persistent). In this early version of Web Authentication, session cookies are always used. We are researching how to use persistent cookies for both when the user requests "remember my password" and the various issues with keeping the control and the site in sync across numerous scenarios. Please stay tuned for updates!