[endgültig-gelöst] Iwaredir macht plötzlich Redirect zum falschen Protokoll

[Tode]

Ein Server steht hinter einem reverseproxy. Auf dem Server ist die iwaredir mit fixem Hostnamen eingerichtet:

http://Https://reverseproxy.domain.de steht da....

Der reverseproxy leitet an die Website des Servers http://Server.domain.intra weiter.

Seit kurzem passiert folgendes (obwohl weder am Domino noch am Reverse Proxy was geändert wurde):

Der Benutzer gibt http://Https://reverseproxy.domain.de in seiner Adresszeile ein und erhält den Login- Bildschirm.
Er meldet sich an, und iwaredir leitet an
http://Http://reverseproxy.domain.de/Mail/username.nsf weiter, obwohl https in der config der iwaredir steht.
Und http ist von draußen nicht erreichbar, was zu einer Fehlermeldung führt.

Drückt man jetzt den zurück- Button des Browsers, landet man ja wieder auf der iwaredir (diesesmal ist man aber schon angemeldet),
Und jetzt wird man korrekt auf https:// weitergeleitet...

Klar, für den Server ist die erste Anfrage eine http Anfrage, weshalb er -wenn ich dynamisch gewählt hätte- auch auf http weiterleiten würde. Aber wenn ich ihm doch das https vorgebe, muss er das doch beibehalten.

Wie gesagt: das hat so Jahre funktioniert, und jetzt hat niemand was geändert, und plötzlich geht es nicht mehr.

Server ist ein Domino 8.5.3

Jemand ne Idee

[alexhe]

Hi Torsten,

ich weiß zwar nicht, warum du auf einmal das Problem hast.

Hilft dir denn "Force login on SSL" im Internetsitedocument weiter ?

gruß
alex

[Tode]

Ne, hilft nicht. Das Problem ist ja, dass für den Domino alles über http abläuft... der reverse proxy versteckt ja die tatsächlichen aufrufe vor dem domino und den domino vor dem browser... Auf dem domino selbst ist der ssl port ja nicht mal eingeschaltet (und war es auch noch nie)..

[stoeps]

Hast du in der Redirect DB die Optionen für SSL umgestellt?

Siehe Screenshot.

[Tode]

Sorry für die späte Rückmeldung... Heute bin ich vor Ort... Habe schon alle möglichen Kombinationen der SSL- Einstellungen ausprobiert: Protokoll weglassen Ja / Nein, SSL Authentifizierung erzwingen Ja / Nein, etc... werde wohl um ein Debugging mittels Console nicht drumrum kommen...

[Tode]

Ergänzung: Ich glaube, ich bin auf dem Holzweg... es ist nicht die iwaredir, die Mist macht... Das ist die domcfg... Denn ich lande ja zuerst auf dem Login- Screen. Und von da werde ich nach erfolgreichem Login falsch umgeleitet... Ich versuche gerade rauszufinden, warum das so ist...

EDIT: Wenn man die settings der iwaredir verwenden will, dann muss man halt auch die domcfg so anpassen, dass sie den Login- Screen der iwaredir verwendet... dieser Artikel hat mich auf die Spur gebracht... mal schauen, ob ich damit nicht weiterkomme...

[Tode]

So... führe ich meinen Monolog mal weiter:

Das Problem ist das Feld "RedirectTo". Das enthält einen relativen Pfad.

So sieht ein Ablauf aus:

ich rufe auf
H11ps://reverseproxy.domain.de

es öffnet sich die Anmeldemaske, im Feld "RedirectTo" steht: "/iwaredir.nsf?Open"
in der Form- Action steht "/names.nsf?Login"

Nach erfolgreichem Anmelden SCHEINT der Server die URL zusammenzurechnen (nicht der Browser), und für den Server ist das alles ja HTTP. Also leitet er um nach:

H11p://reverseproxy.domain.de/iwaredir.nsf?Open

