Rechte

Allgemeine Zugriffsrechte

In vielen Fällen reicht es völlig aus, die Rechte für unangemeldete Nutzer zu bestimmen. Sie selbst, als Eigner haben immer alle Rechte an der Datenbank, ebenso der Programmcode, den Sie in Ihren Templates verwenden: Die dort verwendeten Funktionen können beliebig auf Ihre Datenbanken zugreifen. Es gibt 4 Zugriffsarten, die beliebig kombiniert werden können:

• Lesen
• Schreiben
• Ändern
• Löschen

Beispiele:

• Sie können Aussenstehenden keinerlei Rechte geben: Niemand kann dann ohne Zugangsberechtigung auf diese Datenbank zugreifen. Sie dient also z.b. für ihre persönlichen Adressdaten.
• In den meisten Fällen geben sie Aussenstehenden das Recht, ihre Datenbank zu lesen. Sie sind dann derjenige der neue Daten hinzufügt oder bestehende Daten pflegt. Sie sind also der Redakteur. Anwendungsbeispiele sind ein News-system, eine Linkliste oder eine Produktdatenbank
• Sie können ihren Nutzern auch erlauben, selbständig Daten hinzu zufügen. Ein Forum wäre dafür die klassische Anwendung. Unliebsame Einträge können Sie, nachdem Sie sich angemeldet haben, einfach löschen.
• Möglich wäre auch, ihren Nutzern NUR schreibende Rechte zu geben. Z.B. eine Umfrage, in der sie nur Rückmeldungen ihrer Nutzer abfragen wollen, bräuchte diese Einstellung.

Nutzer-Datenbanken

Um einen ausgefeilteren Schutz zu realisieren, bietet baseportal Nutzerdatenbanken an. Sie können für jede Datenbank eine eigene Nutzer-Datenbank erstellen oder auch eine Nutzer-Datenbank für mehrere Datenbanken einsetzen. Eine einfache Nutzerdatenbank könnte so aussehen:

Name	Passwort	EMail	Lesen	Schreiben	Ändern	Löschen	Ausführen
*			*
sepp	Sjm72H	sepp@web.de	*	*
liese	edhi6xd	liese@yahoo.de	*	*
gregor	ysdfhuie3	gregor@gregor.de	*	*	*	*

Die Nutzer sepp und liese können lesend und schreibend auf die Datenbank zugreifen; der Nutzer gregor kann zusätzlich ändern und löschen. * ist ein spezieller Nutzername - hier werden die Rechte für unangemeldete Nutzer gesetzt, wie oben beschrieben. Ein "Passwort" und ein Eintrag beim "EMail"-Feld erübrigt sich damit natürlich.

Rollen

Bei komplexeren Rechten wäre es sehr mühsam bei vielen verschiedenen Nutzern diese immer wieder neu eingeben zu müssen. Beispiel: Sie haben interne Mitarbeiter definiert, die Zugriff auf die Felder "Name", "Strasse" und "Ort" haben. Später ergibt sich, dass sie auch noch das Feld "Telefon" lesen dürfen - nun müssten Sie bei jedem einzeln die Änderung durchführen. baseportal bietet dafür eine bessere Lösung: Wie man am Beispiel sieht, kann man Nutzern bestimmte "Rollen" zuteilen und über diese Rollen ergeben sich dann die Rechte - so haben z.B. alle News-Redakteure das Recht zu schreiben. Innerhalb der Datenbank ist eine Rolle nichts anderes als ein Nutzer. Obwohl nicht zwingend, ist es keine schlechte Idee, Rollen immer komplett gross zu schreiben, um sie so einfach von normalen Nutzern unterscheiden zu können. Es können auch mehrere Rollen, durch Komma getrennt angegeben werden. Ein Nutzer erhält dann alle Rechte der einzelnen Rollen zusammen. Es werden auch die bei den Rollen angegebenen Rollen weiterverfolgt (bis maximal 50), so dass eine komplexe Rechtehierarchie aufgebaut werden kann.

Know-How Kommas (,) die in Rollennamen enthalten sind, müssen Sie mit einem vorangestellten "Backslash" \ markieren. Sinnvollerweise sollten Sie einfach keine Kommas in Rollennamen verwenden.

Hier eine kleine, aber feine Nutzerdatenbank mit verschiedenen Rollen: undef @_sel;

