Login in spezielle Datenbank

[HarryB]

Hi Forum,

meine Datenbank darf sich jeder ansehen. Wenn jedoch bestimmte Funktionen ausgeführt werden sollen (Datenpflege), muss man sich einloggen. Mit dem ?login Kommando soweit kein Problem. Es wird korrekt die Login Seite des Servers, die in der Domcfg konfiguriert wurde angezeigt.

Allein: nach dem Login kommt man nicht zurück zur Datenbank, sondern in das Wurzelverzeichnis "/". Hat jemand eine Idee, wie ich unter Nutzung der Login Seite auch wieder auf meine Datenbank zurück komme?

Viele Grüße
Harry

[fiuman007]

Also ich hab das bis jetzt immer nur im Web gemacht. Da kann man beim "Logout" festlegen wohin er zurückspringt .....
Vielleicht gehts da auch. Hoffentlich schreibe ich jetzt kein Schmarn hier ....

[Marinero Atlántico]

2 Schüsse ins Dunkle:
1. In deinem Browser erlaubst du keine Cookies.
2. Du hast in der Maske Felder die irgendwie die Navigation bestimmen. Heisst das nicht $$Return, mit dem man redirection machen kann? Vielleicht ist sowas da drin in der Maske.

[HarryB]

2 Schüsse ins Dunkle:
1. In deinem Browser erlaubst du keine Cookies.

Der war daneben.

2. Du hast in der Maske Felder die irgendwie die Navigation bestimmen. Heisst das nicht $$Return, mit dem man redirection machen kann? Vielleicht ist sowas da drin in der Maske.

Es gibt ein redirect Feld. In dem ist "/" als Standardwert drin. Allerdings ist es so, dass wenn man eine Datenbank aufruft, die keine Anonymous Zugriffe zulässt, der Server dieselbe Login Maske nutzt und trotzdem korrekt zur Datenbank zurückspringt.

Viele Grüße
Harry

[HarryB]

Also ich hab das bis jetzt immer nur im Web gemacht. Da kann man beim "Logout" festlegen wohin er zurückspringt .....
Vielleicht gehts da auch. Hoffentlich schreibe ich jetzt kein Schmarn hier ....

Leider nein, habe ich schon ausprobiert.

Viele Grüße
Harry

[Marinero Atlántico]

Es gibt ein redirect Feld. In dem ist "/" als Standardwert drin. Allerdings ist es so, dass wenn man eine Datenbank aufruft, die keine Anonymous Zugriffe zulässt, der Server dieselbe Login Maske nutzt und trotzdem korrekt zur Datenbank zurückspringt.

Ich würde testweise versuchen, in das redirect Feld die baseURL der Datenbank einzutragen. So http://server/theConcreteDatabase.nsf

Dann wäre es aber wohl ein bug.

[HarryB]

Es gibt ein redirect Feld. In dem ist "/" als Standardwert drin. Allerdings ist es so, dass wenn man eine Datenbank aufruft, die keine Anonymous Zugriffe zulässt, der Server dieselbe Login Maske nutzt und trotzdem korrekt zur Datenbank zurückspringt.

Ich würde testweise versuchen, in das redirect Feld die baseURL der Datenbank einzutragen. So http://server/theConcreteDatabase.nsf

Dann wäre es aber wohl ein bug.

Da ich damit unser Intranet lahmlegen würde, lasse ich das mal lieber.

Viele Grüße
Harry

[Marinero Atlántico]

Ich halte parallele Testsysteme inzwischen für eine gute Idee.
Man braucht ungefähr 2 Jahre, bis das Management kapiert hat, dass beide trotzdem immer ein bischen unterschiedlich sind, egal wieviel Mühe man sich dabei gibt.
Aber es hilft auf jeden Fall.

[HarryB]

Das sehe ich genauso. Aber derzeit will mein Chef sogar mit Gewalt alle Notes Funktionen auf einem Server vereinen. 

Hat noch jemand Ideen zu dem Problem? Automatische Verwendung des Login Form der DOMCFG funktioniert astrein. man kommt dain, wo man hergekommen ist. Explizites verwenden des ?Login verhindert das leider. 

Viele Grüße
Harry

[Marinero Atlántico]

Dann braucht man nur genau 1 Rechner für die Testumgebung

[datenbanken24]

Normalerweise schickt Dich der Login-Dialog immer automatisch dahin zurück,
von wo Du gekommen bist.

Das passiert über das Feld "redirectTo" automatisch.
 
Ansatz:

Wenn Du als Anonymous bereits in einer Datenbank bist,
und Dich dann für mehr Funktionalität einloggen willst,
muß hinter dem Login-URL
am besten die Startseite Deiner Notesdatenbank im Web
gefolgt einem "&LOGIN"

also z.B.

..db.nsf/indexpage?openpage&login

stehen.


Vielleicht liegt Dein Problem schon daran,
dass Du das Login hinter ein Fragezeichen setzt.

Man braucht also die domcfg Loginform nicht direkt aufzurufen,
sondern das Datenbank-Element, wo man hin will.


Sorry, wenn ich das Beispiel schon wieder bringe,
soll keine Werbung sein -
aber diese Datenbank macht genau das, was Du beschreibst
und nutzt auch eine eigene $$loginform

http://www.manetu-03.de/pvdemo

Zuerst bist Du Anonymous und bist nur Leser

Und nach dem Login (rechts oben klicken)

Login: "pvdemo"
Pw:    "pvdemo"

hat man dann Authorenrechte.

Das Logout
funktioniert demgegenüber anders -
nämlich mit dem Fragezeichen, welches Du für das Login verwendet hast

