Microsoft macht einfache Dinge unnötig kompliziert? Ist nicht wahr! Selbst glühende Microsoft-Fans werden mir spätestens bei dem folgenden Problem beipflichten, dass da irgendein Holzkopf etwas ganz und gar nicht zuende gedacht haben kann. Als Java-Programmierer betreue und entwickle ich mehrere Webportale bzw. Webanwendungen. Diese verwenden wie eh und je eine Benutzeridentifikation über Sessions und Cookies. Die dafür nötige Benutzerverwaltung ist dabei teilweise mit einem Active Directory gekoppelt, aber das tut hier nichts zur Sache. Wer nicht eingeloggt ist, bekommt zunächst nur eine Login-Seite zu sehen. Selbst wer eine Unterseite direkt aufrufen will, aber noch nicht eingeloggt ist, wird sofort auf die Login-Seite zurückgeworfen. Nicht eingeloggt ist jeder, der Gegenteiliges nicht mit Hilfe eines Cookies beweisen kann.

Schon seit mindestens zwei Jahren liegen mir die Nutzer besagter Applikationen mit einem sonderbaren Fehlerbild in den Ohren: Sie sagen, man könne aus Word-Dokumenten, Excel-Tabellen und Powerpoint-Präsentationen keine Links zu Unterseiten meiner Webanwendung öffnen. Obwohl diese Nutzer auf der entsprechenden Seite im Browser definitiv eingeloggt sind, bekommen sie nur entweder eine Fehlermeldung oder einfach nur die Login-Seite zu sehen. Das entsprechende Problem konnte ich nachstellen, und gleichzeitig zeigen, dass das Problem dagegen NICHT auftritt, wenn man die Adresse mittels Copy & Paste aus Word/Excel/Powerpoint manuell in die Adresszeile des Browsers überträgt. In dem Fall wird sofort die richtige, verlinkte Seite angezeigt. Es schien so als würde der Browser nicht mehr erkennen, ob jemand eingeloggt ist, wenn man den Link aus einem MS Office-Programm öffnen wollte. Das fand ich sehr sonderbar. Darauf konnte ich mir lange Zeit keinen Reim machen.

Wieso sollte es einen Unterschied machen, ob ich den Link im entsprechenden Office-Programm anklicke, oder ob ich den Link von Hand in den Browser kopiere? Die Adresse ist doch in beiden Fällen genau dieselbe. Eigentlich sollte Office bei einem Mausklick auf den Link doch auch nichts anderes machen als den Standardbrowser zu öffnen und die Adresse dort einzufügen. Heute weiß ich: Das elende Mistding macht GENAU DAS eben NICHT. Microsoft findet sich oft ganz besonders witzig und scheißt gerne mal auf alles, was naheliegend und richtig wäre.

Der Mechanismus dahinter nennt sich „Microsoft Office Hyperlink Prefetching“ und wird beim Hersteller – trotz aller Probleme mit Webanwendungen wie den meinen – gerne weiterhin als dickes Feature verkauft. Im Gegenzug schiebt Microsoft die Schuld für die bekannten Probleme kackdreist auf die Entwickler der jeweiligen Seiten, weil diese sich auf Session Cookies verließen, ganz so als sei das der Fehler. Session Cookies sind nach wie vor eine etablierte und korrekte Form der Nutzeridentifikation, unabhängig davon was es mittlerweile noch so an neuen technischen Möglichkeiten gibt.

Das Hyperlink Prefetching ist wohl teilweise dafür gedacht, zu verhindern, dass Office den Browser überhaupt öffnet, wenn die Seite hinter dem Link ohnehin nicht erreichbar ist. Dazu macht Office den Link im Hintergrund schonmal heimlich selbst auf und guckt, was sich dahinter verbirgt. Wenn der Link ungültig ist, bleibt der Browser zu, und Office zeigt nur eine Meldung an. Wenn die Seite den Benutzer aber umleiten will, werden die Umleitungen vorher abgearbeitet und der Browser bekommt erst die Ergebnis-URL übergeben. Das ist aber leider eine ganz schlechte Vorgehensweise von Microsoft, denn diese Umleitungen passieren meistens nicht grundlos, sondern hängen von bestimmten Faktoren ab.

