Das Notes Forum
Domino 9 und frühere Versionen => ND7: Entwicklung => Thema gestartet von: Sten am 10.04.07 - 10:13:13
-
Hallo zusammen,
kaum ist Ostern vorbei, schon 'wallert' es wieder durch meinen Kopf, und zwar folgende Frage:
Wie kann ich jemandem eine eigene Notes-Datenbank (*.NSF) als 'Demo-Version' zur Verfügung stellen, ohne das dieser jemand an den Code herankommt.
Sprich, in besagter Demo-Version sollen beispielsweise maximal 10 Dokumente erstellt werden können. Dies wird entsprechend verscriptet/vercodet.
Nun könnte dieser jemand ja einfach mit Admin/Designer/Entwickler-Berechtigungen beigehen,
und im Code genau diese 'Demo-Sperre' rausnehmen, und schon hat er die 'Vollversion'.
Frage: Läßt sich der Zugriff auf den Code sperren ? Danke für richtungsweisende Tip(p)'s.
-
Tipp: Design verstecken.
-
Frage: Läßt sich der Zugriff auf den Code sperren ? Danke für richtungsweisende Tip(p)'s.
Yoo und das auch noch sehr einfach.
Erstelle dir von deiner DB eine Schablone (mit der Endung .ntf). Dann nimmst du deine fertige DB, die du ausliefern willst und wechselst die Gestaltung und dabei kannst du im Dialog die Option "Formeln und LotusScript verbergen" setzen.
Axel
-
Hallo,
habe mich die letzten Tage 'nass' gemacht, und zwar bei dem 'einfachen':
"Erstelle dir von deiner DB eine Schablone (mit der Endung .ntf)."
(Der Rest klappt dann hervoragend.)
Wohl kann ich eine Kopie meiner *.NSF als *.NTF anlegen
und dann per 'Schablone wechseln' die Gestaltung verbergen. Dies kann ich
(oder der Kunde meiner Demo-NSF) aber genauso auch wieder rückgängig
machen, indem ich den Vorgang wiederhole
und den Haken (verbergen) wieder rausnehme.
Daher suche ich nun nach dem korrekten Weg
wie ich mir von meiner DB eine Schablone "mit der Endung .ntf" erstelle.
Danke (und schlagt mich nicht deswegen).
-
Naja, es fehlt bei Dir noch der Schritt
Aus der DB mit verstecktem Design eine neue Schablone erstellen und diese dem Kunden zustellen :-)
-
Ahhh, ein wertvoller Tip(p), nun komme auch ich nicht mehr ran...
Dennoch die Frage: Wird das 'Erstellen einer Schablone' lediglich dadurch erreicht,
dass ich mir eine Kopie der *.NSF als *.NTF anlege ? Das erscheint mir zu einfach,
da es doch immer wieder heisst: 'ERSTELLE Dir von Deiner DB eine Schablone',
das klingt doch nach mehr, als einfach nur umkopieren ? Wo ist denn da mein
Verständnis- bzw. Denk-Fehler ?
-
Du siehst das zu kompliziert!
Notes ist da zum glück so einfach. Nur via Notes eine Kopie erstellen, dabei die Endung von nsf auf ntf wechseln. Anschliessend das NTF öffnen und dort noch "Is Master Template" anhäkeln und einen Namen vergeben. Dann wird es auch unter Templates korrekt angezeigt.
-
So, hier den kompletten Ablauf, bei dem ich denke, dass er OK ist.
Bitte korrigiert mich, wenn dem nicht so ist,
(extra ausführlich für mich und vielleicht auch andere Nutzer):
1. Rechtsklick auf die lauffähige, weiterzugebende und noch bearbeitbare NSF-DB-Kachel
- Datenbank / Neue Kopie / Dateiname: *.NTF (Radio-Knopf: nur DB-Gestaltung kopieren)
Ergebnis: es wächst eine neue DB-Kachel, hinterlegt ist genau diese *.NTF
(ich habe sicherheitshalber den gleichen Namen genommen).
2. Rechtsklick auf diese NTF-DB-Kachel
- Datenbank / Eigenschaften / Reiter: Gestaltung
- Haken setzen bei: "DB ist eine Master-Schablone",
inkl. eines Namens ohne Endung (ich habe sicherheitshalber den gleichen Namen genommen)
3. nochmal Rechtsklick auf diese NTF-DB-Kachel
- Datenbank / Schablone wechseln
Durch die Aktionen aus Schritt 2 ist nun eine zusätzliche Master-Schablone
in der Liste verfügbar. Diese auswählen und den Haken
setzen bei: "Formeln und LotusScript verbergen" - Button "Ersetzen" drücken - OK.
Ergebnis: Diese dadurch 'umadministrierte' *.NTF enthält nur Gestaltungselemente
und den Code (keine Dokumente) und ist nun nicht mehr editierbar (auch für mich nicht).
Diese *.NTF würde nun bei Änderungen an den Kunden verschickt werden.
4. Aktion des Kunden zur Aktualisierung der DB
Die versendete *.NTF in das ...Notes\data - Verzeichnis kopieren (gut, das ist es bei mir).
Der Kunde führt folgende Aktionen durch:
- Rechtsklick auf seine bisherige, produktive NSF-DB-Kachel
- Datenbank / Schablone wechseln
- markieren der entsprechenden Schablone (also die ihm zugesendete *.NTF)
- Button "Ersetzen" drücken
Ergebnis: Bei dieser Aktion ist es nun egal, ob der Kunde
den Haken bei: "Formeln und LotusScript verbergen" setzt oder nicht,
er kommt nicht an den Code heran.
Auf diesem Wege läßt sich also zunächst eine Demo-Version an einen Kunden verschicken,
welche im Nachgang über den beschriebenen Weg angepasst werden kann. So ist sichergestellt,
dass er nicht an den Code heran kommt.
Ziel erreicht, Danke für die Unterstützung (aber bitte nochmal gegenlesen).
-
Nur vier Ergänzungen:
Ich würde mit zwei Schablonen arbeiten: Aus der zuerst erzeugten wird noch eine weitere erzeugt, und erst bei dieser wird wie beschrieben das Design verborgen. Das aber nur wegen "Ordnung und Sauberkeit im Schlachthof".
Beim Erzeugen einer Schablone immer das Kopieren der ACL verhindern (Option abwählen) und danach kontrollieren, ob nicht vom Original die Einstellung "konsistente ACL erzwingen" mitgenommen wurde.
Der Hintergrund: Beim Speichern eines Design-Elements werden sowohl @functions als LS tokenisiert abgelegt - das ist der eigentliche Code, der im Client ausgeführt wird. Der Klartext der @functions und von LS wird hierfür prinzipiell NICHT gebraucht. Beim "hide design" wird nun dieser Klartext aus den Design-Elementen entfernt. Daher hat auch niemand eine Chance, durch Setzen irgendwelcher Haken oder eines geheimnisvollen Bits per Hexeditor den Quellcode wieder hervorzuzaubern - er ist schlicht nicht mehr da. Dies kann man sich (mit hinreichenden Kenntnissen) auch selbst machen, indem man sich Routinen schreibt, die eben diese Extraktion der Sources vornehmen. Dann ist das Design scheinbar nicht versteckt (der Nutzer einer solcherart behandelten DB kann also noch selbst Ansichten erstellen oder Masken anpassen, aber die eigenen Sources sind eben sicher verschwunden).
Abschliessend eine Warnung: Das Update einer DB mit einer "hidden design"-Schablone funktioniert leider nicht hundertprozentig sicher. Auch hier im Forum findet sich solche Fälle ab und an wieder. Ich arbeite daher prinzipiell nur noch mit der oben genannten Variante (die Sources selbst zu entfernen).
Bernhard