../db.nsf?logout&redirectto=xxx"

Im Javascript Code hinter dem Login im Beispiel siehst Du den URL.

Du braucht also nicht direkt bzw. solltest nicht die Loginform per URL ansprechen
sondern ein Element Deiner Datenbank mit einem angehängten "&LOGIN"

Und das geht eigentlich immer und macht eigentlich nie Probleme.
Wenn das nicht geht, dann ist definitv die $$loginfom kaputt-customized.

Gruß,
Uwe

[HarryB]

Folgendes

http://notesweb.uni-wh.de/public/UWHForschung.nsf/wStart?OpenPage&login

ergibt folgende Fehlermeldung:

HTTP: Missing resource string
HTTP: Missing resource string: HTTP: Missing resource string - HTTP: Missing resource string

Hast du eine Idee dazu? "?login" gibt die Meldung nicht, allerdings kommt man eben nicht mehr zurück zur Datenbank.

Viele Grüße
Harry

[datenbanken24]

mmh..., komisch

Die Datenbank sieht ja völlig ok aus,
nur eben beim &Login knallts

mein Ansatz wäre die $$UserLoginForm zu prüfen,
aber was da jetzt genau nicht stimmt,
hab ich auf Anhieb jetzt leider auch nicht parat.

Eine Sache habe ich noch wage in Erinnerung,
und das könnte in die Richtung gehen:

Wenn man die $$USerLoginForm, wie beschrieben,
über ein Datenbankelement direkt aufruft ...&Login

und dann per HTTP auf Ressourcen innerhalb der domcfg zugreifen möchte (z.B. auf Bildressourcen),
dann muß man bei dem relativen URL-Pfad die domcfg.nsf davor schreiben:

Das habe ich hier damals beschrieben:
http://www.atnotes.de/index.php?topic=17646.msg106634#msg106634

Vielleicht greift Deine $$LoginForm noch auf irgendwas anderes zu, innerhalb der Datenbank, was er dann nicht findet und den missing string zurückmeldet.

Das würde erklären, warum es bei einem Direktzugriff über ?login klappt und bei einem Zugriff über ?element&login
nicht.

[HarryB]

Darf ich dir mal unsere domcfg schicken, damit du sie dir mal ansiehst? Ich bin da echt ratlos.

Viele Grüße
Harry

[datenbanken24]

Versuchen können wir es.

Noch interessanter wäre dabei, was das domlog und das Notes Logbuch dazu sagt.

Wenn man ins Notes/Domino 6 Forum "Missing resource string" eingibt,
kann das ja scheinbar alles möglich sein,
angefangen von einer Einstellung der Sprachtabelle im Serverdokument bis zu einem Include lss Befehl im Code.

Bei den meisten dort hat das Logbuch geholfen.

Reinschauen in die domcfg können wir gerne:
uhe at manetu punkt de

PS.
Soweit ist es mit den Spamfritzen schon gekommen,
dass man so seine Mailadresse angeben muss..

[datenbanken24]

Was zwei Stunden PAUSE bewirken können.
Dann lösen sich die Probleme manchmal von selbst.

DEIN LOGIN FUNKTIONIERT EINWANDFREI

https://notesweb.uni-wh.de/public/UWHForschung.nsf/wStart?OpenPage&login

Wir waren beide blind.

Der "HTTP MISSING STRING" Fehler kam nur,
weil wir das HTTP vergessen hatten.
und über HTTP daruf wollten
(ich habe einfach den URL aus Deinem Text kopiert)

Wahrscheinlich hat Deine Datenbank als Eigenschaft:
"Nur über HTTPS aufrufbar"

und in Deinem Serverdokument ist einfach noch nicht eingestellt, dass HTTP-Anfragen bei solchen Datenbanken automatisch auf HTTPS umgeleitet werden sollen.

Das ist jetzt nur noch ein Mausklick in N&A.

Gruß,
Uwe

[datenbanken24]

Harry,

ein Kollege sagte mir gerade,
dass man mein "PS" in der Antwort #14
möglicherweise schwer mißverstehen könnte...

Ich meinte keinesfalls Dich als Spamfritzen,
sondern dass man wegen der allgemeinen Spammerei
seine Mailadresse in einem öffentlichen Board nicht direkt angeben kann,
sondern diese wie oben geschehen anders schreiben muss.

Das habe ich auch nur bei anderen hier gesehen und nachgemacht.
Ich denke mal, das ist wegen den Mailcrawlern,
die sich aus solchen Boards Mailadressen ziehen und diese dann für Spam nutzen.

Also das PS bitte nicht mißverstehen.

[HarryB]

ein Kollege sagte mir gerade,
dass man mein "PS" in der Antwort #14
möglicherweise schwer mißverstehen könnte...

Yo, mit Gewalt kann man vieles mißverstehen. War hier aber nicht der Fall.

Vielen Dank erst mal für deine Hilfe. Ich schau noch mal nach.
Harry

[koehlerbv]

Jo, Uwe und Harry, dieses genannte post scriptum müsste man sicherlich extrem missverstehen wollen, um da etwas anderes hineinzulesen. Und es steht leider zu erwarten. dass man in absehbarer Zeit eMail-Adressen noch mehr verschleiern muss - die verbrecherischen Spammer rüsten ja auch permanent nach 

Bernhard

[HarryB]

Der Login klappt soweit. Der Hinweis mit dem https war der richtige. Es lag aber nicht daran, dass die Datenbank selbst SSL erfordert, sondern daran, dass die domcfg SSL erfordert (wir wollten ungerne Benutzername und Kennwort unverschlüsselt über die Leitungen schicken).

Viele Grüße
Harry