Lesezeichen + Kachel beim CLOSE entfernen?

[LN1991]

Besteht die Möglichkeit, für die aktuelle Datenbank beim CLOSE derselben das Lesezeichen und die Kachel zu entfernen?

[Klafu]

http://www-01.ibm.com/support/docview.wss?uid=swg21097270

Chris

[LN1991]

Vielen Dank für diesen Hinweis. Diese Funktion erfordert aber eine Aktionen des Benutzers. Das Lesezeichen bleibt erhalten.

Anwendungsscenario
Der Benutzer besitzt Leserechte auf eine DB für @DbLookup.
Jetzt richtet er sich (ungewollt und unerlaubt) ein Lesezeichen und eine Kachel ein.
Das Datenbankscript und seine Lookup-View verhindert eine direkte Öffnung: "Call source.close"
Sobald er eine Nutzung versucht, wird sich die DB automatisch schließen.
-> JETZT möchte ich gerne auch sofort sein Lesezeichen und seine Kachel entfernen.

Er soll demotiviert werden, weitere kriminelle Energie aufzuwenden.  

[Klafu]

Wenn es sich mit Notes 9 nicht geändert hat, könnte es schwer werden.

It is not possible to remove a database icon from the Notes client workspace using LotusScript, JavaScript, or Notes API.

[ascabg]

Hallo,

Ist ja alles gut und schoen.

Aber der Benutzer beseitzt Leserechte.
Wie er jetzt auf die DB zugreift ist nicht von ausschlaggebender Bedeutung.

Wenn er weiss, wo die D liegt, dann kann er sich das Lesezeichen, welches nicht
zwingend beim Zugriff ueber einen Lookup angelegt wird, "manuell" hinzufuegen.

Und wies es in dem Link schon angedeutet wird, gibt es mit den "Bordmitteln" aus meiner
Sicht keine Loesung fuer Dein Vorhaben.

Es sei denn ihr nehmt Geld in die Hand und kauft Euch entsprechende Produkte von
Drittanbietern. (Panagenda Marvel Client, ob es der Client Genie von BCC kann weiss ich
jetzt nicht mehr so genau, ...)


Andreas

[thkn777]

Hallo LN1991,
notesUIWorkspace.OpenDatabase hat einen Parameter, mit dem das Anlegen der Kachel auf dem Desktop verhindert werden kann.

Vielleicht ist das ein Weg für Dich? Die Kachel erst gar nicht zu erzeugen? Ist nicht genau das, was Du gefragt hast... ich weiß  

Viel Erfolg,
Th.

P.S. Für die Nutzer, die WIRKLICH kriminelle Energie haben, wird ein "seltsames" Verhalten der DB (Versteckspielerei, source.close, etc.) die ganze Sache nur noch interessanter und reizvoller machen.

[ascabg]

HAllo

@thkn777
Soweit ja richtig.
Ich habe es jedoch so verstanden, dass aus "DB A" ein Lookup aufgerufen wurd, welcher
Daten aus "DB B" ermittelt.

Und da scheitert es dann schon mit dem UIWorkspace.


Andreas

[Peter Klett]

Nicht ganz. Es müsste vor dem Lookup die Datenbank auf diese Weise geöffnet werden und auch gleich wieder geschlossen. Danach ist es nicht mehr möglich, die Kachel auf dem Desktop anzulegen, bis Notes neu gestartet wurde.

Aber letztlich ist das alles kein wirklicher Schutz. Ohne den konkreten Kontext zu kennen, ist es schwierig, das zu beurteilen, aber ich stelle mir eine Lösung vor, die eben nicht mit einem Lookup des Benutzers die Daten holt, sondern über einen Agenten mittels Agent.RunOnServer. Der stellt die benötigten Daten in einer separaten Datenbank zur Verfügung, z.B. lesegeschützt nur für den angemeldeten Benutzer (und den Server usw.). Die Datenbank mit den kompletten zu schützenden Daten liegt auf dem Server und kein normaler Benutzer hat Zugriff darauf. Der mit besonderen Rechten ausgestattete Agent holt genau die benötigten Daten in die Pufferdatenbank, aus der sich die Anwendung dann die Daten nimmt und wieder vernichtet (Dokument nicht löschen, sondern recyceln). Den Zugriff auf die Daten kann man bei Bedarf noch weiter schützen, z.B. max. drei Zugriffe pro Benutzer und Tag, so dass nicht ein Mitarbeiter auf diese (mühselige) Art die gesamte Datenbank abfragen kann.

