cross-page sign in; how do I get the Identity object?

Question

I'm having trouble with persisting a signed in user's data across pages.

The only documentation I have found on the subject is here:

http://msdn.microsoft.com/en-us/library/dd570103.aspx

I quote:

"An application should authenticate and sign in a user in the same way on every page. It does so by initializing an Identity object and calling User.SignIn with the Identity object."

How do I do this? Where is the Identity object? Is this supposed to be stored in the browsers local storage, and in that case, how do I retrieve it? I use the code in the resulting signin.js from:

http://msdn.microsoft.com/en-us/library/cc298452.aspx

There was no problem signing in on the first page (application verification token and consent/delegation tokens are OK), but on subsequent pages the _user object is null because it simply has not been initialized and signed in.

Any help is appreciated!

Regards,

/ArlaHaren

Answer 1

Hello ArlaHaren,

You can store the Consent Token you received after the initial signin in a database or cookie, which you can process the same way to get the Delegation Token (but never store the Delegation Token in a cookie!). You can then use the DelegatedAuthIdentity class to create the identity for User.SignIn.

Answer 2

Hi again ChrisW_, and thanks for another quick helpful reply!

Ok, I was under the impression that the toolkit somehow handled this automatically. 

Cited from http://blogs.msdn.com/messenger/archive/2009/03/25/introducing-cross-page-support.aspx

"If you are a web application developer who has already integrated with Windows Live Messenger Library, the good news is that is no code change is required in order to ‘turn-on’ cross-page support. Applications that directly use the Messenger JavaScript Library should simply continue to create a user object and sign-in the user in each page. The Library will automatically use locally stored information to resume the user session as the page loads."

Any idea what they mean with that?

Anyway, I will try your approach and hopefully that will solve it for me!

Regards,

ArlaHaren

Answer 3

A consent token is used to prove that an application is allowed to sign-in a user to Messenger on the user’s behalf. A best practice for applications is to obtain consent from the user only once and store the token securely. If the application already has the consent token for a user it can calculate a delegated-authentication token and pass it to the DelegatedAuthIdentity in order to sign the user in. When the delegation token is reused cross-page navigations, the Messenger Web Toolkit can resume the user session.

When the DelegatedAuthControl is used, a new consent token is obtained from the user. In those cases, the computed delegation token will also change and a previous user session cannot be resumed.

I was sorry to hear that you did not find our documentation clear enough in that sense; we will work on improving that, please continue to provide feedback.

Regarding the blog post that you have mentioned, if an application:

·         Is using our UI Controls

·         Using the DelegatedAuthControl

·         Using the legacy SignInControl

it should not take any programmatic action to maintain a Messenger user session cross-page navigation.

 

Hope this helps,

Offir Bakshitz [MSFT]