Re-authentication required for registered-path links (to ASP.NET site) coming to IE from PowerPoint
- by Daniel Halsey
We're using URL routing based on Phil Haack's example, with config modifications based on MSDN Library article #CC668202, to provide "shareable" links for a ASP.NET forms site, and have run into a strange issue: For users attempting to open links from PowerPoint presentations, and who have IE set as their default browser, using one of these links forces (forms-based) re-authentication, even in the same browser instance with a live session.
Info:
We know the session is still alive. (Page returns information for the currently logged-in user; confirmed via debug watches)
This doesn't happen with other browsers (FF, Chrome) or with other programs (Notepad++) as the URL source.
We do not have a default path set, as this caused issues with root path handling at initial login.
This primarily happens with PowerPoint, but will also happen in Word and OCS.
On some machines, even after changing the default browser, Office apps will continue to use IE for these links, forcing this error. (A potential registry fix for this failed, but even if it had worked, we can't control default browser choice for our users.)
We can't figure out if this is an Office oddity or is being caused by our decision to use app-level URL routing (rather than IIS rewriting). Has anyone else encountered this and found a solution?