Passiert ist also Folgendes: Office öffnet den Direktlink zu den Unterseiten meiner Webanwendung heimlich im Hintergrund (ohne Session Cookie!), und wird natürlich umgeleitet, weil Office dort nicht eingeloggt ist und die Seite nicht sehen darf. Den Link zur Login-Seite übergibt Office dann strunzdumm dem Browser. Dieser wiederum hat das Session Cookie und erkennt, dass der Benutzer eigentlich eingeloggt ist und die Login-Seite normalerweise nicht sehen sollte. Je nach Implementierung bekommt man im Browser nun entweder bei jedem Link immer die Login-Seite zu sehen, obwohl man eingeloggt ist, oder wird wiederum auf eine Fehlerseite umgeleitet (etwa: Zugang verweigert), weil man als eingeloggter Benutzer nichts auf der Login-Seite zu suchen hat.

Microsoft hat hier wirklich einen selten dämlichen Bug eingebaut für ein total hohles Feature, das keine Sau braucht, ohne Rücksicht auf Verluste. Aber sauer macht mich hauptsächlich die Tatsache, dass Microsoft die Schuld dafür auf alle anderen schiebt. Der Workaround, für den ich mich entschied, wird auf einer der unten angegebenen Webseiten präsentiert: Die MS Office Suite gibt sich bei seinem Hyperlink-Prefetch-Request als IE7 aus – ein Browser, den hoffentlich niemand mehr ernsthaft benutzt. In der Folge muss die Anwendung vor dem Login diesen User-Agent erkennen und den Request mit einer leeren Seite beantworten, also sämtliche Redirects verhindern. Erst dadurch macht Office das, was eigentlich sein verdammter Job wäre: Die URL unverändert an den Browser weiterzureichen. Dann klappt’s auch mit dem Login. Es ist natürlich klar, dass der Workaround wackelig ist, und sowieso hinfällig sein wird, sobald der User-Agent sich irgendwann ändert.

Es ist wirklich traurig, dass man als Entwickler seiner eigenen Webanwendung zu solch billigen Tricks greifen muss, um die Fehler von Microsoft auszubügeln, also etwas, das im Sinne meiner Softwareentwicklertätigkeit außerhalb meines Einflussbereiches und ganz bestimmt auch außerhalb meiner Verantwortung liegt. Aber die Nutzer der Weboberfläche sehen den Fehler zuerst bei dir, denn „ihr“ Office funktioniert ja wie gewohnt. Dagegen zeigt „deine“ Anwendung dem Benutzer eine Fehlermeldung an – also muss der Fehler genau dort liegen. Wenn sich solche und ähnliche Vorfälle häufen, wird das Programm subjektiv als generell fehlerhaft oder unausgereift wahrgenommen, die Nutzer beginnen an der Qualität deiner Software zu zweifeln, und in Konsequenz auch an deiner Kompetenz. Wie das Problem im Endeffekt behoben wurde, interessiert dann schon keinen mehr, denn der Entwickler hat ja nur seine Arbeit gemacht: Jetzt funktioniert es endlich so wie es längst hätte funktionieren müssen.

Hier einige Links zu dem leider schon recht lange bekannten Problem:

• https://support.microsoft.com/en-us/kb/899927
• https://www.wimpyprogrammer.com/microsoft-office-link-pre-fetching-and-single-sign-on/
• http://stackoverflow.com/questions/1421608/how-does-ms-word-open-a-hyperlink
• http://plone.293351.n2.nabble.com/Trying-to-solve-MS-Office-bug-with-document-having-link-to-a-private-ressource-in-Plone-td7565492.html
• http://shibboleth.net/pipermail/users/2011-September/001107.html
• http://webmasters.stackexchange.com/questions/71112/make-server-force-excel-to-hand-over-hyperlink-to-browser-without-trying-to-load