java xml agent

[QSecofr]

Hallo zusammen,

ich bin dann mal der Neue hier im Forum (soeben erst entdeckt) und möchte mich doch direkt mal mit einem Problem an Euch wenden, da mich die Suche nicht weiterbrachte.

Folgendes Szenario (Server 6.5.2):
Java XML->XSL-> HTML Agent (siehe Anhang) liest mittels URL Aufruf einen printenden Agenten ein. Dieser Agent printet lediglich den XML Baum, den ich verarbeiten und zu HTML konvertieren möchte.

Alles kein Problem und funktioniert einwandfrei.

Nun kommen allerdings Rechte ins Spiel. Die zu visualisierenden Dokumente im Baum sind zum Teil lesegeschützt. -> Auch noch kein Problem.

Ich trigge den JAVA Agenten über einen URL Aufruf ohne Login und bekomme als Username "Anonymous" -> der XML Print Agent läuft auch als Anonymous und bringt nur öffentliche Dokumente ->  

Aber jetzt kommt das Problem:
Ich melde mich im Browser an und rufe die gleiche URL auf.
EffectiveUser ist nun mein angemeldeter Besucher im JAVA Agent. ->  

Der XML Printagent läuft jedoch als "Anonymous", obwohl ich angemeldet bin.  
Am Server ist SSO aktiviert und es funktioniert auch einwandrei.

Scheinbar reicht der Java Agent meinen User nicht an den Print Agenten weiter.

Hat jmd. eine Lösung parat?

[Marinero Atlántico]

Ich hab das folgende über google gefunden:
http://www-12.lotus.com/ldd/doc/domino_notes/6.5m2/help65_designer.nsf/0/b4ffbf66dd03c05785256d42005118d5?OpenDocument

The Web, this is the either the name of the current Web user (if the Run as web user property is checked in the Agent Properties box) or the name of the person who last saved the script.

Da scheint es also ein vermutlich neues Feature in der Eigenschafts- Box zu geben.

Früher gab das allenfalls den Unterzeichner des Agenten wieder (da Web-Agenten grundsätzlich Server-Agenten sind). Ich meine sogar, dass es da noch eine Sonderregel gibt, bin mir aber nicht so sicher.

Ein Workaround wäre:
Du schreibst den User in dem aufrufenden Dokument in ein Feld und holst dir in dem Java Agenten über

Code

agentContext.getDocumentContext().getStringItemValue("deinFeld");

So in der Art.
Die 6.5er Hilfe scheint aber anzudeuten, dass es da eine bessere Lösung gibt (s.o.)

// AUFRÄUMEN  
         db.recycle();
         session.recycle();

cool!!!

Code

public class XML4JLiaison
extends XMLParserLiaisonDefault

A class that handles interfacing IBM's XML4J2 to the Lotus XSL Processor. 

Ich kannte diese Klasse nicht. Hört sich für meinen Geschmack ein bischen gefährlich an.

Gruß Axel  

[QSecofr]

EffectiveUserName habe ich bereits im Java Agenten testweise verwendet und er funktioniert auch tadellos (welch wunder).

Ich sehe aber im Moment keine Möglichkeiten dem Printagenten diesen User zu übermitteln.

Ich kann dem Printagenten natürlich sagen in welchem Usercontext er laufen soll, nur dies kann ich lediglich hart verdrahten, da die Iris Heineken Truppe mal wieder vergessen hat hier ein Formel oder Script Event zu verankern (siehe Screenshot)

[animate]

klick doch mal die Checkbox "Als Web-Benutzer ausführen" an.

Dann sollte das hier in Kraft treten:

The Web, this is the either the name of the current Web user (if the Run as web user property is checked in the Agent Properties box) or the name of the person who last saved the script.

[QSecofr]

Das hatte ich sowieso drin. Hatte es nur auf dem Screenshot aus...

[Marinero Atlántico]

