fehlende Benutzerrechte zum Speichern eines Dokuments im Web ??

[Daniel S.]

Hallo!

Ich habe hier im Moment ein Problem, bei dem ich nicht ganz weiter weiß. Soweit ich es im Kopf habe, sollte doch ein Benutzer, der auf einer Datenbank als Autor eingetragen ist, ein Dokument mit einem Autorenfeld, in dem er aufgeführt ist, bearbeiten und Speichern können.

In meiner Applikation wird beim Aufruf  im Browser von einem Agenten ein Dokument erstellt, in dem sowohl in ein Autorenfeld als auch in ein Leserfeld der Name des Aufrufenden Users sowie die Rolle [Manager] eingetragen werden (+einige andere Felder). Erstellt wird das Dokument also mit meiner ID, aber durch das Autorenfeld sollten User ihr jeweiliges Dokument ja bearbeiten können. Die Autoren- und Leserfelder sind im Form als "Computed when composed" eingestellt und befinden sich auf einem Subform. Ich habe mal einen berechneten Text mit @Username=fldAuthors hinzugefügt, und das gibt mir "1" zurück.
Die User können die Dokumente auch im Browser öffnen und auch ?EditDocument funktioniert, wenn aber der Submit-Button betätigt wird, erscheint das Anmeldeformular und die Meldung, der User sei nicht zur Durchführung dieser Aktion berechtigt.

Andererseits gibt es in derselben Applikation auch wiederum Dokumente, die die User selbst erstellt haben, und die sie bearbeiten und speichern können. Diese Dokumente verfügen ebenfalls über ein Autorenfeld.

Das Form besteht zu einem großen Teil aus HTML mit einigen eingestreuten Feldern, der Button ist von Hand als <input type="button" onClick="checkValues()" ...> erstellt, die Funktion checkValues() ruft derzeit nur document.forms[0].submit() auf.

Vor einiger Zeit hat das ganze mal funktioniert, und ich meine, an dieser Stelle nichts geändert zu haben und auch keine Zugriffsrechte auf der Datenbank bearbeitet zu haben, aber ganz sicher bin ich mir nicht.
Der Server lief bis heute unter Domino 5, jetzt ist es 6.5.3, aber das scheint für das Problem nicht relevant zu sein. Was ich kürzlich verändert habe war, dass ich die Anmeldung auf Sessions(Single Server) umgestellt habe, um eine selbsterstelle Anmeldemaske nutzen zu können.

Im Moment weiß ich einfach nicht mehr weiter, was das Problem sein könnte. Vielleicht hat hier ja jemand eine Idee, danke schonmal dafür.

[datenbanken24]

Hallo Daniel,

nach Deiner Beschreibung zu urteilen,
scheinen Deine Authorenfelder ok zu sein und Dein Problem scheint woanders zu liegen.

Sollten die im Hintergrund generierten Dokumente nämlich kein ordentliches Autorenfeld haben, könnte sie ein Benutzer (auch im Web) nicht in den Editmode versetzen. An genau dieser Stelle ?EditDocument würde dann schon der neue Login kommen.

Zwei Möglichkeiten auf die Schnelle
(bin sicher, Dir kann geholfen werden, wenn auch nicht gleich bei der ersten Antwort...)

1. Idee:

Gibt es einen WebQuerySave-Agenten in Deiner Maske?
Der läuft im Web mit den Rechten des Unterzeichners (=Dir) und der muß dann auch in den Autorenfeldern stehen.
Und vor allem muß der Unterzeichner im Serverdokument stehen, dass er Agenten ausführen darf.
Vielleicht habt ihr den Unterzeichner beim neuen Server noch nicht in der richtigen Agentenstufe drin.

2. Idee:

Es kann sein, dass das Speichern des Dokuments bei Dir sogar problemlos klappt und die Nachfolgeseite eigentlich Dein Problem ist. $$Return oder der WQS zeigt vielleicht auf eine Folgeseite (nach dem erfolgreichen Speichern), die der Benutzer nicht mit seinen aktuellen Rechten aufrufen darf.


Gruß,
Uwe

[Glombi]

Wird durch den Submit Button ein Agent aufgerufen, der ggf. in einer anderen Datenbank was ändert oder in der gleichen Datenbank andere Dokumente?

Was ich kürzlich verändert habe war, dass ich die Anmeldung auf Sessions(Single Server) umgestellt habe, um eine selbsterstelle Anmeldemaske nutzen zu können.

Hast Du schon getestet, dass wieder zurückzustellen? Funktioniert es dann?

Andreas

[Tode]

Du hast aber nicht zufälligerweise den maximalen Internet- Zugriff auf Leser gesetzt, oder ?

Gruß
Tode

[Daniel S.]

1. Idee:

Gibt es einen WebQuerySave-Agenten in Deiner Maske?

