Das Notes Forum
Domino 9 und frühere Versionen => ND6: Entwicklung => Thema gestartet von: tks am 10.09.08 - 13:01:17
-
Hallo zusammen.
Ich soll in einer DB ein umfassendes Logging (wer hat wann welches Dokument gelesen / gespeichert / gelöscht) einbauen. Soweit ist das auch in Ordnung.
ABÄR.
Der Anwender kann unter "Extras / Debug Lotus Script" den Debugger aktivieren und damit dann auch verhindern, daß Einträge ins Log geschrieben werden.
Wieso hat eigentlich der Normaluser (normale Client-Inst.) den Debugger? Oder haben wir hier was falsch installiert?
Ich konnte jedenfalls als Normaluser (nur Notesclient und Autor-Rechte auf die DB) den Debugger starten und das Script stoppen.
Kann man das verhindern?
-
Mal so ein Schnellschuss: Sperren der Gestaltung ?
-
Hm,
nach notes.net sieht es danach aus, als wäre der Debugger installiert.
-
Weiss nicht an was es liegt,abär..bei einigen meiner Kollegen ist er bei anderen ist er nicht vorhanden.
Also müsste es irgendwo eine Schraube geben??
Boris
-
@klauss: Na ja, wäre ein probates Mittel. Gibt es sonst nix?
@Andre: Wie meinst Du das? Der Client wurde "Standard" installiert. Also einfach weiter, weiter, fortsezten, beenden. Da scheint der Debugger dann automatisch mit an Bord zu sein.
Hmmm. Mal sehen was noch an Ideen kommt.
-
Hab grade mal die Installationsroutine von 6.5.5 gestartet und da ist der Debugger nirgends erwähnt. Man kann ihn weder an- noch abwählen.
Sh....t
-
Hi,
soweit ich mich erinnern kann läßt sich der Debugger nicht deintallieren und deaktivieren. Ich glaub das Bernd (koehlerbv) mal im Bezug auf die Sicherheit erwähnt.
Rainer
-
Hallo,
es gibt einen Notes.ini Parameter, der den Debugger deaktiviert / ausblendet.
NoDesignMenu=1 ==> Verbergen
NoDesignMenu=0 ==> Anzeigen
Gruß
André
-
Herzlichen Dank.
Der Eintrag führt genau zum gewünschten Ergegnis. :D
-
Das ist aber auch nur wieder Suboptimal, so an der ini rumfummeln, oder?
-
Hi André,
ich bin deiner Meinung gefällt mir eigentlich nicht so sehr. Der Benutzer hat da mal wieder eine Hintertür die er sich öffnen kann.
-
Hallo,
das mit der Hintertür stimmt, ich wollte auch nur die Ursache für das verschiedene Verhalten unterschiedlicher Clients erläutern. Als Sicherheitsfeature ist diese Lösung ungeeignet. Da ist ein Auslagern des Scriptcodes (%Include) oder ein Verstecken des Designs garantiert die bessere Alternative.
Gruß
André
-
Wieso "suboptimal" oder "Hintertür"?
Also in der notes.ini werden ja auch andere Einstellungen getroffen. Wenn ist die ganze notes.ini "suboptimal".
Ich finde es eher mies, daß ein normaler Client einen Debugger hat. Und das Design verstecken hat dann wieder andere Tücken. Daher wollte ich mir das eigentlich ersparen.
Natürlich kann der Anwender den notes.ini Eintrag wieder ändern und sich den Debugger wieder holen. Aber für mich ist der Ansatz, den Menüeintrag erstmal auszublenden ausreichend.
-
Du musst ja nicht das gesammt design verstecken.
Es genügt ja, wenn Du das DB-Script mit %Include einbindest.
-
Ich gebe euch Recht. Es gibt bessere Methoden.
Aber für mich ist der ini-Eintrag der "wirtschaftlichste". 8)
-
Neinnein ich wollte nichts schlecht Reden.
Ich finde es auch grausam, das der Normale Client einen Debugger in die Hand bekommt.
Und wie überall, mit der entsprechenden kriminellen Energie...
Und wenn es reicht, ist auch Ok.
-
Du musst ja nicht das gesammt design verstecken.
Es genügt ja, wenn Du das DB-Script mit %Include einbindest.
Kann ich da nochmal nachhaken?
Meinst Du, der Code liegt als .lss Datei irgendwo aufm Netzlaufwerk rum und wird mit %Include eingebunden?
Matthias
-
Ja, das meine ich.
Der Debugger "sieht" den Code der lss nicht ;-)
-
Ja, das wusste ich.
Dachte nur es liegt noch ein anderer "Zauber" hinter %Include ;D
Alles klar, danke.
Matthias
-
Der Zauber hinter dem "%Include" ist noch, dass die Dateien nur beim Kompiliervorgang im Zugriff sein müssten, soweit ich weiß. Aber das sollte so sein, da man ja ansonsten die Dateien für die Clients in Zugriff geben müsste, was sehr aufwändig wäre und was den Vorgang des Versteckens wieder hinfällig machen würde. Denn kann der Client gucken, sollte es eigentlich auch der User können, wenn er denn suchen würde.
-
Das mit dem Kompiliervorgang gilt auch nur eingeschränkt, Markus: Du kannst auch ScriptLibraries verwenden, bei denen der Quellcode (whyever) Dir gar nicht vorliegt - Du kannst nur eben diese in keiner Weise verändern. Auf jeden Fall braucht der Nicht-Designer-Client aber die excluded files natürlich nicht.
Eleganter als %INCLUDE ist es natürlich, wenn man sich ein Programm schreibt, welches den Quellcode aus den Designelementen entfernt. Das erspart, dass man bei den veröffentlichten DBs jedes Mal die eigentlichen Module durch %INCLUDE manuell ersetzen muss (oder man eben gar keine Version mehr hat, in der man einfachen Zugriff auf die Sources hat).
Bernhard
-
Seh das als Fall von: Das rechnet sich nicht.
Selbst in sehr großen Unternehmen mit hohen Sicherheitsstandard, werden die Datenbankskripte nicht von irgendwelchen Debug-Versuchen durch Anwender geschützt. Die konzentrieren sich eher auf wirklich heikle Probleme wie z.B. das Lapptops ein Festplattenkennwort im BIOS setzen müssen.
Das auslagern in lss ist zwar schnell gemacht, aber dann muss man die noch replizieren. Ausserdem gibts ein aufwendigeres Prozedere im Fall von Codeänderungen.
-
Das auslagern in lss ist zwar schnell gemacht, aber dann muss man die noch replizieren. Ausserdem gibts ein aufwendigeres Prozedere im Fall von Codeänderungen.
Was sollte man da replizieren müssen, Axel? Ich sehe das Problem eher in der Wartbarkeit: Entweder, man hat eine zentrale Kiste (für die Entwickler, andere brauchen das ja nicht), oder jeder Entwickler frickelt alleine mit ausgelagerten .lss-Files herum - der grosse Schaden ist da vorherzusehen.
Aus meiner (praktischen) Sicht ideal ist: Die Entwickler arbeiten wie gewohnt (Code-sharing-Tools ggf. vorausgesetzt) und müssen die Produktivversion dann nicht manuell umbauen auf %INCLUDES, sondern ziehen mit einem weiteren Tool auf Knopfdruck den LS-Klartext (aus dem Template) heraus.
Abgesehen davon: Jeder Code sollte auf einen Abbruch (wie auch immer der geschieht) so reagieren, dass danach kein Disaster auftreten kann. Statt einem durch den Debugger abgebrochenen Code kann da ja auch eine Programmfehler oder eine noch nicht bedachte äussere Bedingung zuschlagen und den eigentlich geplanten Ablauf unterbrechen.
Bernhard
PS: Dass der normale Client den Debugger zur Verfügung hat, finde ich natürlich auch mehr als "suboptimal". Für mich als Programmierer sehe ich das aber nicht als bedrohlich - siehe oben: Es gibt auch noch ganz anderes zu bedenken.
-
Danke für die kurze Erläuterung der Grenzen. Aber im Prinzip ist das schon so, wie ich vermutet habe? Wieder was dazu gelernt... Und das seit fast einem Jahr ohne mit Notes zu arbeiten... ;D
-
Ich Dummchen. Die werden da ja reinkompiliert. Hab ich vergessen. ;D