Ich sehe in deinem Source code keine Stelle, wo ein zweiter Print-Agent aufgerufen wird.
Das kann natürlich sein, dass wenn du von Agent A Agent B aufrufst der User-Context für den Aufruf von Agent A nicht an Agent B übermittelt wird.

Bist du sicher, dass du überhaupt 2 Agenten brauchst. Warum?

Also: Wenn du uns sagst wie du den 2. Agenten aufrufst, können wir dir vielleicht sagen, wie der 2. Agent der Username übermittelt wird.

Gruß Axel

[Ralf_M_Petter]

Ich versteh eigentlich nicht ganz, warum du 2 Agenten brauchst, verkompliziert das nicht alles, warum kann nicht der Agent, der das XML macht auch gleich die Konvertierung in XML machen.

Grüße

Ralf

[QSecofr]

Nun diese Möglichkeit habe ich natürlich.

Leider handelt es sich bei dieser Anwendung um eine Navigator Datenbank, die für das Web die Navigation zur Verfügung stellt. Der XML Agent ist als Webservice implementiert, damit auch andere Anwendungen (ja, wir haben leider auch nicht Notes DBs) auf diese Navistruktur zugreifen können.

Ich wollte eigentlich keine doppelte Codepflege dabei machen müssen. Aber scheinbar gibt es keine andere Lösung.

Eventuell ginge auch noch ein Servlet, aber das habe ich bislang noch nie gemacht und weiss nicht wie Notes mit Authentifizierung an dieser Stelle funktioniert.

Hat schon mal jmd. ein Servlet mit Rechten realisiert?

[Ralf_M_Petter]

Hm jetzt ist mir alles klar!

Der Grund ist, dass sich dein Javaagent ja als neuer Client beim Server anmeldet wenn er auf ein URL zugreift. Eventuell könnte funktionieren, dass die UserName und Password im URL mitschickst. Habe es nicht probiert aber
http://<username>:<password>@host/url müsste funktionieren.

Grüße

Ralf

[Marinero Atlántico]

Wenn du den 2. Agenten mit Agent.run() startest, kannst du auch ein temporäres Dokument erstellen und dem 2. Agenten die NodeID übergibst. Der erste Agent würde dann den Usernamen in dieses temporäre Dokument schreiben.
(näheres s. Doku Agent.run () in LotusScript oder Java Hilfe von Lotus.
Du kannst diese Temporären Dokumente dann jede Nacht löschen.

Moment. Der XML Agent ist als Web Service implementiert?
Kannst du nicht vielleicht dem Webservice so erweitern, dass du den Usernamen als zusätzlichen Parameter / Element an den Webservice übergibst?

Gruß Axel

[Ralf_M_Petter]

Hallo Axel!

Deine Aussagen sind mir nicht ganz klar. Wenn du denn Source anschaust, dann siehst du ja, dass er den Agent nicht einfach startet, sondern der Agent der das XML erstellt, wird indirekt durch den Zugriff auf ein URL gestartet und das Ergebnis, dass über den Agenten als HTTP Datenstrom zurückgeschickt wird ist der Input für den XMLTransformer. Deshalb nützt ihm auch das Agent.run nichts. Was mir weiter noch unklar ist, interessiert mich aber wie bringst du dem Agent bei, dass er unter einer bestimmten Usernamen laufen soll, der ihm zur Laufzeit des Agenten erst bekannt ist?

Grüße

Ralf

[Marinero Atlántico]

Da hast du Recht.
Normalerweise würde ich den Usernamen an die URL anhängen. Also url-encoded (dh mit maskierten Leerzeichen, Sonderzeichen, etc.) mit &name=<variable>.
Geh mal davon aus, dass die URL irgendwo aus einer Notes-Page oder Form aufgerufen wird (wie auch immer). Dann kann man den Namen in diesem Gestaltungselement, von dem der Agent aufgerufen wird, ermitteln und an die URL hängen.
Auch wenn der Agent zum Start der Anwendung aufgerufen werden soll, ginge das, indem man eine form dazwischenschaltet, die direkt auf den Agenten redirektet.

Gruß Axel

[Ralf_M_Petter]

Warum so kompliziert, was hälst du von meinem Vorschlag weiter oben, einfach im Url für den Importer Usernamen und Passwort mitzuschicken, habe zwarnicht probiert, müsste aber funktionieren.

http://<username>:<password>@host/url&login

Grüße

Ralf

[Marinero Atlántico]

Du meinst das funktioniert

Bei meinem derzeitigen Testserver wäre das:
http://Axel Janssen:sag_ich_nicht@LN02/url?login

Also für meinen Geschmack müsste man das zumindest urlencoden, also ohne Leerzeichen.

Kann mich aber irren.

@QSecoFr: Wieso eigentlich Webservice.
Wird der jetzt über Webservice aufgerufen oder einfach über HTTP-GET (also eine URL)?
Webservice ist für mich mit SOAP und so.

Gruß Axel

[Ralf_M_Petter]

Urlencode ist klar, habe gerade probiert, mit Mozilla 1.7 funktioniert es. Es kommt aber zuerst noch eine Sicherheitswarnung ob man sich wirklich mit dem Uernamen einloggen will. Aber ich denke mal, dass die Java Klassen QSECOFR verwendet diese Einschränkungen nicht verwenden.

Übrigens gehe ich mal aus, dass ein User der QSECOFR heisst mir Sicherheit sowieso nicht viel am Hut hat oder;-)

