Wenn sowohl die NoteID bzw. UniqueID eines Dokuments als auch Pfad/DB bzw ReplikaID der Datenbank bekannt ist, sieht das schlecht aus.
Und NoteIDs werden schön sequentiell angelegt, da kann man wunderbar ins Blaue tippen und dann weiterzählen.
Ansichten für's Web disablen (oder schlimmer noch: verstecken) hilft auch nichts.
Aber mal zurück:
Im Web hast Du im beschriebenen Szenario nur zwei offensichtliche Möglichkeiten:
a) 'Echte' Zugriffskontrolle oder
b) auf eindeutige IP der Station prüfen (falls statisch)
(a) kannst Du mit üblicher Domino-Security (ACL/Reader-Feldern) abdecken, für (b) habe ich zB den Weg gefunden, fallweise einen nicht vorhandenen WebQueryOpen-Agenten aufzurufen und so einen Fehler vor der Auslieferung des Dokuments zu provozieren (s.
http://www.sns1.de/partner/flamme/wflamme.nsf/Diese%20Ansicht%20gibt's%20doch%20gar%20nicht!!!/afa2bac922659ff5c1256cdf003eb7a5?OpenDocument)
Wenn Dir keine der oben beschriebenen Lösungen gefällt, dann hast Du einfach Pech gehabt. Und zwar auf *jedem* System, denn das ist kein Notes-spezifisches Problem, sondern eine Eigenschaft des HTTP(S)-Protokolls: Wer den Link kennt und das Dokument lesen darf, der kann es eben lesen.
Ansonsten ist halt ein Zugriffsschutz mit Entsperrung durch eine Authentifizierung fällig.
Alles andere wäre 'security by obscurity' und das hat noch niemals zuverlässig funktioniert.
Natürlich
könntest Du zB den Referer der Quellanwendung abprüfen und wenn er aus der richtigen URL stammt, *keinen* Fehler provozieren. Aber wehe, einer kommt drauf - und es sind immer die bösen Jungs, die drauf kommen - wie einfach doch Referer zu fälschen sind, dann kannst Du Dich unverhofft im Mittelpunkt einer öffentlichen Auspeitschung wiederfinden.
Ähnlich luschtische Schutzmechanismen werden in der Praxis aber dennoch gelegentlich verwendet. ZB ACL offen lassen, aber alle klickbaren URLs auf diese DBen mit ..&login 'absichern'.
Gibt's nicht, meint ihr? Gibt's doch!
