I have a rich client application that connects to a backing web service using ASP.NET web services. The underlying authentication method used for multiple requests is ASP.NET forms authentication (with the .ASPXAUTH cookie)
I am extending the client to support communication with a webservice fallback url to provide some level of redundancy. However, when I do this, the client doesn't transmit the authentication cookie to the fallback url.
For example:
- User logs on to https://www.example.com/service.asmx
- this sets an authentication cookie with the domain of www.example.com
- At some point later the client decides it needs to route a request to the backup url
- this issues a request to https://www.examplebackup.com/service.asmx
- the authentication cookie is not transmitted and the request fails
I recognize that the design of cookies is to keep them isolated per-domain so what I am trying to do is a bit naughty. However, it seems like I should be able to do this because I control the client and have a fixed (in configuration) set of hosts which I want to consider to be equivalent within this application.
Is there any way that I can persuade the HttpWebRequest/CookieContainer implementation in .net to allow me to specify that cookies should be shared across domains.
I understand that there are other ways to do this for "big infrastructure" options that would allow me to have fallback options with the same DNS name, but BGP and routing changes are not feasible for this project.