Grüße

Ralf

[Marinero Atlántico]

Übrigens gehe ich mal aus, dass ein User der QSECOFR heisst mir Sicherheit sowieso nicht viel am Hut hat oder;-)

Wieso?
QSecoFr kommt aus dem westlichen Ruhrgebiet, ist über 30 und hat eine überdurchschnittlich große Nase.

Eigentlich sollte man Usernamen und Passwort nie per URL übertragen.
Die Lösung einfach den Usernamen (ohne Passwort) an die URL anzuhängen wäre ein bischen sichererer.

Gruß Axel

[Thomas Schulte]

Weil Qsecofr das Kürzel für die Anmeldung als superadmin mit vollen Rechten an der AS/400 ist.

Thomas

[Ralf_M_Petter]

Das ist korrekt Thomas, aber das Q steht dafür, dass es ein Systemobjekt von OS/400 (i5/OS) ist und das SecOfr ist die die Abkürzung für Security Officer. Also sollte eigentlich der sein, der für Sicherheit zuständig ist. Was meiner Meinung von der IBM etwas seltsam gedacht ist, denn genau der sollte ja wissen, das man nicht mit Superusern arbeiten soll.

Aber ich freue mich, dass ich nicht der einzige mit Domino auf der Iseries bin.

Grüße

Ralf

[QSecofr]

Hallo zusammen,

@Marinero Atlántico: Die 30 habe ich hinter mir, aber das halte ich für nicht dramatisch, da dies ja auch eine nur durch Suizid zu beeinflussende natürliche Sache ist. :-)

Username:Password in der URL ist natürlich tabu....

Eine Lösung ist auch in Sicht....
XML Baum wird im XML/XSL Agenten (der JAVA Agent) generiert. Der XML Baum wird mittels einer JAVA Script-Bibliothek generiert, so dass ich den Code nur einmal vorhalten muss.

Der Webservice (Anmerkung zu obigen Kommentar: Webservices müssen sich nicht zwangsweise über das SOAP Protokoll unterhalten) greift ebenfalls auf diese Library zu...

Erste Tests zeigen, dass es so einwandfrei funktioniert.

Ach ja und nochwas zu meinem QSecofr... Der ruht noch aus alten AS/400 Zeiten richtig.

Heute laufen jedoch alle Domino Server ausschließlich auf Win 2000/2003 ....

[Marinero Atlántico]

Wie sprichst du diesen XML-Agenten an?
Über HTTP Url-Connection (oder verwandtes)?