LINQPad is a great tool, even for a SharePoint developer when working with the RESTful web services. However, it does not provide an authentication mechanism against Office 365, a major issue when there is no on-premise SharePoint or Project Server at your hand to develop and test your queries (as suggested by Andrew Lavinsky in this post), as illustrated by the figures below.
We add a new connection of type WCF Data Service 5.1 (OData 3) to LINQPad:
Specify the URI of the ListData.svc at our O365 tenant, and Default (XML) as Formatter.
Then we receive the following error (you can try to specify username and password in the previous step, but it makes no difference):
Error: The remote server returned an error: (403) Forbidden.
I’ve found a workaround for this issue on the web, but for me it was so complex at the first sight (even though I later understood how it should work), so I decided to find another way, using my other favorite tool Fiddler.
Our “solution”: we will “cache” the authentication cookies from an Internet Explorer session, then inject the same cookies to the LINQPad sessions.
Start Fiddler, choose Roles / Customize Rules…, and edit the CustomRules.js file (don’t forget to create a backup!).
Before the OnBeforeRequest function add this code:
static var authCookies = "";
static var o365Site = "yourO365Site.sharepoint.com"; // modify this value!
At the beginning of the OnBeforeRequest function add this code:
if (oSession.HostnameIs(o365Site)) {
var cookie = oSession.oRequest["Cookie"];
if ((cookie == "") && (authCookies != "")) {
//oSession.oRequest["Accept"] = "text/html, application/xhtml+xml, */*";
oSession.oRequest["Cookie"] = authCookies;
}
}
At the beginning of the OnBeforeResponse function add this code:
if (oSession.HostnameIs(o365Site)) {
var cookie = oSession.oRequest["Cookie"];
if (cookie != "") {
authCookies = cookie;
}
}
Done! Save the changes of CustomRules.js. Then (having Fiddler running and capturing network traffic!) start IE, navigate to your O365 site, and authenticate yourself when requested. Cookies are cached in Fiddler at this point.
Note: In my development environment I always enable Fiddler to decrypt HTTPS traffic. I have not tested this solution with decryption disabled, and have doubts, if it should work. If you test it, please, leave us a comment with the results.
In the next step (the same Fiddler instance is still running and capturing network traffic!), try to reconnect LINQPad to the same O365 site. Cookies are replayed by Fiddler, authentication in LINQPad should work this time.
To test the functionality, I submitted a simple query:
So far the good news. After “solving” the authentication issue, let’s see a further problem, and that is bound to the (missing) $metadata support of Microsoft’s OData implementation in SP 2013.
As you might have noticed, in the example above I used the “old-style”, SP 2010 compatible version of the REST API (_vti_bin/ListData.svc), and not the “new-school” format, including _api (like _api/web/), and that is no just accidentally.
Since LINQPad needs the $metadata to build up the object structure, it simply does not work without that:
In LINQPad:
Error: The remote server returned an error: (404) Not Found.
In Fiddler (HTTP status 404):
Cannot find resource for the request $metadata.
One of the workarounds may be (again with Fiddler) to use an existing beta installation of SP 2013, capture the response for the $metadata request to a file, then in the development environment send it as a response for the $metadata request from LINQPad automatically, but it is rather hacky, even for me. In my opinion it simply does not worth monkeying so much with that, we should rather learn and use the syntax of the OData requests.
Developers (including myself) who need to work against Project Online are luckier. Although the OData service of PS seems to be available only through the new _api interface, the $metadata support is still there in this case.
And a sample query:
Have fun using LINQPad against your O365 site and Project Online!
UPDATE: The same trick can be applied, when we would like to add a service reference to our Visual Studio project, referring to an O365 / Project Online site (just like described here for an on-premise PS). Although VS 2012 displays an authentication dialog for my – in this case German – O365 site (it is not the case with VS 2010),
it seems to have no effect (at least, not always?):
Note, that based on the error details it is likely not just a simple authentication issue, as VS would like to append /_vti_bin/ListData.svc to the service URL.
In this case you can use Fiddler again to replay the cookies and authenticate on behalf of VS:
