locked
Strange Sign in/session status behaviour RRS feed

  • Question

  • I'm using the Live SignInButton control and I've got a LiveConnectSession declared at the App level so that when the user signs in, the session is available across the application until they sign out.

    I am, however, seeing some strange behaviour with the button and the SessionChanged event as I navigate around my app.

    Starting from the main page, I click on the button that takes me to a page that (a) allows me to sign in and (b) select a file from SkyDrive for downloading. At this stage, the session hasn't been established so the button says "Sign in". I tap on the button, authenticate, approve the app, and then I see a list of files and the Live SignInButton shows "Sign out". So far, so good.

    If I navigate back to the main page and then click to go forwards to the page again, the page sees that it has an active session so retrieves the list of files again. However, it then receives a SessionChanged event with a null session, despite the fact that it can continue to access the SkyDrive! Furthermore, the Live SignInButton is showing "Sign in".

    Not so good.

    I'm confused. The session should still be valid because it isn't dependent on the lifetime of the page that I used to authenticate since it is preserved at the App level. Also, the app is quite clearly able to continue accessing SkyDrive, which is bizarre in itself given that the SignIn button believes I haven't signed in.

    If I change the scope list defined with the SignIn button so that "wl.offline_access" is included, that fixes the behaviour of the SignIn button so that it now remains showing "Sign out" until I explicitly sign out.

    This seems to me to be a bug in the SDK given that you shouldn't really have (a) the button saying you need to sign in but (b) the code still able to access the SkyDrive.

    Unless I'm misunderstanding something?

    Philip

    Thursday, February 16, 2012 3:48 PM

Answers

  • Hi Philip, this sounds like a bug in the SDK.  However, is there a reason that you don't want to ask for the wl.offline_access scope?  Without that scope, your app would have to ask the user to sign-in and give consent each time the user uses the app.  Unless that's what you want (and I would like to hear the reasons), I would highly recommend that you add the wl.offline_access scope.

    Thanks.


    Shelly Guo - MSFT

    Tuesday, February 21, 2012 8:06 PM

All replies

  • Hi Philip,

    Are you building JavaScript app on Windows 8 developer preview?

    When you use the Sign in control, it is assumed that you rely on the Library to maintain the session. Mostly you can simply use the Library to access Live REST API without consuming the session instance explicitly on your own. What is the scenario that makes your app have to hold the session instance in the app level?

    If you do need to do that, you may want to implement your own Sign in button logic, or try to be consistent with the Library session state (via the sessionChange event).

    Thanks,

    Lin

    Friday, February 17, 2012 7:00 PM
    Moderator
  • Hi Lin

    No, it is a C# app on Windows Phone.

    I understand your point about being consistent with the Library session state, and I accept that there is a sessionChange event firing that I should then be using to clear out my record of the session. I do find it interesting, though, that the session does seem to be valid despite the sessionChange firing, and I also find it interesting that simply having wl.offline_access in the scope allows me to offer a more pervasive experience to the user.

    Essentially, I don't want the user to have to keep on signing in to Windows Live *during the execution of the application* every time they want to access SkyDrive. To my way of thinking, they should be able to sign in once and that session remains valid until they either sign out or the application quits. It seems to me though, and it may be that I have mis-implemented some logic, that without wl.offline_access in the scope, the user is expected to sign in on with every attempt to access SkyDrive.

    It may be the page flow that I'm going through. Main page -> SkyDrive page (which doubles up as sign-in and file browser). If the user goes back to main page and then forward to SkyDrive page again, the latter is going to be constructed afresh which means that the SignIn control may not be aware of the fact that I have a live session already? If that is the case, I'm not sure how others have managed to avoid this unless they just don't present the SignIn control again.

    That may be it ... I've just tried the new release of Freda which has the sign-in authentication process on a separate page to the file browsing page. I can navigate away from the file browsing page back to the main page and then forwards again to the file browsing page without any problems. BUT if I tap the button to take me to Freda's SkyDrive authentication page, one might expect to be presented with the SignOut button but, no, you see the SignIn button and if you then go back to the file browsing page, it says that I need to sign in.

    So the experience does seem to be consistent if you don't have the wl.offline_access scope defined: the SignIn control does NOT accurately track the state of the session when it is freshly created. I don't know what happens under the hood when the scope is modified to include wl.offline_access but it doesn't really make sense to me that a developer would need to add that in order to have the button work properly.

    Philip

    Saturday, February 18, 2012 10:46 AM
  • Hi Philip, this sounds like a bug in the SDK.  However, is there a reason that you don't want to ask for the wl.offline_access scope?  Without that scope, your app would have to ask the user to sign-in and give consent each time the user uses the app.  Unless that's what you want (and I would like to hear the reasons), I would highly recommend that you add the wl.offline_access scope.

    Thanks.


    Shelly Guo - MSFT

    Tuesday, February 21, 2012 8:06 PM
  • Hi Shelly

    Thank you for confirming my suspicions.

    I am perfectly happy to add the wl.offline_access scope in order to have the consistent experience I'm looking for. My main reason for wanting to remove it was to try and trim down the list of things that the user sees when the application is requesting access - the screen they see after authenticating. Adding wl.offline_access translates for the user to "allow this app to access SkyDrive anytime" (or something like that - I don't have the app running in front of me at the moment) and may be a bit "scary" for the user.

    To be honest, I'm not really sure that I understand what adding wl.offline_access *should* do differently for the application. The explanation of the various scopes in Microsoft's documentation could do with a bit of expansion ;-).

    So it really was just to try and reduce the number of things the user was being asked to grant access to (I only want to download and upload files) but I am OK with using the offline scope to get me a working solution.

    Thanks.

    Philip

    Wednesday, February 22, 2012 3:49 PM