Unangemeldete Besucher dürfen das Feld "Name" lesen, sonst nichts. MITARBEITER dürfen die Felder "Name", "Strasse", "Ort" und "Telefon" lesen, in diesem Fall haben diese Rolle die Nutzer berger und krumpawesch. Letzterer hat zusätzlich die Rolle EINGEBER, d.h. er darf auch komplette Einträge (in alle Felder) machen. Die Nutzerin gabi hat die Rolle KONTROLLEUR, mit der sie alle Felder lesen und Einträge löschen darf. Beim Nutzer fongi schliesslich werden die Rechte aus der Rolle KONTROLLEUR um das Recht, alle Felder zu ändern, ergänzt. Die Weitervererbung von Rechten sieht man am Nutzer Schlumpf, der die Rechte von KONTROLLEUR2 bekommt und zusätzlich die Rechte von KONTROLLEUR (die Rolle von KONTROLLEUR2). Rollen erhalten normalerweise kein Passwort: Dadurch ist eine Anmeldung unter deren Namen ausgeschlossen. Wenn Sie wollen, können Sie aber auch Rollen Passwörtern geben und Sie damit wie normale Nutzer behandeln.

Einrichtung Nutzer-Datenbanken

Bei der Einrichtung einer Nutzerdatenbank gibt baseportal zwei verschiedene Typen zur Auswahl vor:

Typ Felder Kommentar
Einfach Name, Passwort, EMail, Lesen, Schreiben, Ändern und Löschen Die Rechte sind als "checkbox" definiert, damit vergibt man das Recht für alle Felder. Es gibt auch keine Rollen. In vielen Fällen reicht diese Nutzer-Datenbank völlig aus.
Felder Name, Passwort, EMail, Rollen, Lesen, Schreiben, Ändern, Löschen, Erstellt am und Gesperrt Die Rechte sind als "text"-Felder definiert, d.h. ein Recht kann für bestimmte Felder vergeben werden.

Hier die einzelnen Felder und ihre Funktionen:

Feld Beschreibung
Name Der Name den der Nutzer zur Anmeldung verwenden muss. Pro Nutzerdatenbank darf ein Name nur einmal vergeben werden. Gross/Kleinschreibung wird unterschieden.
Passwort Das Passwort das der Nutzer zu Anmeldung verwenden muss. Gross/Kleinschreibung wird unterschieden.
EMail Die Email des Nutzers. Immer gut zu wissen, falls Probleme auftreten. Wird von baseportal verwendet um einem Nutzer, der sein Passwort vergessen hat, dieses automatisch an seine EMail-Adresse zu schicken. Da das sehr häufig vorkommt ist dies eine grosse Arbeitserleichertung für den Administrator.
Rollen Bestimmt die Rollen (Gruppen) eines Nutzers. Es können mehrere, durch Kommas getrennt (ohne zusätzliche Leerzeichen) angegeben werden; diese werden der Reihe nach geholt und zusammengeführt gewertet. Auch die normalen Rechte eines Nutzers können zusätzlich angegeben werden.
Lesen, Schreiben, Ändern, Löschen Diese 4 Felder bestimmen die Rechte für eine Datenbank. Dies kann für einzelne Felder bestimmt werden, die Namen der Felder müssen dann hintereinander weg durch Komma getrennt (ohne zusätzliche Leerzeichen) im entspechenden Rechte-Feld stehen. Undefinierte Felder werden einfach ignoriert. Ein Stern (*) bedeutet die Rechtefreigabe für alle Felder der betreffenden Datenbank.
Gesperrt Ist dieses Feld markiert, ist der Nutzer gesperrt und kann sich nicht anmelden.
Erstellt am Datum an dem der Nutzer eingetragen wurde.

Natürlich ist auch eine Nutzerdatenbank eine ganz normale baseportal-Datenbank. Das bedeutet, sie können deren Aufbau völlig frei selbst bestimmen und beliebige eigene Felder hinzufügen oder nicht benötigte Felder löschen. Es werden einfach die angegebenen Feldnamen vom Anmelde-Modul verwendet und nur wenn diese vorhanden sind, wird deren Funktion ausgeführt. Als zusätzliche Felder bieten sich ein "Kommentar"-Feld oder ein "Geburtstag"-Feld an. Sie können auch eine komplette Adress- und Kundenverwaltung darauf aufbauen!

