Gliederung: rechte Maustaste verhindern

[Ayhan]

Hallo Leute,

ich habe eine Anwendung im Notes. Es sind ca. 150 Ansichten (Useransichten + Systemansichten für Lookups etc.) vorhanden.

Die Anwendung wird über ein Frameset (links ist eine Seite mit einer eingebetteten Gliederung; rechts die Views) aufgerufen.

Ich habe mich für die Gliederung entschieden, weil einige Ansichten sind, die meine Datenbank-Benutzer überhaupt nicht interessieren (leider sind diese sehr experimentierfreudig).

Beispiel:
Es ist als Beispiel ein Konfigurationsdokument pro User vorhanden, das über den Administrator bearbeitet werden kann. Wenn der User in der Anwendung arbeitet, laden wir per Lookups bestimmte Werte aus der User-Konfiguration und zeigen dem User bestimmte Felder an / verstecken bestimmte Felder.

Nun hat seit kurzem ein "total cleverer" über eine andere Datenbank sein Userprofil geändert (hat dort einen Agenten erstellt, über die Ansichten sein Konfigurationsdokument angesprochen und bestimmte Felder gesetzt).

Als ich ihn gefragt habe, wie er überhaupt rausgefunden hat, welche Ansicht er ansprechen muss (da ich ja ein Frameset mit einer Gliederung lade und die Systemansichten ja nicht sichtbar sind) hat er mir folgendes gezeigt:

1. Rechte Maustaste auf einen beliebigen Gliederungseintrag, Link im neuen Fenster öffnen.
2. Dann wird die Anwendung komplett ohne Frameset geladen, und der User kommt in jede View :-((

Der Benutzer hat Autorenrechte auf sein Profil, weil während der Anwendung bestimmte Ergebnisse im Profil hinterlegt werden (ansonsten hätte ich ihm einfach die Rechte entzogen).

Nun, die einfachste Möglichkeit wäre (ohne die Anwendung umschreiben zu müssen) die rechte Maustaste zu verhindern (aber das geht leider nicht - habe mich bereits in unterschiedlichsten Foren "totgelesen"). Daher suche ich nun nach Ideen, wie man evtl. doch noch verhindern könnte, dass über diese Prozedur trotzdem das Frameset mitgeladen wird.

Über Ideen würde ich mich sehr freuen.

lg,
Ayhan

[dirk_2909]

Hallo

Du kannst Die Ansichten, die der Benutzer nicht sehen soll verbergen, in dem Du um den Ansichtennamen eine Klammer setzt.
Den jetzigen Namen würde ich als Alias verwenden, damit alle Scripte funktionieren...

[klaussal]

Den jetzigen Namen würde ich als Alias verwenden, damit alle Scripte funktionieren...

m.E. muss er das sogar.

[dirk_2909]

m.E. muss er das sogar.

Müssen muss man gar nix... 

Man kann ja, wenn man vvviiiieeeelllll Langeweile hat, alle Scripte und Formeln anpassen ;-)

[Glombi]

Das kommt davon wenn man nicht die Standardnahmen für die Frames verwendet!

Also: NotesNavigation für die Outline Page und NotesView für den Rahmen, der die Ansicht anzeigt.

Als Ziel für NotesNavigation muss NotesView eingetragen werden.

Das kann man gar nicht oft genug sagen.

Andreas

[klaussal]

Das kommt davon wenn man nicht die Standardnahmen für die Frames verwendet!

Also: NotesNavigation für die Outline Page und NotesView für den Rahmen, der die Ansicht anzeigt.

@Andreas,

kannst Du dafür mal eine Argumentation liefern ?

[Glombi]

Manfred hat es nett beschrieben:

http://www.madicon.de/content/view/202/1/


Also: IMMER die genannten Rahmennamen verwenden!

Andreas

[dirk_2909]

in unseren Anwendungen habe ich kein einziges Frame den Notes-Standardnamen gegeben
und habe keine Probleme ?!  ....außer in einzelnen Applikationen, da habe ich den standard.

[Tode]

die ganze "rechte-Maustaste-verhindern" und "Ansicht verstecken"- Zauberei hilft doch bei einem solchen User genausowenig (im übrigen auch nicht die Verwendung der Standard- Frame- Namen):

über Ansicht -> Gehe zu bei gedrückter Shift + Strg- Taste kommt der User in ALLE Ansichten, die nicht Leserfeld- geschützt sind, sogar die, die mit Hilfe der Klammern verborgen sind.

Hier hilft nur, Security by Obscurity wegzulassen und ECHTE Sicherheit zu implementieren:
Wenn die Profil- Dokumente nicht manuell vom user geändert werden dürfen (egal ob über bearbeiten oder über einen Agenten mit FIELD x = y), dann müssen diese per Autor- Feld geschützt werden und eventuell nötige Änderungen durch den User müssen -z.b. über eine Dialog- Maske- abgefangen und per "runonserver"- Agent ins Profil geschrieben werden. So braucht der User selbst keine Schreib- Berechtigung auf das Profil und kann diese Sicherheit auch nicht umgehen.

Gruß
Tode

[Ayhan]

Mist,

das dachte ich mir fast, dass das nicht so einfach gehen würde. Ich wende als 1. Step erst mal die Idee von Glombi (Standardnamen) an weil ich keine Lust habe, die Anwendung umzuprogrammieren (es werden nämlich über weitere DBs auch auf die Anwendung zugegriffen).

Als nächstes muss ich das meinem Abteilungsleiter erklären, dass der Aufwand größer ist als man denkt.

Dann muss ich mich noch um diesen "Schlawiner" kümmern - was mach ich mit ihm. Verschwinden lassen  oder lieber mir die Mühe machen, die Ansicht umzubenennen und dies in der Programmierung überall anzupassen. Hmm.. Was ist wohl einfacher 

Spaß bei Seite, danke für Eure antworten.

[Glombi]

Um zu verhindern, dass ein besonders Schlauer eine versteckte Ansicht öffnet, kannst Du im Queryopen ein
Continue = False
einbauen, ggf. Rollen-abhänging. Zusammen mit den Standardrahmen sollte das ausreichend Schutz bieten.
Die User sollten zudem nicht das Recht haben, private Ansichten zu erstellen, damit die nicht selbst was basteln.

Andreas

[Tode]

hmmm... die Sache mit den privaten Ansichten: Kann man das inzwischen wirklich verhindern ? Ich muss gestehen, dass ich es seit Ewigkeiten nicht mehr probiert habe, aber unter R5 war es so:

Berechtiung in der ACL zum erstellen privater Ansichten: Ansichten wurden in der DB selbst erstellt
KEINE Berechtigung: Private Ansichten konnten trotzdem erstellt werden, wurden aber halt in der Desktop.ndk gespeichert (damals noch .dsk): Das erstellen von Ansichten konnte man also nicht verhindern....

Tode