Nun habe ich per Javascript dafür gesorgt, dass im RedirectTo- Feld der volle Pfad steht, also so:
H11ps://reverseproxy.domain.de/iwaredir.nsf?Open

Dann klappts alles.

Ist zwar nur ein Workaround, und es ist momentan auch nicht geklärt, warum der Server sich plötzlich anders verhält als vorher, aber im Moment ist es damit gelöst...

[stoeps]

Ein wirklich seltsames Problem. Ich habe die gleiche Konfiguration letzte Woche wieder einmal aktiviert und habe absolut keine Probleme. Proxy ist nur über https erreichbar, die Dominos nur über http.

Die Berechnung der Ziel URL ist aber doch in iwaredir.nsf, die domcfg dürfte nur die Login Maske liefern (apropos welche nimmst du?).

[Tode]

Ich nehme die Standard- Login- Maske der domcfg (8.5.3, kopiert und Logo ausgetauscht, sonst Original)... Ich habe auch schon probiert auf die DWALoginForm der iwaredir umzustellen, aber die hat das selbe Phänomen.

Wie beschrieben: Die iwaredir macht alles korrekt, sie beachtet Ihre Settings und leitet sauber um. Das Problem ist der "erste" redirect nach dem names.nsf?Login... Der geht ins Nirvana.

Was ich nicht verstehe: Das Ganze hat jetzt Jahrelang funktioniert, und plötzlich nicht mehr, obwohl weder am Proxy noch am Domino was gemacht wurde (beim Proxy bin ich mir zu 100% sicher, beim Domino nur "relativ", weil hier die Admins des Mutterkonzerns unter Umständen generell was geändert haben (sie sagen, sie hätten nix geändert), was dieses Verhalten verursacht...

Jetzt könnte ich die aktuellen Dokumente per DXL exportieren und mit den automatischen Backups im IBM_TECHNICAL_SUPPORT- Verzeichnis per DIFF vergleichen. Ich fürchte nur, dass da nix bei rauskommt...

Ich stehe vor einem Rätsel... Da müsste ich wohl ziemlich tief abtauchen, um festzustellen, wo hier der Fehler passiert...

[Tode]

Muss das Thema nochmal hochholen: Das Problem ist jetzt "gewandert"... Es passiert nämlich auch, wenn die forms85.nsf auf die UltraLite- Seiten umleitet... Auch dort wird wieder das Protokoll in der umgeleiteten URL ersetzt (https wird zu http)... Und da kann ich nicht so einfach mit JavaScript reinschreiben...

Es muss also ein zentrales Problem am Domino sein. Ich habe ein solches Verhalten noch nie gesehen:

Wenn der Server eine relative URL berechnet und an den Browser zur Anzeige sendet, dann wird aus dem HTTPS der Browserzeile IMMER ein HTTP (was der Server sieht)...
Ich konnte das sogar ganz ohne domcfg und iwaredir nachvollziehen, nur mit der "schönen" gelben Standard- Login- Seite...

Noch jemand ne Idee, wie ich dem Domino sagen kann, dass er die URLs gefälligst:

a) in Ruhe lässt
oder
b) mit dem protokoll ausstattet, die der Client in der URL- Zeile hat...

[Tode]

So... letzter Post zu dem Thema von mir: Problem konnte gelöst werden, es war (mal wieder) was ganz anderes:
Der Reverse- proxy hat sich selbst nicht unter seinem eigenen Namen gekannt. Dadurch hat er nicht "erkannt", dass er die falsche URL, die der Domino generiert (was technisch vollkommen ok zu sein scheint) in eine richtige URL (mit https) umwandeln muss.

Ein Eintrag in der HOSTS des Reverse- proxy, wo der name korrekt aufgelöst wird und alles funzt.

Die Änderung, die den Fehler verursacht hat, war also tatsächlich weder im Domino noch im pounds, sondern in einem DNS- Server, wo der Eintrag für die beiden Reverse- Proxies "wegoptimiert" wurde...