[koehlerbv]

Man müsste jetzt wissen, um was es wirklich geht und was man vor dem neugierigen Blick schützen will, wovon doch eigentlich nur Ausschnitte sichtbar sein sollen. Ich kann man mir da jetzt soviele Szenarien vorstellen, daß die Zeit (und wegen mangenlnden Informationen auch die Lust) nicht ausreicht, um dazu mögliche Lösungen aufzumalen.

Wenn Helmut mehr zur gegebenen Situation schreibt, wird er auch mehr Vorschläge bekommen. Ein Database icon oder ein Bookmark "so einfach" wieder verschwinden zu lassen, wenn der User das Recht hat, es sich auf etlichen Wegen selbst zu erzeugen, geht jedenfalls nicht (sinnvoll).

Bernhard

[LN1991]

In den letzten Tagen konnte ich viele Ideen und Konzepte erproben. Einige führten mich in Sackgassen, andere ließen wieder neue Ideen entstehen.

Von meiner Ursprungsidee musste ich dabei Abschied nehmen. Die Darstellung der Kacheln werde ich nicht verhindern können.
In diesem Zusammenhang auch meinen herzlichen Dank für die vielen Gedanken und Anregungen.

Wenn also der User die Kachel sehen kann, muss ich davon ausgehen, dass manch einen die Neugier packt. Daher muss ich effektiv den Zugang zu Detailinformationen verhindern.
Das Konzept sieht hierzu - in Kurzform - folgendermaßen aus:

- Keine Feldinhalte sichtbar
Gestaltung verborgen

- Keine Kopie oder Replikation
ACL-Anpassung

- Export verhindern
Erweiterte DB-Eigenschaften

- Kein direkter View-Aufruf
Close auf den Ebenen DB+View
Kontrollierter Zugriff über embbeded Views

- Admin-Unterstützung
offene Gestaltung auf Admin-Server im Cluster
keine Userzugriffe auf diesen Server

Habe ich an alles gedacht? Oder vielleicht eine Lücke übersehen?
Verbesserungsvorschläge sind jederzeit willkommen.

[Peter Klett]

Wie willst Du die Gestaltung auf dem Anwendungsserver geschlossen halten und auf dem Adminserver offen?Zwei Schablonen, eine offene, eine geschlossene, Replikation der beiden Datenbanken nur mit Editorrechten? Tu Dir das nicht an.

Geschlossene Gestaltung ist überhaupt kein Schutz. Nur weil die Felderliste nicht angezeigt wird, bedeutet das nicht, dass man nicht an die Daten herankommt. Kopiere mal ein Dokument aus einer geschlossenen Datenbank in eine offene, dort ist die Felderliste sichtbar.

Auch alle anderen Schutzmechanismen, die Du aufgezählt hast, sind reine Frontend-Mechanismen, die den "einfachen" Benutzer abschrecken, aber keinen Schutz darstellen.

Wenn es wirklich schützenswerte Daten sind, gibt es nur eine Maßnahme. Kein Zugriff, alles andere kannst Du vergessen. Ich bin sicher, dass ich Dir jede Deiner genannten Maßnahmen mit etwa 10 Zeilen Script über das Backend aushebele.

[LN1991]

Wie willst Du die Gestaltung auf dem Anwendungsserver geschlossen halten und auf dem Adminserver offen?Zwei Schablonen, eine offene, eine geschlossene, Replikation der beiden Datenbanken nur mit Editorrechten? Tu Dir das nicht an.

Schablone = 1x
Datenbank = 2x (Repliken auf A+B)

"Gestaltung verbergen" auf Server A wird NICHT auf die Replik auf Server B übertragen.

[LN1991]

Geschlossene Gestaltung ist überhaupt kein Schutz. Nur weil die Felderliste nicht angezeigt wird, bedeutet das nicht, dass man nicht an die Daten herankommt. Kopiere mal ein Dokument aus einer geschlossenen Datenbank in eine offene, dort ist die Felderliste sichtbar.

