Blog

Issue installing Windows Server 2012 Remote Server Administration Tools (RSAT)

Tue, 25 Jun 2013 00:29:49 GMT

Quick post today to discuss an issue I came across last night. I was trying to install the Windows Remote Server Administration Tools for Windows 8 so I could manage the servers on my home network directly from my laptop (I'm planning con converting a couple of them down to server core rather than having the GUI on them so need to have the tools elsewhere) and I came across this funny issue with the installation.

Basically the process is that you download the tools (which you can get from here if you haven't looked), run the installer and you're done. In theory this is all well and good, but when I ran the installer it appeared to run, tell me it was finished and then leave me with nothing at all. I went hunting around to see if I needed to turn windows features on or something like that to enable the tools (which you had to do with previous versions of Windows, but the documentation says you don't for Windows 8, all the tools should be on by default) but there was nothing there.

The problem in the end is that the tools weren't speaking my language - my language being en-GB specifically (at least that was the flavor of Windows I installed, with the GB locale being closer to AU from a language perspective than the US one). To get the installer to work correctly I had to download and install the en-US language pack and run the installer again. If you don't know how to install a language pack its pretty simple, go in to languages in the control panel and add the language from there. It will then say its "available and ready to download" so follow the link to trigger the download (the en-US one was around 150MB or so, so not huge). Once it's done run the installer again and you're all set!

An animated walk through OAuth in SharePoint 2013

Thu, 20 Jun 2013 07:00:00 GMT

I'm one of these people who is a very visual learner, so when it came time for me to get my head around OAuth in SharePoint 2013 I sat down to read MSDN, and my brain melted a little. So to help me understand it a little better I whipped up a quick animation with Prezi to walk you through the process. It's all based on the MSDN doco (link at the end of the prezi) so there isn't anything new here, but I figured I would share it to see if anyone else found it useful. Enjoy!

View on Prezi.com

Do I need to use HTTPS for my SharePoint 2013 apps?

Wed, 19 Jun 2013 00:50:25 GMT

In my last post where I discussed app URLs and how they should be configured in SharePoint 2013, I made a remark about using HTTPS for apps and that I would go in to that in more detail in a separate post - well here is that post. So the question is "do I really need to use HTTPS for my SharePoint apps?" - and the answer here is "yes", but there are some exceptions to this that I'll cover off here.

SharePoint Hosted Apps

I'm becoming a bigger fan of SharePoint hosted apps more and more each day (despite the whole JavaScript thing) and this question brings up yet another reason for liking them. SharePoint hosted apps run within SharePoint in the app web, and are for all intents and purposes just as secure from the client/server perspective as you make the host web (think of the AJAX components running inside the OOTB stuff), its HTML content coming from SharePoint to the client, so if you would put HTTPS on to your SharePoint site there, then go with HTTPS for the apps there as well - just make sure they match so if you can avoid those browser warnings about 'unsecured content on the page' if some of it comes from a HTTP source and the main page is on HTTPS (think for things like app parts and client side web parts).

Realistically though if we are talking about doing SharePoint hosted apps in an on-prem environment where you are away from all the pesky annoyances of the general Internet, I would say that HTTP is probably gonna be fine - you're not doing any auth in your code (as SharePoint handles authorisation of your app automatically in the app web, so no OAuth or anything like that) so it's all fairly basic stuff. The second you start talking about a farm that is touching the Internet and has people coming externally, I start looking at HTTPS anyway (for SharePoint in general, not just apps) just to keep things tight. The thing to remember when doing HTTPS for your SharePoint hosted apps (and depending on the set up, possible your cloud hosted ones as well) is that you will need a wildcard certificate to cover all of the possible sub-domains that will be created by the URLs for each app, so give that some consideration in your planning for HTTPS as well (not that these certs are usually expensive or anything, but the app scenario can be easily overlooked).

Cloud Hosted Apps

This is the bigger point of concern when looking at HTTPS for apps, and where the "Yes you should use HTTPS" response comes from. The scenarios here revolve around SharePoint being on one server, and your application being on a different one (be it azure or any other web server somewhere else that isn't SharePoint). In this scenario you have your app communicating to SharePoint through the remote APIs that are all web based, and that communication could be passing through any part of the Internet to get from A to B (as opposed to the SharePoint hosted apps which just request data from the client in the same way as browsing the content in SharePoint in the first place). This is the reason you will want to use HTTPS, and in most cases it is actually forced upon you by default.

But doesn't OAuth encrypt my requests for me?

The short answer here is yes - sort of, OAuth will encrypt the tokens in your requests (as SharePoint doesn't use the PLAINTEXT signature method within the OAuth protocol, it all gets encrypted with keys known to SharePoint, ACS and your app), and this is one of the reasons OAuth is great for communication across unsecured channels (regular HTTP) in that you get security in the protocol itself. Now this will generally keep you pretty safe unless your keys are somehow compromised, and in the event that happens you are open to all sorts of potential attacks. Even without the keys being compromised there may be scenarios where replay attacks could be thrown in based on a request being sniffed out as well. The bottom line though is that HTTPS is going to give you a higher level of security between your end points through the use of the certificate to encrypt the whole message (not just the token with the data in it like OAuth does) and will help you avoid having your communication being eavesdropped on (through something like a man in the middle style attack). Oh, also - by default SharePoint will make you use HTTPS for OAuth, which is also a good reason too.

OK, so I'm using HTTPS - does that mean I need certificates for my dev environment too?

Great question - and luckily the answer is no (I say luckily because in the context of needing an SSL cert for your apps you may end up need a wildcard certificate for the app URLs which will cover off multiple possible URLs, and they cost more). You can switch off the in built requirement for the OAuth calls to operate on HTTPS using a little bit of PowerShell

$serviceConfig = Get-SPSecurityTokenServiceConfig
$serviceConfig.AllowOAuthOverHttp = $true
$serviceConfig.Update()

Same script again with $false on line 2 will turn it back on. You'll find that if you are using OAuth with HTTP before you turn this on that SharePoint will throw a bunch of 403 errors at you, so keep an eye out for that.

Isn't SSL hard to set up though?

A question I get from a lot of developers, and before I was actually educated on the matter I might have agreed (I saw Mark Rhodes set it up in a presentation at the Melbourne SharePoint User Group one time from scratch in only a few minutes - granted it was a demo VM environment he had control over, but it really isn't that hard). At the end of the day though it's not that hard, and realistically speaking there aren't a lot of reasons for not using it for any kind of forward facing SharePoint site (especially where users can manipulate data in the site externally). If you want a quick run through of how to set up SSL in SharePoint there are a few guides out there for normal web apps and for Central Admin as well, both worth a read if you want a run down of the process involved.

So that is about the gist of it and my two cents worth on the matter. So to answer the original question of "should my app use HTTPS?" - if you app is running off the SharePoint server, then yes.

Understanding and Configuring App URLs in SharePoint 2013

Mon, 17 Jun 2013 21:52:00 GMT

One of the discussions I have with a lot of developers when the new app model in SharePoint 2013 comes up is around how they configure their environments comes up, and it can be a little tricky to get your head around at times - realistically the configuration of app URLs and how apps will work in an environment is an area that will normally involve the IT pros in your organisation more than the developers, but this is definitely an area where a developer is going to be better off knowing a bit of the infrastructure side of things too, so I wanted to go in to it a bit here.

The App URL

One of the things you will have noticed if you are working with apps already is that they are given unique URLs when you browse to the app web, they are broken up in to a number of different parts, but can look roughly like this:

http://[app prefix]-[app id].[domain name]/[site collection path]/[app path]/pages/default.aspx

Each of these components translates to the following:

App prefix: You specify this in central admin, all app URLs the farm generates begin with this
App ID: This is a unique ID for a specific instance of your app. If your app is installed in more than one site collection each installation will have a unique ID here
domain name: This is the domain name that is used for all of your apps
Site collection path: This is the path to the site collection that the app was installed in (which might be the root, in which case you don't have anything here, but could be something like sites/mysitename)
app path: This is the URL for your app web (which is more or less just a sub site of the site collection, just with more limitations), so it gets a URL like any other sub web would

The most important part to remember here is that every time you install a new app you get a new ID, which means that you are going to need to set up a wildcard DNS entry for the apps, which leads me on to my next point.

DNS Entries

Once you understand that, you can start to look at the domain name part of that which is configured in Central Admin. Lets assume you have a couple of web applications in SharePoint already - portal.company.com and my.company.com - and you want to start using apps in both of these, we need to decide on an appropriate domain name and DNS entry to set up for the apps to run under, and there are a couple of options here:

*.company.com

This would result in app URLs that look like [app].company.com, which would work but creates some issues of its own, the biggest of which is that every single DNS request that doesn't have a specific entry for it in your domain will get directed to SharePoint, meaning that in a day to day operations view its potentially going to be getting a lot of traffic going to it that it won't understand. This approach should be avoided

*.apps.company.com

The approach here is to create a subdomain under your main domain name that would host all the apps, giving your URLs like [app].apps.company.com. While again this approach will work, it does still present some issues. By being a child domain of the parent domains your main web applications are running under you may end up with sensitive information stored in cookies being able to be accessed, which could open the door for a malicious developer to get access to cookies they shouldn't be getting to, which makes this options poor for production use.

*.company-apps.com

In this option we create a new top level domain name to end up with app URLs like [app].company-apps.com. This option gets around all of the potential issues with the other two and is the recommended approach from Microsoft. So the best DNS entry to set up will be one that points everything for a new top level domain name to your SharePoint farm

How SharePoint responds to app requests

The next piece of the puzzle here is around how SharePoint responds to requests for an app web. So if you browse to an app web under the regular URL for your site SharePoint will automatically redirect you to the app URL for the app instead (to protect itself from an app in case it is trying to get access to things it shouldn't be). Now traditionally when we set up a SharePoint web app we end up with a site in IIS that will listen on the appropriate port number and host header for requests to serve them up, but now we have our apps running in a new top level domain, we need to come up with an approach for this so that SharePoint can listen for the requests and send the appropriate content out.

One option is that you could set up an additional binding to one of these sites in IIS to capture traffic based on the host header and port number combination. Again, this will work in basic set ups but has a few problems of it's own with it. Firstly, if you are using SSL (and if you are doing apps you should definitely be using SSL, I'll do another post explaining why for another day though) you will run in to issues with the certificates on the site being for different top level domain names. Secondly you can also get yourself in to trouble with permissions to content databases as well.

The better approach to take with this is to set up a new web application in SharePoint, create it without a host header at all and then go in to IIS and configure it to listen on a unique IP address that your DNS entry points to (so you have unique IP addresses assigned to the web front ends for each web application in this scenario). So this way the IIS site will listen for all requests made to that specific IP address, regardless of the host header or port used, and can serve up your app content from there and have an appropriate SSL cert put in to here as well.

Accessing SharePoint content

The last thing to consider with your app URL configuration is how our new web application will get to SharePoint. The web application that your apps runs under must have access to the content databases for the site collection the app is installed in. So the way a request works from start to finish here is that it comes in to our new apps web app and based on the app URL SharePoint will use the Application Management Service App to look up the appropriate web app, and then it goes looking for the info from that web apps content database.

The simple solution here is to make sure that the application pool for this web app as you use for the content web apps. Now this could mean you use the same application pool across all of the web applications, or that you use different application pools that all run with the same service account, either option is fine here from an authentication perspective.

Alternate access mappings

By default when SharePoint 2013 hit RTM you could only run your apps as part of the default zone in a web application, which limited some of the options for how users could get to your apps. It is now possible to set up multiple app domains and map them to specific zones (this came in the March 2013 public update for SharePoint 2013). There is an article on TechNet that describes how to set this up that is worth looking at if you need to run under different zones.

Scrolling issue with SharePoint 2010 in Google Chrome

Mon, 17 Jun 2013 00:43:00 GMT

Just a quick post today to describe an issue I came across this week with a client of mine. We had recently launched a public facing SharePoint 2010 website and were finding some issues with users not always getting a scroll bar in Google Chrome. I spent some time looking over the issue and it appeared to be very intermittent, with the scroll bar appearing sometimes but not others.

Having a look at it, the issue was caused by the way SharePoint dynamically sets the scroll bar on to the s4-Workspace div. For those who aren't aware, when SharePoint loads a page it blocks the scrolling of the page like a normal web page allows, and substitutes this with a scroll bar on the div with an ID of s4-workspace. What this does is allows the ribbon to always sit at the top of the page, no matter how far down the user scrolls down, which when you think about it is pretty important (if I'm editing text at the bottom of a long page of content, I dont want to have to scroll back up to hit the font size button). The issue in Chrome is that on some page loads the script that dynamically sets the height of the workspace div just wouldn't run, meaning there was no scrolling mechanism at all because the default ones are already disabled.

The problem here though is that this was happening on the out of the box master pages as well as our custom ones, meaning this wasn't an issue we had caused with our branding or CSS, it was built in to SharePoint.

After hunting around through some forums I did find a couple of solutions. The first solution was to remove the content place holder that put the search box on to the page - yes I know this sounds insane, but it did actually work! The search box added some JavaScript to the bottom of the page which I suspect was failing based on the order of scripts loading, thus preventing the others from running correctly. This wasn't a solution that worked for us though as we kind of needed the search box. The second solution I found involved running your own script to set the height, which fundamentally would work, but at a glance could fall victim to the same issues, not to mention needing to re-write some code to run on events like the window resizing or the ribbon changing visibility status - not an impossible task, but would need some testing.

Before I set off on that path though I decided to see if patching the farm to a higher cumulative update level would resolve the issue - I figure someone at Microsoft must have come across this issue, so I wanted to see if it could be resolved with a patch. The customer was sitting at the first CU that was released after Service Pack 1 (which was required as SP1 was kind of broken), so there was a lot of updates to look over. After installing a couple in a dev environment to check if they worked I had some success - Build 14.0.6137.5000 (the April 2013 Cumulative Update) appeared to resolve the issue for both the out of the box master pages as well as our custom one. So we are in the process of rolling this through the pre-production environments as we speak to make sure it doesn't introduce any other issues with it (as you should with a CU) but assuming all goes according to plan, that will go to production and the issue will be resolved, and I won't have needed to write a single line of code to address the issue - which is a pretty good result in my book!

WARNING

After talking to a friend of mine he warned me of some issues raised with the April 2013 CU, which have been recorded by a few people as well. I recommend definitely looking in to this one and testing in a non production environment first. Apparently the June CU fixes these issues, but we aren't sure what else that might break year either, so proceed with caution. The details on the breaks are on Todd Klindt's blog at http://www.toddklindt.com/blog/Regressions/April2013CU.aspx

SharePoint Developer Free Short Course

Thu, 30 May 2013 10:55:00 GMT

This year I've been doing some work with IT Masters for Charles Sturt University to create a new topic for their Masters degree that is specific to SharePoint development. Coming up with a fresh and relevant cirriculum for the topic has been a great challenge for me, and I'm really happy with what we came up with. To help attract people to the topic and to the university though we ran a free version of the course that is essentially the first 4 weeks of the 15 week topic and we posted all the lectures online!

All the code is in a GitHub repository, and all of the videos are on YouTube (embedded below). If you're interested in learning more about the topic, please email me or check out the course info on the website!

You tube playlist of all four lectures

Links to individual lectures

Using the SharePoint Colour Palette Tool

Wed, 17 Apr 2013 10:50:00 GMT

Last week I was introduced to a neat little tool that Microsoft have put together called the SharePoint Colour Palette Tool (which you can download at http://www.microsoft.com/en-us/download/details.aspx?id=38182). Basically this tool will let you come up with a design for SharePoint from a colour perspective - selecting specific colours to be used in a very long and detailed list of places (broken down in to common headings to make it easier).

You get a neat live preview of what these looks like which is kinda nice, and when you save it you get this .spcolor file as the output, which is some XML with a bunch of colours referenced in it. I'll admit this is where I tuned out a little as I had no idea what these were for - but sure enough they do serve a pretty awesome purpose! In SharePoint 2013 there is a feature called composed looks, which I wont go in to in detail here but basically there are a replacement for themes in 2010, and in 2013 when you use the "change the look of the site" thing and you choose a colour set and fonts etc. there, these are composed looks. As part of a composed look you get to specify a colour scheme - and this is where the spcolor files come in to it.

If you go in to a SharePoint 2013 publishing site, head in to site settings and in to the "Themes" gallery (which considering themes are essentially dead is poorly named, but that aside, lets move on). Here you will find a folder called 15, and inside that you will find a bunch of font and palette files - and they are all .spcolor files! So lets go and upload your spcolor file here, note down it's URL as we will come back to it.

Now back in site settings head in to "Composed Looks". Here is a list where we can add our own composed looks. This is a standard SharePoint list and if you create a new item you can create a look by specifying the following:

Master Page URL
Theme URL
Image URL
Font Scheme URL

So master page is obvious, Theme URL will be the URL of the spcolor file we just uploaded, image URL is for a background image to be applied, and font scheme URL is for another spfont file with the fonts specified in it (the colour palette tool won't do these for you).

Add your new item in here with the appropriate values, and you're done! Now when you go to apply a composed look (by going to the "Change the look" link on the site settings page) you will see your new look with your colours in there. You can use one of the out of the box master pages, and you don't need to add an image or font URL, so this gives you a very powerful way to create custom colour schemes without needing to know CSS or anything too complicated from the SharePoint perspective!

Australian SharePoint Conference presentations

Thu, 11 Apr 2013 10:55:00 GMT

Once again I had the chance to present at the Australian SharePoint Conference, which is always a great event and I'm so happy that I was able to make it along this year. As promised in my sessions though, here are the slides and code from my sessions, and if you have any questions please make sure you flick me an email or get me on twitter, always more than happy to chat about things!

Creating custom branding in SharePoint

This is an embedded Microsoft Office presentation, powered by Office Web Apps.

Working with Office Apps in SharePoint 2013

This is an embedded Microsoft Office presentation, powered by Office Web Apps.

Download the code

Detect if WP7 has a data connection

Fri, 22 Feb 2013 09:50:00 GMT

I've been doing some work with Windows Phone 7 development of late, and the other day I got around to submitting my first app to the marketplace ... and it got knocked back! The reason was that the application fell over due to some unhandled exceptions when the app was run without an active data connection.

After a bit of a search I tuned up some code that will let you determine if the phone has an active data connection, which I could implement easily enough and then conditionally run the code that requires an internet connection. You can check for the connection like this:

if (NetworkInterface.GetIsNetworkAvailable())
{
    // do something here
}

Now there are some problems with this though - and not with the code itself, but some "gotchas" that apply to when you debug this code. Firstly, from what I've seen you can't get the emulator to act as if the data connection is off. If you disable your PC's interenet connection your calls will just time out, but this method will still return true.

The next test I did was on the device itself, so I plugged in and set VS to debug from the device, and even when I put the phone in to flight mode it was still returning true. It was only when I unplugged the phone from my laptop all together and ran the app again that I saw what I expected. My best guess as to why this is happening is that the phone treats the USB connection as a data connection, and as such that method will return true.

So the network availability check seems to just test for any kind of network connectivity, not an internet connection specifically. Probably worth knowing and in your code making sure that your HTTP calls and other internet access is still properlly error handled for things like time outs and other errors, and also use this check to try to head off the obvious scenarios where you know for sure there wont be a connection.

SharePoint Saturday Australia 2013 dates

Mon, 28 Jan 2013 09:50:00 GMT

2013 is the fourth year of SharePoint Saturday events in Australia, and I've loved being able to be part of these events since the first one we ran in Sydney back in 2009. With the release of SharePoint 2013 this years run of events promises to be full of great new content from some of our countries greatest community speakers as well as some of our international favourites. We have confirmed the dates for our events this year, and they are as follows:

Perth: 9 March
Brisbane: 11 May
Adelaide: 29 June
Melbourne: 27 July
Canberra: 24 August
Sydney: 19 October

To stay up to date with all the latest news and announcements make sure that you follow us on twitter and like our facebook page for even more info and announcements!

Issues with a custom 404 page in SharePoint 2010

Wed, 19 Dec 2012 09:45:00 GMT

I came across this issue the other day while putting together a custom 404 page for a SharePoint 2010 site I'm working on. Basically the scenario is this - I have got my custom 404 page put together and deployed (following the process described in this Microsoft support article - http://support.microsoft.com/kb/941329) and when I browse to it in internet explorer it all works fine. Here's the odd bit though, when I browse to the site in Firefox or Chrome I get my page, but instead of it being rendered as HTML, it gets spat out as plain text and all my users see is a big chunk of HTML on the page - far from ideal.

The reason this is happening is that the custom 404 page is not sending out any Content-Type response header. IE by default will assume HTML for anything that doesn't have this header, which is why it appears to be fine. Firefox and Chrome though both assume its plain text if this header is not set, which is why you only see the HTML code itself, not the actual rendered page.

The solution here isn't that complicated, lucky for me - using a HTTP module we can manipulate requests and responses as they go in and out of IIS, meaning we can write some code to change the response before it hits the user. Here is the code for the HTTP Module class:

public class FileNotFoundHeaderModule : IHttpModule
{
    public void Init(HttpApplication context)
    {
        context.PreSendRequestHeaders += ContextOnPreSendRequestHeaders;
    }

    private void ContextOnPreSendRequestHeaders(object sender, EventArgs eventArgs)
    {
        if ((HttpContext.Current.Response.StatusCode == 404)
           && (!HttpContext.Current.Response.Headers.AllKeys.Contains("Content-Type")))
        {
            HttpContext.Current.Response.Headers.Add("Content-Type", "text/html; charset=utf-8");
        }
    }

    public void Dispose()
    {
    }
}

That's all there is to it - just check if you are returning a 404, and if you are make sure it has the Content-Type header on the response. Too easy. To register this one we add a small change to the web.config files for our application:

<system.webServer>
    <modules>
        <add name="My-404Handler" type="My.Namespace.FileNotFoundHeaderModule, MyFullAssemblyName" />
    </modules>
</system.webServer>

Once you have that it your 404 page will work fine in all browsers. Hope that helps!

SharePoint Saturday Sydney Interviews

Thu, 13 Dec 2012 09:50:00 GMT

We had SharePoint Saturday Sydney a couple of months ago now, and while we were there the guys from SSW TV put together this video with some interviews of me and our speakers there, with the focus being on what we thought about the new version of SharePoint. Check out the video here!

Using WebAuthenticationBroker with OAuth 1 in WinRT

Tue, 20 Nov 2012 09:45:00 GMT

If, like me, you have been having a look at developing apps for Windows 8 that connect to remote web sites, then chances are you have probably seen some code that shows off how to use the WebAuthenticationBroker by now. Basically this is a neat little control that can simplify some of the things we need to do in order to authenticate against OAuth based websites in our apps. Now for anyone who doesn't know, I did a Windows Phone 7 app (Stitch - see http://stitch-app.com for more info) which connects to the remote site through OAuth, using OAuth version 1.0.

If you spend some time looking around at how the WebAuthenticationBroker works, chances are you will have noticed something else about it - it works really easily for OAuth 2 based stuff, but for OAuth 1 we are still left need to get a couple of tokens ourselves though. The hard part here is that we need to encrypt the signatures on our OAuth requests correctly - which if you don't know what you're doing can be tricky.

Using RestSharp

In my phone app I made use of RestSharp to do all of the required OAuth shenanigans for me, which was great because it kept my code simple and was very easy to implement. Naturally when it came time to do this on my WinRT app I went looking for a version of RestSharp that would work there, but unfortunately no one had been able to contribute something to the public version yet. Lucky for me though a guy by the name of Devin Rader had already taken a fork of RestSharp and was working on adding a WinRT library there. His fork had removed the OAuth functions though (as he saw a lot of it baked in to Win8 as it was), but after we had a quick chat I decided to throw my hat in the ring and see if I could get the OAuth stuff ported for WinRT to solve my issues with OAuth 1. Lucky for me, I made some quick progress and came together with something that in my early testing appears to be pretty solid. My fork is at https://github.com/BrianFarnhill/RestSharp for anyone who is interested, hopefully we can get it all rolled in to a public release in the not too distant future, but in the mean time you can grab it from there and build it to use it like I'm about to show you below.

Logging in with OAuth

Once you have gotten yourself a build of RestSharp for WinRT in to your project, the process is almost identical to how you would do it on any other platform, except that we are still going to make use of the web authentication broker. The first step as always is to get a request token that we can use to form the login URL that will be shown to the user. My code looks like this:

var client = new RestClient(OAuthConstants.AuthenticationUrl)
{
    UserAgent = OAuthConstants.UserAgent,
    Authenticator = OAuth1Authenticator.ForRequestToken(OAuthConstants.ConsumerKey, OAuthConstants.ConsumerSecret, OAuthConstants.CallbackUrl)
};

var request = new RestRequest(OAuthConstants.RequestTokenPath, Method.POST);
var response = await client.ExecuteAsync(request);

if (response.StatusCode == 404)
{
    throw new RavelryException(ResourceHelper.GetStringResource("Error_CantContactRavelry"));
}
_authToken = UrlHandler.GetQueryParameter(response.Content, OAuthToken);
_authTokenSecret = UrlHandler.GetQueryParameter(response.Content, OAuthTokenSecret);

This gets us the tokens we can pass in to the WebAuthenticationBroker which will show the user the login screen and let us know when it gets the result of the login process (which may involve more than one screen being shown to the user to grant permissions or do other actions)

var startUri = new Uri(OAuthConstants.AuthenticationUrl + OAuthConstants.AuthorisePath + "?oauth_token=" + _authToken);
var endUri = new Uri(OAuthConstants.CallbackUrl);

var webAuthenticationResult = await WebAuthenticationBroker.AuthenticateAsync(WebAuthenticationOptions.None, startUri, endUri);
if (webAuthenticationResult.ResponseStatus == WebAuthenticationStatus.Success)
{
    //handle a successful login here
}

So here we are creating the start URL for the broker using the tokens we received in the initial request, and this works perfectly to get the next stage of tokens for the login. After this is done all we need to do is combine them in to one last request that will get us the final access tokens we can use, which looks like this:

var loginResponse = webAuthenticationResult.ResponseData;
UserName = UrlHandler.GetQueryParameter(loginResponse, Username);
var requestVerifier = UrlHandler.GetQueryParameter(loginResponse, OAuthVerifier);

var client2 = new RestClient(OAuthConstants.AuthenticationUrl)
{
    UserAgent = OAuthConstants.UserAgent,
    Authenticator = OAuth1Authenticator.ForAccessToken(OAuthConstants.ConsumerKey, OAuthConstants.ConsumerSecret, _authToken, _authTokenSecret, requestVerifier)
};

var request2 = new RestRequest(OAuthConstants.AccessTokenPath, Method.POST);

var response2 = await client2.ExecuteAsync(request2);
AccessToken = UrlHandler.GetQueryParameter(response2.Content, OAuthToken);
AccessTokenSecret = UrlHandler.GetQueryParameter(response2.Content, OAuthTokenSecret);

So if you have used RestSharp at all the first and last request there should look pretty familiar to you (there are a couple of helper method I put in there though that pull the values you - the full code is in my app and you can see this class in full if you are interested in seeing how all the parts work.

Now the disclaimer - my fork of RestSharp is still very much so a work in progress, so don't complain to me if it breaks until we can get it stable enough for a release. That being said, if you do have any feedback on the fork that isn't just a "this doesn't work for me!" then I'm all ears! :-P I also haven't done any testing to see if I can hit any OAuth protected resources with this version of the library yet - but I will get to that shortly and will be keeping my public code for Stitch and my RestSharp fork up to date so feel free to keep an eye on those to see how I'm doing things as they progress through to a release.

Hope that all helps someone out there!

Using the BCS picker in a custom application page

Tue, 04 Sep 2012 10:45:00 GMT

I came across this need recently with a client of mine - basically I needed to be able to select an item from the BCS on a custom application page. Lucky for me this is pretty straight forward to do, but seeing as I ended up having a couple of small issues with it I figured I would cover it in one post here.

So step one, go and add a "ItemPicker" control to your ASPX page:

<SharePoint:ItemPicker class="ms-input" ID="MyPicker" OnInit="MyPickerInit" runat="server" />

The important part here is to make sure you have the OnInit event wired up, as we will use this to specify which LOB system and entity we want the picker to show. Here is the code for that.

    protected void ContactPickerInit(object sender, EventArgs e)
    {
        MyPicker.ExtendedData = GetExtendedData();
        MyPicker.AllowTypeIn = true;
        MyPicker.AllowEmpty = false;
        MyPicker.AutoPostBack = false;
        MyPicker.MultiSelect = false;
    }

    private static ItemPickerExtendedData GetExtendedData()
    {
        var data = new ItemPickerExtendedData
                       {
                           SystemInstanceName = "MyLOBSystem",
                           EntityName = "My BCS Entity",
                           EntityNamespace = "My namespace",
                           PrimaryColumnName = "ColumnName"
                       };

        data.SetSecondaryColumnNames(new[] { "ColumnName" });

        return data;
    }

So to run through what's going on here - firstly the properties I'm setting in the init method (past the ExtendedData Property) are all stuff I could shove into the ASPX, this was just me being lazy. The important part is in setting the ExtendedData Property. I use the GetExtendedData method I wrote to return a ItemPickerExtendedData object here.

Basically there are a few properties we need to set here, such as the System Instance name, entity name and namespace, and the primary column name - in my case I used the name of the field that would show in the picker once an entity is resolved. The second thing to change is in the SetSecondaryColumnNames method, where we pass in an array of properties we want the picker to return as well as the entity itself, so these are column names from your BCS entity itself. You have to make sure you include the column you specified in the primary column name Property or else when users try to resolve entities they will only see the BCS id for it (eg. _bg00013857349309 and so on ...) instead of the friendly text label. Also any other fields you request in the secondary columns will also be handed to you in the entity object, saving you the need to go and call them out separately after the user has made their choice, so that's handy to know.

To work with the entities that are chosen you refer to MyPicker.Entities and cast each object to the type PickerEntity, from there it has the Property of Key which will return the BCS Id (which you can then decode to get primary keys), as well as other properties for all the other fields you asked for.

Populate a SharePoint list with items in a CSV file using PowerShell

Thu, 05 Jul 2012 10:40:00 GMT

Again with the PowerShell related posts - but this is one that I have found quite useful in testing some of my SharePoint solutions so thought it was worth sharing. Here is the scenario - you have a SharePoint solution that you are developing and testing, and you need to create some data in lists you provision to be able to effectively test - now you could go down the path of provisioning the list items either declaratively or through some code in your actual solution, but when the time comes to go to production you will need to remember to take them out again, so not ideal.

So what about this - you take your PowerShell deployment script and configure it to create some list items for you (and through a flag you can set either in the script or however your are passing your settings to the script tell it to not do that when the script is run in production). This gets you away from adding the items to your actual SharePoint specific stuff, and gives you a nice way to automate the creation of the test data. So now how do we do it? Lucky for us the answer is very, very simple.

Start by making yourself a CSV file that uses the first row as headers for your data, and each header should line up with the internal field name in SharePoint that you want to add the data to - so "Title" is still "Title", but remember that if you created and exported some site columns you will be looking at the name with the x0020 's in the name. Once your CSV file is ready to go, here is a quick function I use in PowerShell to add the items to the list:

function Add-CsvDataToList([Microsoft.SharePoint.SPWeb]$web, [string] $listName, [string] $csvPath)
{
    $list = $web.Lists.get_Item($listName)
    Import-Csv $csvPath | ForEach-Object {
        $csvRow = $_
        $newItem = $list.Items.Add()
        Get-Member -InputObject $csvRow -MemberType NoteProperty | ForEach-Object {
            $property = $_.Name
            $newItem.set_Item($property, $csvRow.$property)
        }
        $newItem.Update()
    }
}

So going through what is here, the function takes in a SPWeb object (which you can get with Get-SPWeb) the name of the list, and the path of your CSV file. It then gets the list from the web and then goes through creating items for each row in the CSV file. The Import-Csv statement in PowerShell makes reading and working with CSV data amazingly simple as we get some objects back that represent each row, and by using the Get-Member statement with the filters there we can get back the names of all the columns in the CSV file without any of the other properties and methods it will inherit. So we loop over those properties and add them to our new list item and we're good to go!

This script will work with any CSV file and list as long as the headers all match up fields in your list (notice the lack of error handling here - get your field names or list name wrong and this all goes very pear shaped). Hope you find this useful though!

My SharePoint Developer Session Slides

Thu, 17 May 2012 10:30:00 GMT

A few weeks back I had the pleasure of presenting at the Australian and New Zealand SharePoint confernces. The session I did was a bit of an 'introduction to ALM for SharePoint developers' and it was pretty well received by the crowds at both conferences.

As promised (and somewhat late I know), here is all the content from my session. Below is the link to download the source code, as well as the PowerPoint slides. Also I did promise I would publish the results of the survey I discussed during the session as well.

If you have any questions or comments, make sure you let me know - I would love to hear from you.

External lists - where is my "Connect to outlook" button?

Tue, 28 Jun 2011 10:30:00 GMT

I've said it before and I'll say it again - External Lists in SharePoint 2010 are just awesome. Today I was looking at some work I am doing with an Outlook add in that ties in to an External List in SharePoint and I came across a bit of an odd situation - when I went to browse to my external list the "connect to outlook" button was missing from the ribbon! It wasn't disabled or anything like that, it was just plain and simple not there! Luckily though, this was an easy fix and I wanted to quickly share the solution.

As with everything to do with the Ribbon in SharePoint, it is all to do with features. Now the external list I was working with was deployed to a site that I had created from a custom site template that I had based on the blank site, so not a lot of features turned on in it at all (I like to keep these things very minimal and turn on only the features that I genuinely need when I'm writing up the onet.xml file). With that in mind I set out to find the feature that would add my button back, and a minute or so later I found it. The feature in question is a site scoped feature (not site collection - so "Web" scoped for the developers out there) and it's called "Offline Synchronization for External Lists".

So the easy way to fix things here is to just manually turn it on and all is well - but since I'm working with a site template I wanted it included in the site template, so I just looked up the ID of the feature (for anyone who doesn't know, you can do this very easily by switching on your developer tooling of choice and having a look at the HTML around the activate or deactivate button - SharePoint will render a div tag that has an ID attribute of a GUID, this is the ID of that specific feature) and then put it into my onet.xml file, the XML looking like this:

<WebFeatures>
    <!-- Offline Synchronization for External Lists -->
    <Feature ID="d250636f-0a26-4019-8425-a5232d592c01" />
</WebFeatures>

A quick redeployment later and my ribbon button was there and all was right with the world once more!

Checking permissions in SharePoint from the client object model

Thu, 09 Jun 2011 10:25:00 GMT

SharePoint 2010 brought us this great little addition called the client object model, which gave us an effective way to talk to SharePoint without having to deal with the at times rather average set of web services. This is been great for me at the moment as I have been working on an addin for Outlook 2010 that talks back to SharePoint, and in this post I wanted to share how I use the client object model to check a users permissions to a specific site.

The goal for this piece of code was to find out if the user had permissions to view items in a specific site, and I used that information to trim some of the functionality in the Outlook addin. First lets have a look at the code

bool hasPermissions;
using (var context = new ClientContext("http://MySharePointUrl"))
{
    var web = context.Web;
    context.Load(web);

    var permissions = new BasePermissions();
    permissions.Set(PermissionKind.OpenItems);
    var result = web.DoesUserHavePermissions(permissions);

    context.ExecuteQuery();
    hasPermissions = result.Value;
}
return hasPermissions;

Now let's break it down. Getting started we have the ClientContext object, this is the key to retrieving data from SharePoint on the client side. We pass the URL of our site into the constructor and from there we can use this object to execute queries. The first thing we do with this object is to retrieve the Web object (not called an SPWeb at the client side, just a Web, so don't get confused here!). This is done via the next 2 lines of code, the first creates our local variable but at this point it is essentially just a stub. Until we call the context.Load() method, which will essentially return the properties of the object from the server, we can't do much with this object. When we do call that load method only a small set of properties will actually be returned by default - you can throw some overloads into that method to specify which properties you specifically need but I wont go in to that here, I'll keep this simple. The theory is though that by specifying just the properties you need you can reduce the traffic between the client and the server.

Moving on to the important part of the code, the permission check. Here we create ourselves a BasePermissions object which will contain the permission we are checking for. In this case I'm just looking for the OpenItems permission, so I use the Set method to set the value and then I call the DoesUserHavePermissions method. Again, the result object here will throw an exception if I try to call it immediately after this as it is just a stub. What is happening here is that the appropriate query commands are queued up with the ClientContext object, and until we call the ExecuteQuery method (which we do on the next line) those queries will not be executed. This gives us control over when we go back to the server, which can allow us to do things in batches to optimise the communication between client and server once more. After the ExecuteQuery method returns I can simply check the result object for its Value property and that's it - I now know if the user has permissions to the site in question. Pretty simple stuff in the end, you just need to adjust to the client side way of thinking when dealing with transferring data to your client side app but a lot of the properties and methods on the objects are going to be familiar to you anyway, so feel free to have a crack at the client side object model when you get a chance!

Dialog boxes and long running operations

Tue, 17 May 2011 10:20:00 GMT

Just a quick little thing I discovered about the modal dialog boxes in SharePoint 2010 and how you can use a SPLongOperation within it. For those who don’t know, using SPLongOperation is a great way to get SharePoint to throw up a little loading screen while you run some code that will take a while to run (that way they know something is happening still), but if you want to use it in a dialog box you do things a tiny bit differently.

A basic SPLongOperation will look like this in code:

using (var operation = new SPLongOperation(Page))
{
    operation.LeadingHTML = "Updating SMS project";
    operation.TrailingHTML = "Please wait while additional tasks are added to the project plan";
    operation.Begin();

    // do your long running code here

    operation.End("/MyResultPage.aspx", SPRedirectFlags.Default, HttpContext.Current, string.Empty);
}

And if you are doing it in a modal dialog, there isn’t necessarily anything needs to change if it makes sense for the dialog to stay open, just redirect out and you are fine. If you need to close the dialog though there is only one thing that needs to change. Basically you swap the End() method out for an EndScript() method, which instead of redirecting the user will run some JavaScript for you, which you can use to close the dialog if you like. So the new closing line would look like this:

operation.EndScript("window.frameElement.commonModalDialogClose(1, 'My long running op completed!');");

There you have it, hope that helps someone!

CSS not rendering for SharePoint date picker control

Sun, 24 Apr 2011 10:15:00 GMT

Been a little while since I posted something to do with SharePoint development as such, so I figured I would add this quick post in explaining something I cam across the other day. I’m currently working on some Project Server 2010 customisations (which of course are all built on top of SharePoint 2010) and came across this when I noticed a date picker I was putting on one of my pages was rendering out like this:

So in this post I’ll take you through how I figured out what was happening here.

The first place I started was with the CSS – lets make sure I wasn’t doing anything silly to overwrite the out of the box styles. A quick look at where the styles on the date picker come from had me sure it wasn’t one of mine that did this. The reason being is that the calendar portion of the date picker is actually handled by an iFrame, and is an entirely separate page. If you look at the properties of the iFrame you can see that it is rendering the URL of “_layouts/iframe.aspx” with a massive query string that passes all the properties of the calendar, such as which calendar to use, work days, first day of the week, etc.

Next step was to have a look at what this iFrame looked like when it was called as part of a list field or some other out of the box scenario, as they were working and mine wasn’t. Since there isn’t a great deal of HTML on these little iFrames it was pretty easy to pick the differences – and there was one that got my attention – an extra CSS reference. The out of the box iFrame was rendering this CSS reference and mine wasn’t for some reason:

<link rel="stylesheet" type="text/css" href="/_layouts/1033/styles/Themable/datepickerv4.css?rev=Hu9OlQmu1YOXv7TK%2BQrc5Q%3D%3D"/>

As the name of the style sheet suggested, this is the file that has all of the styles for the date picker in it. From here I needed to figure out why my page wasn’t calling the date picker right. Seeing as I knew it was just an iFrame my next stop was to compare the URL’s of each iFrame to play spot the difference there, and surely enough there was one. Here is a sample of each URL:

Default: http://server/pwa/_layouts/iframe.aspx?...
Mine: http://server/_layouts/iframe.aspx?...

The difference here – the “/pwa” part, being the URL of my project server collection and the current SPWeb I was working with (also worth acknowledging, in this case there is no site at the root of the URL). When I changed the URL to add the /pwa the iFrame worked great and got the CSS reference.

So now that I knew what the problem was,how do I fix it? I’m working with and out of the box SharePoint control so recompiling it with a code fix isn’t an option,and I wasn’t keen on writing my own just for this. As luck would have it though, there is a property on the date picker that lets you specify the URL of the iFrame that should be used for the date picker, so a quick line of code in my code behind had it rendering out great, here is it.

MyDatePicker.DatePickerFrameUrl = SPContext.Current.Web.ServerRelativeUrl + "/_layouts/iframe.aspx";

Redeployed the solution with this and it all worked perfectly. Now I can only assume that the property I’m using is there in the case of someone wanting to use a different date picking mechanism, but in the case it allowed me to fix up the problem with the CSS not rendering.