Know-How Das Id-Feld einer Datenbank ist, sofern ein anderes Feld lesbar ist, ebenfalls automatisch lesbar. Dies ist nötig, da die Id immer zur Auswahl und Bestimmung eines Datensatzes gebraucht wird. Sind beim Recht Löschen einzelne Felder definiert, so werden bei einem "Löschen"-Befehl genau diese Felder geleert. Ändern kann der Nutzer, sofern er nicht zusätzlich die entsprechenden Ändern-Rechte besitzt, diese Felder nicht. Nur wenn alle Felder mit dem * zum Löschen freigegeben sind, wird der Datensatz tatsächlich aus der Datenbank gelöscht.

Rechte der Nutzer-Datenbank

Da eine Nutzer-Datenbank selbst eine normale baseportal-Datenbank ist, können Sie den Zugriff darauf wieder mit einer eigenen Nutzer-Datenbank regeln. Dadurch können Sie verschiedene Zugriffslevel definieren:

Eigner >> Administratoren >> Nutzer >> Datenbank

Der Eigner des baseportal-Zugangs hat dabei immer alle Rechte (vielleicht vergleichbar mit dem Nutzer "root" bei UNIX-Systemen). Die Nutzer-Datenbank einer Nutzer-Datenbank bestimmt die "Administratoren": Sie können neue Nutzer einragen, deren Rechte festlegen und diese auch wieder löschen. Die "Nutzer" können mit diesen Rechten auf die Datenbank zugreifen. Ach ja, und die Nutzer-Datenbank einer Nutzer-Datenbank kann selbst natürlich wiederum auch eine Nutzer-Datenbank haben und... ;-) Eine allgemeine Rechtevergabe ist bei einer Nutzer-Datenbank nicht möglich, denn wenn jeder die Einträge inkl. Passwörter lesen oder gleich beliebige neue Einträge machen kann, hebeln Sie damit natürlich den eigentlichen Schutz komplett aus. Lediglich ein eingeschränkter Zugriff auf bestimmte Felder (z.B. Name) könnte für ALLE Sinn machen.

Anmeldung

Wird der Zugriff auf eine Datenbank über eine Nutzer-Datenbank geregelt, so gibt das <do action=all...> automatisch einen "Anmelden"-Button aus:

undef @_sel;

Die restliche Ausgabe hängt von den Rechten ab, die unangemeldete Nutzer (ALLE) haben, in dieser Beispielausgabe nur Leserechte und sonst keine. Kann man als unangemeldeter Nutzer garnicht auf die Datenbank zugreifen, so erscheint gleich das Anmeldeformular:

undef @_sel;

Wie üblich können Sie die Anmeldung durch einen Parameter beeinflussen:

Art der Anmeldung (Neuer Parameter: login)

Durch den neuen Parameter login beim "do action=all" kann die Art der Anmeldung für einen Nutzer gesteuert werden:

Wert Bedeutung
yes Ein entsprechender Anmeldungs-Link wird ausgegeben - auch wenn gar keine Nutzer-Datenbank existiert (Der Nutzen ist allerdings eher zweifelhaft).
no Keine (sichtbare) Anmeldung. Eine Anmeldung z.B. über eine eigene Anmeldeseite oder per URL-Angaben ist aber trotzdem möglich.
closed Keine Anmeldung möglich, egal wie. Dies kann z.B. für Testzwecke nützlich sein, um zeitweise jegliche Anmeldung auszuschliessen.
lostpw Bei falscher Anmeldung kann der Nutzer das Passwort auf Wunsch an die verzeichnete EMail-Adresse schicken lassen.
top Die Anmeldung wird ohne Link sofort über der restlichen Ausgabe platziert.
bottom Die Anmeldung wird ohne Link sofort unter der restlichen Ausgabe platziert.

Beachten Sie Dieser Parameter kann (aus Sicherheitsgründen natürlich) NICHT von aussen per "get/post" eingestellt werden, sondern ausschliesslich innerhalb eines Templates.

Beispiel:

<do action=all login=top,lostpw>

