Introduction to the problem
It’s not uncommon when upgrading to SharePoint 2013 from a previous version of SharePoint that you’ll get encoded claims usernames in the places you may have seen normal usernames (DOMAIN\Username) syntaxes before. In my case it was a matter of finding a ton of custom code and have it check whether the username was a claims encoded username or not.
This is what we saw:
However, what we really wanted our code to output was this:
There’s a good reason for why the username that is claims encoded look the way it does. The format tells us what type of claim it is. Wictor has done a nice breakdown and explained the claims here: http://www.wictorwilen.se/Post/How-Claims-encoding-works-in-SharePoint-2010.aspx
The solution to this problem
There’s a pretty simple solution for this that it looks like a lot of people are missing out on. The code snippets I’ve seen in the last project are all parsing the string manually with custom logic and then trying to determine on a string.split() if it is a claim and what type of claim it is.
Instead of going down that dark and horrible road, you should take a look at the built-in functions in the API that does this just fine for us:
Since I saw so many places in the previous few projects where people have been referencing custom methods for string-splits to sort out the claims usernames into default domain\username formats, I thought you’d benefit from knowing that there’s a built-in method for that. Nothing fancy, but worth to know about it.
Check out these resources for additional and more in-depth information about related things:
Programmatically converting login name to claim and vice versa, by Waldek Mastykarz
Enjoy this quick tip.
Latest posts by Tobias Zimmergren (see all)
- Office 365 Dev Tip – Office 365 Patterns and Practices – Notes from the field - July 28, 2015
- Office 365 Dev Tip – Getting Add-in (App) Information for Add-ins (Apps) on a specific Web - July 28, 2015
- Office 365 Dev Tip – Getting all Apps from your Tenant App Catalog using the Office 365 (CSOM) API - July 27, 2015