How to Change Accounts once you are Logged In to a Site (using SharePoint SDK for Windows Phone)

We need a set up for today's post:

• You created a Windows Phone using the SharePoint SDK for Windows Phone. 
• A user logs in to Site A using his Microsoft Account*.
• He checks the box Keep me signed in. 
• Later he wants to log in to Site B using different credentials than the previous one.

He will get an error:

Error: Access Denied,  "You are not a member of this site."

The problem: Site A credentials will be used for accessing Site B. The user is offered no way to enter new credentials for Site B.

Sticky Credentials

When using MicrosoftOnline as authentication method with the SharePoint SDK the user is presented with a web-based login dialog the first time he accesses the site. The user enters his credentials and can choose to stay signed in by checking Keep me signed in.

If he chooses to be kept signed in the login dialog will not be presented again.

"Keep me signed in" (the German version)

And this can be a problem. These credentials are the definition of "sticky" as it seems to be impossible to get rid of them via code.

You might ask: Why do we want to get rid of them in the first place?

Here's why: If the user tries to access another site (Site B) which requires different credentials than Site A his Site A credentials will still be used. This of course doesn't work and he will be presented with the nice "Access denied" message above.

Discarding the Credentials: #fail

I tried quite some time to delete the sticky credentials via code.

How are credentials stored? They might be cached AES-encrypted to the local store along with cookies from the browser. These cookies will be obtained from the web browser component used for logging the user in (the browser being part of the embedded XAML-based login dialog).

But this caching of cookies needs to be enabled explicitly by setting CookieCachingEnabled to true. It's disabled by default. In my attempt to dispose the sticky login I was lead astray by these methods related to caching:

• Authenticator.ClearAllApplicationSettings
• Authenticator.ClearAllCookies
• Authenticator.ClearAllCredentials

While these might clear the internal cache, they didn't solve my problem. The user was still logged in with his Site A credentials.

I then started to believe (and still do) that the login information is simply stored as "normal" cookies somewhere. I verified that there are lots of cookies related to my SharePoint activities. I used the GetCookies extension method for WebBrowser to get a list of cookies which revealed 14 cookies for the domain login.microsoft.com: WLOpt, PPAuth, MSPPre, MSPCID, RPSTAuthTime, MSPVis, MSPSoftVis, MSPRequ, MSPBack, PPLState, RPSTAuth, MSPAuth, MSPProf, MH.

Unfortunately this cookie collection is read-only, so no chance of modifying (or clearing) it. And I still don't know how to manipulate these cookies. If you do then help me out on StackOverflow!

Offering the User to Log In with Different Credentials

In the end I chose a workaround which is rather simple. I navigated to login.microsoftonline.com in the desktop browser and used Fiddler to look at the requests that were being made when I logged out by actively clicking on Sign Out.

It navigates to https://login.microsoftonline.com/logout.srf. And that's all it takes.

In code, navigate to the above URL and the next time the user accesses any site he will see this:

The highlighted link says: "Sign in with another User ID"

(Usability note: On the right site the dialog is cut off because it is too wide for the phone screen. It's not the screenshot being cropped. Ugly.)

But finally the user can click the highlighted link to sign in with another ID.

---

* Forgive me if I sometimes refer to the credentials being entered by the wrong name. There are just so many terms to choose from (some old, some new).

• Microsoft Online Services ID
• Microsoft Account
• User ID
• MicrosoftOnline (= name of authentication method in code)

Why do Windows Phone Apps for SharePoint need access to Location Services?

I recently did some programming with the SharePoint SDK for Windows Phone. (See my last post for details on how to set up your development environment.) When running the Store Test Kit I noticed that my app needed the Location Capability (ID_CAP_LOCATION).

This was strange and I decided to investigate.

Windows Phone App Certification Requirements when using Location Services

Why do I even care? Two reasons:

1. It might push away users if they get the feeling my app wants to spy on them.
2. Apps using Location Services have to follow certain rules. If they don't they can't enter the Store.

When an app uses the user's location you have to include or link to a privacy policy in your app explaining how you are going to use the collected data. You can find the certification requirements over here. Reading them carefully can save you some time as I had to learn the hard way.

Fair enough, but I wasn't using any actual location data. Apart from that the requirement leaves some room for interpretation (emphasis mine):

§2.7 The following requirements apply to apps that receive the location of a user's mobile device

What if I am using location-related classes but never use them? I have the feeling nobody won't care about that. So I decided to include a privacy policy (as demanded by §2.7.2) to be sure:

§2.7.2 The privacy policy of your app must inform users about how location data from the Location Service API is used and disclosed and the controls that users have over the use and sharing of location data. This can be hosted within or directly linked from the app. The privacy policy must be accessible from your app at any time.

How does Capability Detection by the Store Test Kit work?

Open the Store Test Kit via Project context menu.

Why does my app suddenly uses Location Services? How does the Store Test Kit determine that my app has to include the capability ID_CAP_LOCATION?

You can look up what APIs require which app capability in Rules.xml, a file included in the Windows Phone SDK. On my machine it can be found in C:\Program Files (x86)\Microsoft SDKs\Windows Phone\v7.1\Tools\Marketplace.

Here is the relevant part of Rules.xml showing what needs ID_CAP_LOCATION:

<Capability ID="ID_CAP_LOCATION" Type="Security">
 <Assembly Name="System.Device, Version=2.0.5.0, Culture=neutral, PublicKeyToken=24eec0d8c86cda1e">
  <Namespace Name="System.Device.Location">
   <Class Name="GeoCoordinateWatcher" />
   <Class Name="GeoPosition" />
   <Class Name="GeoPositionChangedEventArgs" />
   <Class Name="GeoPositionStatusChangedEventArgs" />
  </Namespace>
 </Assembly>
 
 <Assembly Name="Microsoft.Phone, Version=7.0.0.0, Culture=neutral, PublicKeyToken=24eec0d8c86cda1e">
  <Namespace Name="Microsoft.Phone.Controls">
     <Class Name="WebBrowser">
      <Method Name="set_IsGeolocationEnabled"/>
     </Class>
  </Namespace>
   </Assembly>
</Capability>

Why does the SharePoint SDK for Windows Phone use Location Services?

To determine where the SharePoint SDK uses location-related functionality I had a look into the assemblies included in the SDK - and found something in Microsoft.SharePoint.Phone.Application.

Normally I use ILSpy to look at the implementation of framework assemblies, but ILSpy unfortunately doesn't support full text search as of this writing. So I tried the free JustDecompile by Telerik and this worked nicely.

Searching for GeoCoordinateWatcher lead to the class ModifyItemViewModelBase.

It seems like location services are used in relation with the Geolocation field type which is new to SharePoint 2013. A method named OnGeolocationStatusChanged creates instances of GeolocationFieldViewModel which in turn stores geo coordinates.

I could not find where OnGeolocationStatusChanged is used in any of the SDK assemblies. It's public and virtual so maybe it's just there to use for us. Seems the documentation is a bit scarce here as well.

What does this mean for me as app developer using the SharePoint SDK?

Seems like I have to accept the fact that access to location services is baked into the SharePoint SDK libraries. And that I have to explain this to the wary folks visiting my app in the Store.