Picture your beautiful web application. It does all manner of wonderful things, but herein we examine two of its URL mappings:
-
/loginis the login form. A happy user enters authentication credentials, gets a session cookie, and proceeds to enjoy the delightful experience. -
/important-documents/<document_name>downloads a document. These documents are very important and some contain secrets, so a user must be authenticated to see them. An authenticated user sees the document, and an unauthenticated user receives a 301 redirect to/login.
Your customers are important business people, so they use the paramount software for business, Microsoft Office. Your web application has become established among their community as the authoritative document repository, and one very important user just had the clever idea to cite synergy.doc from revenue.doc by adding a hyperlink to yourwebapplication/important-documents/synergy.doc.
You're about to receive a new issue in the bugtracker. Do you know why?
Of course this report is nonsense. Your URLs work. But you'll test a few links anyway just to verify, because you're a good diligent software developer, before filing this one under the "cannot reproduce" resolution.
Tomorrow the ticket is open again. They don't give up easily, do they? You watch the insistent user log in ... copy the URL for a document ... open Word ... search the ribbon for that cryptic ideogram of a giant chain attacking planet Earth ... and ctrl+click the resulting link. And as you expected, the user now sees---
The login form?
When you activate the hyperlink to important-documents/synergy.doc, you might expect it to immediately launch the default web browser pointed to that URL. But instead, Word does its very best to be clever. Unfortunately for you, it isn't.
The first thing Word does is try to resolve that URL on its own. "Why is my word processor making HTTP requests?" Perhaps so it can open links to Office files directly without going through a web browser. Whatever the reason, it does.
If I now remind you of the security policy we discussed, you should know what happens next. Word does not have your web browser's session cookie, so the server responds with a redirect to /login. The redirect points to an HTML page, so Word launches a web browser, just like you'd expect.
What you didn't expect is that the web browser never receives a request for important-documents/synergy.doc. Word directs the browser directly to /login. If you want an explanation for that one, you'll have to ask someone on the Office development team.
Good luck explaining to the user why this is Microsoft's fault and not yours.