Monday, September 05, 2011

In the warm, fuzzy .Net world...

Accessing webservices on a SharePoint site using FBA takes a little extra work.

In .Net, it's pretty simple. In fact, there's a MSDN article with code samples and all on precisely how to do that. In summary, you first call the Login method on Authentication.asmx, and use the returned cookie in all future web service requests.

Outside .Net

One dark and stormy night, I ventured out into the non-Microsoft world.  No-man's land.  Without the .Net generated web service proxies, we were rolling our own SOAP messages to communicate with SharePoint webservices.

Where's my cookie??

Without the .Net proxy, you can't use CookieContainer as the MSDN article suggests. Authentication.asmx's description for Login shows the following SOAP response:

The response XML simply contains the authentication cookie's name.  Where did the actual cookie go? GIMME MY COOKIE!!!

Getting the cookie

It turns out the cookie is sent in the SOAP header. If login is successful, the response's SOAP header will look something like this:

The Set-Cookie field above gives us the FBA cookie called .ASPXAUTH, with value 987A98.......

Using the cookie

To use the cookie for web service requests, we need to include it in the SOAP request header by adding a Cookie field:

You can include multiple cookies by separating the name/value pairs with semi-colons. Once the .ASPXAUTH cookie is set, you can send the request and a response should be returned as normal.

No-man's land behind ISA lines

SharePoint sites behind an ISA server with Forms authentication can be handled similarly. The difference is that we have to get the authentication cookies from the ISA server instead of SharePoint. That can be done by POSTing to the /CookieAuth.dll?Logon url. I won't go over the details, but it shouldn't be hard to figure out the appropriate url and querystring to use.