Nein, kein WebQuerySave-Agent.

2. Idee:

Es kann sein, dass das Speichern des Dokuments bei Dir sogar problemlos klappt und die Nachfolgeseite eigentlich Dein Problem ist. $$Return oder der WQS zeigt vielleicht auf eine Folgeseite (nach dem erfolgreichen Speichern), die der Benutzer nicht mit seinen aktuellen Rechten aufrufen darf.

$$Return ruft die Seite auf, von der das Dokument geöffnet wurde, eine Maske mit einer Ansicht. Aber auch ohne $$Return-Feld geht es nicht.

Wird durch den Submit Button ein Agent aufgerufen, der ggf. in einer anderen Datenbank was ändert oder in der gleichen Datenbank andere Dokumente?

Der Submit-Button ist als HTML in die Maske gesetzt <input TYPE="button" onClick="checkValues();" value="Absenden" class="gen" />, die aufgerufene Funktion führt derzeit nur einen Submit durch.

Was ich kürzlich verändert habe war, dass ich die Anmeldung auf Sessions(Single Server) umgestellt habe, um eine selbsterstelle Anmeldemaske nutzen zu können.

Hast Du schon getestet, dass wieder zurückzustellen? Funktioniert es dann?

Das wollte ich grade testen und habe daher mal eben den Session authentication im Server- und im Website-Dokument auf disabled gestellt, dann wollte mich der Server nach einem Neustart gar nicht reinlassen. Das kann ich leider frühestens heute abend weiter verfolgen, da ich den Server lieber schnell wieder zurückstelle.

Du hast aber nicht zufälligerweise den maximalen Internet- Zugriff auf Leser gesetzt, oder ?

Wo setze ich den? Aber ich denke nicht, denn bei anderen Dokumenten treten die Probleme ja nicht auf.


Danke für die Antworten soweit, leider bin ich immer noch nicht weiter. Ich kann mir im Moment einfach nicht erklären, was das Problem sein könnte. Aber ich hoffe noch darauf, dass einer von euch mir helfen kann. Hier ist leider der einzige andere Notes-Programmierer, der etwa 10 Jahre mehr Erfahrung hat als ich, ein paar Monate nach meiner Ankunft gegangen. Und ich bin grade mal seit letztem Sommer mit der Ausbildung fertig.

Ich überlege derzeit, ob ich nicht einen Agenten das Schreiben übernehmen lasse, der mit meinen Rechten  läuft. Aber das ist eigentlich Flickwerk, das ich vermeiden möchte.

[datenbanken24]

Nächster Versuch:

Es gibt eine Sache, die sich mit Session authentication anders verhält als ohne.

Angenommen Deine User kommen als Anonymous auf die Startseite A in Datenbank A.
Dann wollen Sie auf Ihr Dokument in Datenbank B und loggen sich dafür ein.
Editieren, Speichern, klappt alles.

Dann sagst Du, sollen Sie zurückgeleitet werden auf die Startseite A in Datenbank A.

Obwohl in Datenbank A nun Anonymous Zugriffsrechte hat, z.B. Leser,
kommt der eingeloggte Benutzer jetzt nicht mehr drauf,
weil dieser jetzt nämlich auf einmal "Default" ist und nicht mehr "Anonymous".

Und möglicherweise hat "Default" keine Rechte bzw. keine Internetrechte in Datenbank A
So kann es also sein, dass ein eingeloggter Benutzer, der nicht explizit in der ACL steht, kein Leserecht mehr auf eine Datenbank hat, obwohl er es eben als Anonymous noch hatte.

Dies tritt bei Session authentication auf, ohne session authentication dagegen nicht.

Das ganze lohnt sich aber nur zu prüfen, wenn die Ausgangseite (Startpunkt ) und die Dokumente in verschiedenen Datenbanken liegen und Du also nach dem Abspeichern des Dokuments wieder zurück auf eine andere Datenbank springst.

Gruß,
Uwe

[Daniel S.]

Das ganze spielt sich in einer Datenbank ab. Also wird es das wohl auch nicht sein.

 

[datenbanken24]

Schade auch.

Was sagt denn der obligatorische Blick ins Logbuch ?
Bei einer Zugriffsverweigerung steht da oft sogar drin, worauf der Benutzer keinen Zugriff hat.

[Daniel S.]

Unter "Miscellaneous Events" (dort müsste das doch erscheinen, oder?) steht nichts neues, wenn ich den Fehler provoziere. 
Ich habe mir jetzt erstmal einen Umweg über einen Agenten gebaut, damit das ganze erstmal läuft, aber was das eigentlich Problem war, weiß ich immer noch nicht. 

Danke für alle Antworten, wenn jemand noch etwas weiß, das mir weiterhilft, werde ich das noch versuchen.