Kopieren darf der User nicht mehr.
ACL = Kein Häkchen bei "Dokumente replizieren oder kopieren"

[LN1991]

Wenn es wirklich schützenswerte Daten sind, gibt es nur eine Maßnahme. Kein Zugriff, alles andere kannst Du vergessen. Ich bin sicher, dass ich Dir jede Deiner genannten Maßnahmen mit etwa 10 Zeilen Script über das Backend aushebele.

Der User hat keine Entwicklerrechte.

[Peter Klett]

Der User hat keine Entwicklerrechte.

Der User kann sich lokal eine Datenbank erstellen und darin einen Scriptagenten schreiben, hierzu benötigt er noch nicht einmal einen Designer.

Solltest Du das auf irgendeine Weise verhindern können, was ich extrem zu bezweifeln wage, schreibt er sich ein Macro in Excel oder Word.

Und falls Deine nächste Frage sein sollte, wie der Benutzer in die Lage kommen sollte, solch ein Script zu schreiben, hier die Antwort: Er fragt atnotes (s.u.).

Kopieren darf der User nicht mehr.
ACL = Kein Häkchen bei "Dokumente replizieren oder kopieren"

Dim db As New NotesDatabase ("server", "dateinamequelle")
Dim dblokal As New NotesDatabase ("", "dateinameziel")
Dim col As NotesDocumentCollection
Dim doc As NotesDocument
Dim doclokal As NotesDocument
Set col = db.AllDocuments
Set doc = col.GetFirstDocument
Do While Not doc Is Nothing
  Set doclokal = New NotesDocument (dblokal)
  Call doc.CopyAllItems (doclokal)
  Call doclokal.Save (True, True)
  Set doc = col.GetNextDocument (doc)
Loop

Schablone = 1x
Datenbank = 2x (Repliken auf A+B)

"Gestaltung verbergen" auf Server A wird NICHT auf die Replik auf Server B übertragen.

Mag sein, habe ich nie probiert. Und Updates machst Du wie?

[LN1991]

Schablone = 1x
Datenbank = 2x (Repliken auf A+B)

"Gestaltung verbergen" auf Server A wird NICHT auf die Replik auf Server B übertragen.

Mag sein, habe ich nie probiert. Und Updates machst Du wie?

Der Designer-Task auf dem Server läuft auch bei verborgener Gestaltung.

Der User kann sich lokal eine Datenbank erstellen und darin einen Scriptagenten schreiben, hierzu benötigt er noch nicht einmal einen Designer.

Das ist in der Tat eine harte Nuß. Danke für den Hinweis.

Mein erster Gedanke:
Logbuchauswertung und Mitteilung an den Admin, wenn viele Dokumente in kurzer Zeit gelesen werden.
Dann ist das Kind zwar schon in den Brunnen gefallen, aber der Mitarbeiter auch. 

Aber dann:
Was ist, wenn er das stückenweise macht?
Oder er wertet mit einem Hotspot im Body-Feld den Inhalt des aktuellen Dokumentes aus?
Davon bekommt niemand etwas mit.

Oh je, und ich hatte schon Hoffnung, das alte Konzept mit neuen Mitteln verbessern zu können.
Seit 22 Jahren arbeitet die Anwendung kontrolliert mit getrennten Datenbanken und Lesefeldern.
Ich werde wohl dabei bleiben müssen. 

[Peter Klett]

Der Designer-Task auf dem Server läuft auch bei verborgener Gestaltung.

Das ist klar. Und das Update auf dem geschlossenen Server (Schablone mit verborgener Gestaltung) repliziert sich auf den offenen Server so, dass die Gestaltung dort offen ist? Dass die Formeln und Scripte dort weg sind, ist klar, denn die fehlen ja schon in der Schablone, aber die Felderliste ist sichtbar, also die Datenbank "glaubt", dass die Gestaltung offen sei und zeigt die Felderliste? Das wäre eine weitere Variante, wie man halboffene Schablonen erstellen kann. Interessant, wenn es so wäre...

[Peter Klett]

Oder er wertet mit einem Hotspot im Body-Feld den Inhalt des aktuellen Dokumentes aus?

