Wie ich schon vorher fragte: Ist das die Standard Login Maske der domcfg oder eine eigene ?
[HTTP] mail redirect
- Deny6equj5
- Erledigt
-
-
Oh sorry
habs übersehen...
Es ist die Standard-Maske die da angezeigt wird :))
Habe auch schon eine Kopie der Maske mit eigenem Logo etc.. ausprobiert...ging auch nicht...Meinst du es könnte daran liegen?
-
Wie sieht denn das LoginMapping in der domcfg aus ?
-
Existiert eine Maske diesen Namens auch in der domcfg ?
Ist diese Maske verfügbar für öffentlichen Zugriff ?
Wie sieht die ACL der domcfg aus ?Hast du diese anhand der Anleitung in der Admin Hilfe eingerichtet ?
-
Einfach mal die DB domcfg löschen oder umbenennen. Für die normalen Funktionen wird sie nicht benötigt, erst wenn man z.B. die Anmeldemaske anpassen möchte.
Wenn dann alles funktioniert kann man sich um diese "Schönheits"-Geschichte immer noch kümmern.
-
Hi,
unabhängig von diversen Dateizugriffsrechten kannst Du an der Dominokonsole mit
"tell http show users"
den Erfolg einer Anmeldung überprüfen ...
ZitatAlles anzeigen
Deny6equj5 schrieb:Ohne Session authentication funktioniert der direkte Pfad auf die Mail-DB. Ein HTTP-Auth öffnet sich ich logge mich ein und bin auf meiner Mail-DB. Das funktioniert!
Sobald ich die Session authentication auf 'Single Server' stelle, dann greift er natürlich wieder auf die Infos der 'domcfg.nsf'
Ich gebe den direkten Pfad der Mail-DB an und der Login Maske erscheint...Ich gebe meinen Namen und mein Passwort an...und...es tut sich nix...User/Passwort sind korrekt...Das alles jetzt erstmal ohne DWARedirect
denn es hebt primär an der DOMCFG.NSF!!!Hat jemand noch ne Idee? :pint:
-
So bin wieder da
war ne Runde auf LotusScript Schulung :hammer:lodsnods
danke für deinen hinweis, es sind tatsächlich user eingeloggt, nur sind sie nicht in ihrer Mail drin sondern stehen weiterhin in der Anmeldemaskecarsten
die domcfg.nsf habe ich schon gelöscht hat leider nix gebracht...taurec
- die Maske existiert auch in der domcfg.nsf
- die Maske ist für öffentlichen Zugriff zugelassen sonst könnte man sie ja auch nicht öffnen denk ich mal
- die ACL der domcfg.nsf sieht folgendermassen aus:
default: leser; anonymous: leserHab die domcfg.nsf laut Admin-Hilfe erstellt
da kuck ich immer rein, unverzichtbar!also das lustige ist wie oben schon erwähnt, ich habe mich angemeldet mit direkter Pfadangabe in der Adressleiste des Browsers http://server/mail/meinemail.nsf -> Anmeldemaske der domcfg.nsf erscheint -> melde mich an -> wieder erscheint die Anmeldemaske der domcfg.nsf -> "tell http show users" zeigt auch tatsächlich das ich mich erfolgreich eingeloggt habe
komisch :-?
-
Mit welcher URL wird denn die Anmeldemaske aufgerufen, d.h. welche URL steht beim ersten Aufruf und nach dem ersten Anmeldeversuch in der Adresszeile des Browsers ?
-
Wenn du http zulässt funktioniert es dort ?
-
habe die frage jetzt nich ganz verstanden...aber habe weiteres gerade probiert...Ich habe den SSL Port disabled.
Wenn ich nun per http://server/mail/meine_mail.nsf auf meine Datenbank zugreife erscheint nach wie vor die AnmeldeMaske der domcfg.nsf
Nun melde ich mich an, mit den gleichen Daten wie vorher die funktioniert haben laut "tell http show users"
Jetzt bekomme ich sofort eine Fehlermeldung "You provided an invalid username or password." und ich werde auf "http://server/names.nsf?Login" verwiesen!!
Also ich versteh jetzt ehrlichgesagt gar nix mehr...
Wenn ich jetzt die Session Authentification wieder disable dann funktioniert ja der Login per HTTP-Auth wunderbar!! der HTTP-Auth funktioniert auch per HTTPS etc.... :-?
-
Das heisst da herrscht ein grundsätzliches Problem mit der Session Authentification.
Prüf doch mal nach ob die im Serverdokument eingetragenen Netzwerk Hostnamen auch mit dem wirklichen Hostnamen deines Servers (der mit dem du von aussen zugreifst) übereinstimmen
-
Prüf mal folgende Dinge:
Einstellungen bei den Internet Sites, evtl eingerichteter Realm
-
soweit passt das habe auch kein REALM Dokument
die DWARedirect Datenbank funktioniert jetzt auch aber wie gesagt nur über die IP
-
Schön aber das Problem selbst behebt das ja auch nicht.
Du musst halt mal prüfen ob bei den Webeinstellungen irgendwo ein falscher Hostname oder gar kein Hostname sondern nur die IP angegeben ist -
Bei der SessionAuthentification wird bei erfolgreicher Anmeldung ein Cookie generiert, dessen Gültigkeit auf die in der Web-SSO-Konfiguration eingetragenen DNS-Domäne beschränkt ist. Das schließt aus, daß dort z.B. .localdomain eingetragen wurde aber jemand sich statt mail.localdomain mit der IP (10.10.10.110) anmelden kann, da der Cookie nicht zurück geliefert wird weiß der Server nichts von der erfolgreichen Anmeldung und antwortet permanent mit der Anmeldemaske, die aber durch die Fehlkonfiguration immer einen falschen Cookie zurückliefert.
Cookies müssen übrigens im Browser für die SessionAuthentification aktiviert sein.
Realms haben übrigens keine Funktion mehr sobald SessionAuthentification aktiviert wurde, sie werden nur für die BasicAuthentification durch den Browser ausgewertet. Sie sind somit dann nutzlos sobald nicht mehr mit BasicAuthentification gearbeitet wird.