Forms Based Authentication in ASP.NET 2.0 has a nice feature that allows you to control whether or not your authentication ticket is stored in an HTTP cookie, or on the URL. In order to force the ticket to be transported on the URL, you simply add the attribute cookieless="UseUri" to the configurationsystem.webauthenticationforms node in your web.config. Now all of your URLs will automatically get the authentication ticket appended to them before being written out to the client browser. Inbound URLs will automatically have the ticket deserialized and the appropriate identity will be placed on the new thread for the request. Basically, it all just works, as long as you play by the rules.
One of the important rules is that all URLs must be relative, otherwise the framework is not going to write the authentication ticket into them on the way out. If that ticket isn’t written into the URL, and a user clicks it, the result will be that the new request comes in unauthenticated. This is a subtly different than the case for authentication tickets stored in HTTP cookies. Since modern browsers (unless specifically configured not to) will automatically send up HTTP cookies with new requests, it doesn’t matter whether you use absolute or relative links on your site, as long as you don’t end up changing the domain. If the domain changes, the cookie is not coming back up.
So… MOSS and WSS 3.0 are both now solidly based on the ASP.NET 2.0 platform, so this should all work in a SharePoint site, right? Well, sort of. So basically, no – not at all. Once you update your web.config to use "cookieless mode" everything appears to be working at first. You authenticate, and the ticket magically appears in your URL. The problems start to appear once you begin to navigate around your site. Some URLs have the ticket in them, and some don’t. It basically comes down to this – if a URL is written using a standard ASP.NET control, or if you write a relative URL yourself, the ticket is preserved and cookieless FBA works. However, if a SharePoint control writes the URL, it’s absolute, the ticket is not written, and FBA breaks.
We ran this past our PSS contacts, and apparently this is a known "issue", and it’s not slated to be addressed in the 3.0 product. Basically, the feature is not supported. It no doubt has something to do with SharePoint writing URLs to support Alternate Access Mappings. There’s really no reason why it couldn’t write them relatively, but it obviously doesn’t.
At any rate, I couldn’t find any evidence of anyone else out there trying this – successfully or not. And it does not seem to be documented anywhere that I could find. So, if you’re doing research to see if you can do this – everything I’ve seen and heard says you can’t.