Wenn das nur Felder sind, die zur Anzeige berechnet sind und zur grundsätzlichen Verarbeitung durch den nichtberechtigten User nicht benötigt werden, kannst Du die in einen zugriffsgesteuerten Abschnitt packen, dort werden die nicht berechnet, wenn der Zugriff fehlt.

[LN1991]

Der Designer-Task auf dem Server läuft auch bei verborgener Gestaltung.

Das ist klar. Und das Update auf dem geschlossenen Server (Schablone mit verborgener Gestaltung) repliziert sich auf den offenen Server so, dass die Gestaltung dort offen ist? Dass die Formeln und Scripte dort weg sind, ist klar, denn die fehlen ja schon in der Schablone, aber die Felderliste ist sichtbar, also die Datenbank "glaubt", dass die Gestaltung offen sei und zeigt die Felderliste? Das wäre eine weitere Variante, wie man halboffene Schablonen erstellen kann. Interessant, wenn es so wäre...

Scenario
Die Formeln sind in der Schablone sichtbar.
Ich wechsele die Gestaltung auf Server A mit der Verbergen-Option
Auf Server B (Cluster) liegt eine Replik der Datenbank.
Dort sind nicht nur die Felder sichtbar. Auch der Code kann dort eingesehen werden.

Gerade habe ich testweise eine direkte Code-Änderung auf Server B vorgenommen.
Die Änderung konnte ich auf Server A erkennen.

Merkwürdigerweise waren auf Server B einzelne Spalten einer View nicht offen.
Daher Vorsicht: Scaleneffekte sind nicht auszuschließen.

Wenn das nur Felder sind, die zur Anzeige berechnet sind und zur grundsätzlichen Verarbeitung durch den nichtberechtigten User nicht benötigt werden, kannst Du die in einen zugriffsgesteuerten Abschnitt packen, dort werden die nicht berechnet, wenn der Zugriff fehlt.

Die Werte müssen für Auswertungen durch andere Benutzer im Dokument stehen. Keine Chance.

Ich hatte schon kurz überlegt (und verworfen), jeden Datensatz doppelt zu führen (Mitarbeiter + Vorgesetzter). Dann bleibe ich lieber bei der jahrzehntelang erprobten Methode der doppelten Datenbanken.

Leistungserfassungssätze eines Mitarbeiters werden täglich in die zweite DB verschoben. Erst dort werden sie bewertet und stehen für Auswertungen zur Verfügung.

[Peter Klett]

Scenario
Die Formeln sind in der Schablone sichtbar.
Ich wechsele die Gestaltung auf Server A mit der Verbergen-Option
Auf Server B (Cluster) liegt eine Replik der Datenbank.
Dort sind nicht nur die Felder sichtbar. Auch der Code kann dort eingesehen werden.

Habe Dein Scenario mal nachgeprüft. Kannst Du wirklich den Code einsehen, oder siehst Du in Wirklichkeit nur die Gestaltungselemente? Öffne mal z.B. eine Maske oder Scriptbibliothek, da kommt eine entsprechende Fehlermeldung.

Gerade habe ich testweise eine direkte Code-Änderung auf Server B vorgenommen.
Die Änderung konnte ich auf Server A erkennen.

Merkwürdigerweise waren auf Server B einzelne Spalten einer View nicht offen.
Daher Vorsicht: Scaleneffekte sind nicht auszuschließen.

Korrekt, das sind die Spalten mit Formeln, denn Scripte und Formeln sind ja verborgen. Diese Datenbank ist jetzt halboffen, man sieht die Gestaltungselemente, aber nicht die Gestaltung (Scripte, Formeln)

Neulich war hier die Frage gestellt, wie man eine halboffene Schablone/Datenbank erstellt. Hier also noch eine sehr einfache und interessante Variante:

Eine nackte Datenbank auf dem Server erstellen und auf lokal replizieren
Auf dem Server die Schablone wechseln, dabei "Formeln und LotusScript verbergen" ankreuzen
Die lokale Datenbank mit dem Server replizieren
-> die lokale Datenbank ist jetzt halboffen

Kein Hexeditor oder sonstiges Tool notwendig. Cool!