Die Anmeldung wird sofort über der Ausgabe platziert. Hat ein Nutzer sein Passwort vergessen und meldet sich falsch an, so kann er sich das Passwort an die in der Nutzer-Datenbank verzeichnete EMail-Adresse schicken lassen. Da dies häufiger geschieht, als man glauben mag, ist dies eine grosse Erleichterung für den/die Seiten-Betreiber. Sie können diese Anfrage zum Zusenden des Passworts auch direkt als Link auf Ihre Seite einbauen, dieser sähe dann ungefähr so aus:

<a href="http://...?htx=/name/seite&cmd=lostpw">Passwort vergessen?</a>

Nutzer beim Anmelden zulassen/ausschliessen (Neuer Parameter: login_users)

Durch den Parameter login_users können nur bestimmte Nutzer zur Anmeldung in einem Template erlaubt werden:

<do action=all login_users=KONTROLLEUR,fongi,gabi>

Hier werden nur die Nutzer KONTROLLEUR (in diesem Fall eine Rolle), fongi und gabi zur Anmeldung zugelassen. Durch ein Minuszeichens - zu Beginn der Nutzerliste, werden die angegebenen Nutzer/Rollen ausgeschlossen. Alle anderen sind zugelassen:

<do action=all login_users=-ALLE,berger>

Schliesst unangemeldete Nutzer (ALLE) und den Nutzer berger vom Zugriff aus.

Know-How Bei Vererbung von Rechten werden alle Rollen unterhalb des zugelassenen Nutzers nur vererbt, wenn diese auch explizit zugelassen sind. Hier einige Beispiele anhand obiger Rollen-Datenbank: Durch ein login_users=berger erhält der Nutzer berger keinerlei Rechte, da die Rolle MITARBEITER nicht freigegeben ist. Umgekehrt gilt bei login_users=-MITARBEITER, dass berger ebenfalls keine Rechte hätte. Der Nutzer krumpawesch allerdings bekommt die Rechte von EINGEBER. Die Sperre von login_users=-KONTROLLEUR2 führt dazu, dass der Nutzer Schlumpf keine Rechte bekommt, auch nicht die von KONTROLLEUR, da dies ja eine Rolle vom (gesperrten) KONTROLLEUR2 ist. Sperrt man durch login_users=-KONTROLLEUR die Rolle KONTROLLEUR, haben gabi und fongi keine Rechte, während Schlumpf das Recht zum Ändern der Felder "Strasse" und "Ort" durch KONTROLLEUR2 erhält.

Eigene Anmeldungsformen (do action=login)

Sie sind nicht auf die Standard-Anmeldung von <do action=all> angewiesen. Sie können die Anmeldung an anderer Stelle der Seite platzieren oder selbst eine Anmeldeseite erstellen und diese URL den Bearbeitern ihrer Datenbank zur Verfügung stellen. Wenn Sie "do action=all" verwenden und dort den Parameter login=no hinzufügen, so erscheint die normale Seitenausgabe ohne "Anmelden"-Button. Um eine Anmeldung bei baseportal vorzunehmen müssen die Parameter "uid" für den Nutzer-Namen und "upw" für das Passwort übermittelt werden. Wenn Sie wollen, können Sie auch gleich eine URL mit diesen Parametern erstellen, z.B. so:

http://baseportal.de/cgi-bin/baseportal.pl?htx=/meinname/meineseite&uid=name&upw=passwort

Natürlich ist dies nicht für jeden Fall das Bequemste. Um ein Anmeldeformular in einem Template zu integrieren, können Sie die neue "action"-Angabe login_form verwenden:

<do action=login_form>

Gibt an dieser Stelle ein Anmeldeformular aus.

Um eine Anmeldung direkt von Ihrer Homepage aus zu ermöglichen benötigen Sie ein eigenes Anmelde-Formular:

Bitte melden Sie sich an:<p> <form action="http://baseportal.de/cgi-bin/bbeta.pl?htx=/meinname/ausgabeseite" method="post" enctype="multipart/form-data"> <input type=hidden name="htx=" value="/meinname/ausgabeseite"> <table> <tr><td>Name:</td><td><input type=text name="uid="></td></tr> <tr><td>Passwort:</td><td><input type=password name="upw="></td></tr> </table> </form>

Das wars auch schon. Bauen Sie diesen Code in Ihre eigene Seite ein und rufen Sie sie dann auf. Das rot markierte "/meinname/ausgabeseite" müssen Sie dabei natürlich auf Ihre eigenen Werte ändern.