Monday, September 16, 2013

In the meantime: Communardo Techblog

Work is keeping me quite busy lately. If it fits to business context I usually post articles in the Communardo Techblog of my employer Communardo Software.
My last adventure was dealing with multilingual content and how you can use the new Content Editor Web Part in SharePoint 2013 to display content in multiple languages:
They are in German but you might find some useful PowerShell snippets in there. Stay tuned.

Sunday, April 14, 2013

ShareCamp 2013

I was at my first ShareCamp in UnterschleiƟheim this weekend and it was fun. Lots of interesting sessions and people. I also gave a session on the topic Custom Indexing Connectors:

Externe Systeme in die SharePoint-Suche integrieren mit Custom Indexing Connectors

Click the link to get the slides on Slideshare (in German, sorry). I was surprised by the interest in this topic, thanks to all people who did attend!

Friday, February 15, 2013

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 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 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 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)

Sunday, February 3, 2013

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=, Culture=neutral, PublicKeyToken=24eec0d8c86cda1e">
  <Namespace Name="System.Device.Location">
   <Class Name="GeoCoordinateWatcher" />
   <Class Name="GeoPosition" />
   <Class Name="GeoPositionChangedEventArgs" />
   <Class Name="GeoPositionStatusChangedEventArgs" />
 <Assembly Name="Microsoft.Phone, Version=, Culture=neutral, PublicKeyToken=24eec0d8c86cda1e">
  <Namespace Name="Microsoft.Phone.Controls">
     <Class Name="WebBrowser">
      <Method Name="set_IsGeolocationEnabled"/>

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.

Saturday, January 19, 2013

Windows Phone Apps, SharePoint 2013 Online and Getting Free Development Started Using Visual Studio Express

Over at Christian Heindel's blog I read the post about authenticating with SharePoint 2013 from a Windows Phone app and thought I'd give it a try.

If you are impatient and just want to start developing here is what you have to do to get your development system on Windows 8 up and running:

Setting up the Development Environment

First I needed to set up my development environment. My operating system is a Windows 8 Pro and has until today been SharePoint-free. I used only Express editions of Visual Studio which you can get for free here.

Since I had already developed Windows Phone apps I had Visual Studio Express 2012 for Windows Phone installed and ready.

Next I needed to install the Microsoft SharePoint SDK for Windows Phone to get the necessary SharePoint assemblies. Seems like version 7.1 of the SDK is the only one available. Quote from the download page:
The Preview SDK installs Windows Phone CSOM libraries for Windows Phone, SharePoint Auth library for Windows Phone and Windows Phone Project Templates, which can be used to build Windows Phone 7.1 Applications against SharePoint 2013 Preview or SharePoint 2010.
The SDK setup did not recognize my Visual Studio Express 2012 and demanded a Visual Studio 2010 to be present. I searched some time for a newer SDK but did not find any.

So I sighed and installed Visual C# Express 2010. Next I installed SP1 via Windows Update so I could install Windows Phone SDK 7.1.

On Windows 8 I got a compatibility warning for the Windows Phone SDK and an error at the end of the setup which is related to XNA Game Studio. Just ignore it.

After the phone SDK I could finally install Microsoft SharePoint SDK Preview for Windows Phone 7.1. (Update: Install the final version instead, see below for details.)

The SharePoint SDK setup put the following assemblies to C:\Program Files (x86)\Microsoft SDKs\SharePoint\v15.0\Phone\v7.1\Libraries:
  • Microsoft.ProjectServer.Client.Phone.dll
  • Microsoft.SharePoint.Client.Phone.dll
  • Microsoft.SharePoint.Client.Phone.Runtime.dll
  • Microsoft.Sharepoint.Client.Taxonomy.Phone.dll
  • Microsoft.Sharepoint.Client.Userprofiles.Phone.dll
  • Microsoft.SharePoint.Phone.Application.dll

Quick Win Using One of the Sample Apps

You can download sample solutions from the Dev Center Page Christian linked to.

I chose the sample solution SharePoint 2013: Store and retrieve SharePoint list items on a Windows Phone since it sounded like it would be easy to test.

If you don't have a SharePoint 2013 Online site to test you can sign up for free for an Office 365 Developer Site.

After downloading the solution I opened it with Visual Studio Express 2012 for Windows Phone and built it - which succeeded without any problems. This was surprising since I expected that I have to add Microsoft.SharePoint.Client.Phone.Auth.UI.dll like Christian needed to do.

I didn't have to change the sample at all, it worked right out of the box. Which is good since Microsoft.SharePoint.Client.Phone.Auth.UI.dll is not present anywhere on my machine. The SharePoint-related references of the sample app look like this:

Apparently Authenticator in my case is coming from Microsoft.SharePoint.Client.Phone.Runtime.dll.

Now it was time to test, so I created a list, added a test item, modified TargetSiteUrl and TargetList in the sample app accordingly and that's it:

Hello SharePoint in the Cloud!

Update: SharePoint Preview SDK for Windows Phone 7.1 vs. Final Version

Seems like MSDN and the Sample Solutions need to be updated - they link to and reference the SharePoint Preview SDK while there is already the final version available!

The SharePoint SDK for Windows Phone 7.1 is available for download.

When building the sample projects you will now get errors for type Authenticator:
Error 1 The type or namespace name 'Authenticator' could not be found (are you missing a using directive or an assembly reference?)
The solution indeed is to add a reference to Microsoft.SharePoint.Client.Phone.Auth.UI. There are two other assemblies which are new in the final SDK, so if you are missing these make sure you don't have the preview installed:
  • Microsoft.SharePoint.Client.Search.Applications.Phone.dll
  • Microsoft.SharePoint.Client.Search.Phone.dll
Thanks Christian in the comments.