[Allegro] avanti und Register 11

[Thomas Berger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lieber Herr Eversberg, liebe Liste,

Register 11 (frueher auch mal Register 10?) ist ja traditionell besonders
geschuetzt, diese Register wurden eingefuehrt, als DOS-ORDER und DOS-ALF
ihre Schluessel irgendwo sauber unterbringen sollten, und vor allem ALF
setzt da personenbezogene Daten hinein. Klare Sache, dass da ein APAC-
Benutzer nicht einfach so vorbeispazieren sollte.

In cat.api-Datenbanken kommt der aufmerksame Benutzer allerdings ueber
Register 9 (Datumsstempel) oder 10 (Identnummern) durchaus an die
schuetzenswerten Saetze, und gegen das Sichten alter Versionen im
Register 1 bei "//" ist gar kein Kraut gewachsen. Es gab Ansaetze
in v13, ueber die Eigenschaften $P in der Kategoriedefinition
Kategorien zu verstecken, oder geeignete Anzeigeparameter, das ist
m.W. aber nie konsequent verfolgt worden, nur eben die erwaehnte
Zugriffssperre aufs Register 11 war wirkungsvoll (und auch besonders
notwendig, denn im Register als Gesamtschau aufbereitete Daten sind
durchaus "sensibler" als die Einzelinformationen).

Die Sperre ist so realisiert, dass Parameterdateien Nachladeoperationen
in diesem Register vornehmen koennen, der Benutzer aber nicht dorthin
"schalten" kann. Bei a99 ist der Benutzer zweigeteilt: Einmal der
menschliche Bediener (analog zu APAC bekommt er im Index das Register
nicht angeboten), zum anderen die Flexe, die er ausloest (und
womoeglich selber formuliert hat): Hier wurde vorletztes Jahr einiges
an Arbeit aufgewandt, damit nicht nur die naheliegende Moeglichkeit
der direkten Eingabe von "x ...." im Schreibfeld bei niedrigen
Zugriffststufen unterbunden wird, sondern auch indirektere Moeglichkeiten
abgeklemmt werden. Das Ergebnis war durchwachsen, fuer manches
braucht man nun eine hoehere Zugriffstufe zum Lesen als zum Schreiben...

Ich glaube mich im alcarta-Kontext an Diskussionen zu erinnern, wie
es mit symbolischen Registern (etwa "GEH") zu halten ist, die das
Register 11 bezeichnen, bzw. mit Pseudoregistern, die nur einen
Abschnitt davon betreffen: Zum einen steht es ja frei, diese zu
konfigurieren, insofern koennte man sie als harmlos bezeichnen, zum
anderen waere eine Nutzung von frei formulierten Anfragen in einer
Art Suchbefehlszeile denkbar, und daher doch ein besonderer Schutz
gewisser Register noetig. Konsens war allerdings, dass vorgegebene
Flexe und Flips durchaus auf Register 11 zugreifen koennen sollen,
der Benutzer darf halt nur nicht "frei" agieren.

Im avanti-Kontext kennt auch acon einen "Schutz" von Register 11, der
ist nach meinen Tests ziemlich drastisch: Jeder Zugriff (mit |; oder
ueber symbolische Namen) verhaelt sich stillschweigend so, als sei das
Register leer. Interessanterweise ist es mir allerdings gelungen,
durch Anheben der Benutzerrechte in der avanti.conf den Zugriff zu
ermoeglichen, wobei ich die Zugriffsstufe fuer die Datenbank als
solche auf 0 lassen konnte: Was das wirklich bedeutet und ob ich damit
unbeabsichtigt doch die Datenbank zum Schreiben freigegeben habe,
ist mir ohne weitere Tests noch nicht klar.

Die Frage ist allerdings wirklich, ob dieser "Schutz" sein muss: Ich
wuerde eher zwischen legitimen und nicht legitimen Jobs unterscheiden,
letztere duerfen acon gar nicht erst erreichen. Anders als die
statischen Flexdateien von a99 sind acon-Jobs im Avanti-Kontext stets
anlassbezogen dynamisch zusammengebaut, wenn ich einer Web-Anwendung
(etwa meinem OPAC) genuegend vertraue, dass sie Jobs an avanti senden
darf, sollte ich ihr auch alle Registerzugriffe erlauben (ueber eine
Art Volltextsuche kommt sie ja sowieso an alle Daten, und die sind
ja evtl. zu schuetzen). Allerdings sind auch hier wieder Anwendungen
zu beachten, die frei formulierte Suchbefehle ermoeglichen oder die
wie Phpac die aus acon dynamisch abgezogene Liste *aller* Register in
Menues anbieten.

Es koennte sich daher lohnen, ueber differenzierte Berechtigungen
auf Ebene 0 (also bei gewaehrleistetem Schreibschutz) nachzudenken,
ich bin allerdings der Ansicht, dass man den Schutz der Datensaetze
(nicht ladbar bzw. nur teilweise sichtbar) und der Register (nicht
zugreifbar) im Zusammenhang sehen sollte: Jobs, Index- und Anzeige-
parameter einer Anwendung duerfen ja durchaus aufeinander abgestimmt
sein und spontan faellt mir eine Restriktion ein, die "verbotene"
Saetze bei Bedarf ausfiltert bzw. umgekehrt eine Anwendervariable,
die explizit gesetzt sein muss, damit Anzeige erfolgt bzw. die Abschnitte
in der .cpi, die die Benutzereingaben vorbehandeln, die Anfrage
"durchlassen".

[Hintergrund dieser Mail: In allegro-HANS sind auch die Datumsstempel
als personenbezogene Daten konsequent ins Register 11 verlagert. Und
nun will ich in einer Web-Anwendung auf die Aenderungen eines bestimmten
Datums zugreifen: Volltextsuche "geht" zwar, ist in grossen Datenbanken
allerdings nicht schnell genug, bevor nach 120 oder 180 Sekunden zunaechst
das Standard-Timeout des Webservers zuschlaegt.]

viele Gruesse
Thomas Berger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iJwEAQECAAYFAk0/VJQACgkQYhMlmJ6W47PHyQP/TmS6x8uyKk0WVlppKPm3Wm5q
hdHOPIFp6kiZ/V1uHGC6a3LCqMfmmAinTFPO+pjj7SHj39al0ubuWCm657xDjHnX
6VOvJ72OBcvgg8JA1S8xXAM0W/kRGqmPgnRCb4tBS2MkLeDvXZnwY28S3otOyboI
h7lNaoi4l7YJUB5xx24=
=vtXb
-----END PGP SIGNATURE-----