Rheinwerk Computing < openbook > Rheinwerk Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger.

Inhaltsverzeichnis
Geleitwort
Vorwort
1 PEAR – Einführung
2 Authentication
3 Caching
4 Date and Time
5 File Formats
6 HTTP
7 Internationalization
8 Mail
9 Networking
10 PHP
11 Text
12 Web Services
13 Benchmarking
14 Configuration
15 Database
16 File System
17 HTML
18 Images
19 Logging
20 Math
21 Numbers
22 Tools and Utilities
23 XML
24 Selbst Pakete erstellen
25 PECL
Index
Ihre Meinung?

Spacer
 <<   zurück
PHP PEAR von Carsten Möhrke
Anwendung und Entwicklung – Erweiterungen für PHP schreiben
Buch: PHP PEAR

PHP PEAR
798 S., 39,90 Euro
Rheinwerk Computing
ISBN 3-89842-580-0
gp 5 File Formats
  gp 5.1 Contact_Vcard_Build
  gp 5.2 Contact_Vcard_Parse
  gp 5.3 MP3_ID
  gp 5.4 Archive_Tar
  gp 5.5 File_Passwd
    gp 5.5.1 Grundsätzliche Funktionsweise
    gp 5.5.2 .htpasswd-Dateien
    gp 5.5.3 Unix-User verwalten
    gp 5.5.4 Samba-Passwort-Dateien
    gp 5.5.5 CVS-Passwort-Dateien
  gp 5.6 File_HtAccess
  gp 5.7 Spreadsheet_Excel_Writer
    gp 5.7.1 Arbeitsblätter
    gp 5.7.2 Tabellenfelder
    gp 5.7.3 Drucken
  gp 5.8 File_PDF


Rheinwerk Computing

5.5 File_Passwd  downtop


Besprochene Version: 1.1.4 Lizenz: PHP-Lizenz
Klassendatei(en): File/Passwd/Authbasic.php; File/Passwd/Unix.php; File/Passwd/Smb.php; /File/Passwd/Cvs.php

File_Passwd ist in der Lage, verschiedenste Arten von Passwort-Dateien zu manipulieren. So können Sie beispielsweise User hinzufügen oder löschen. Das Paket ist eine Art »Schweizer Messer« im Umgang mit Passwort-Dateien. Allerdings muss man hierbei sicher die Einschränkung machen, dass es in einigen Fällen spezialisierte Pakete gibt, die leistungsfähiger als dieses universelle Paket sind.

File_Passwd unterstützt folgende Arten von Passwort-Dateien:

  • .httpasswd-Dateien für den Apache-Webserver
  • CVS-Passwort-Dateien
  • SMB-Passwort-Dateien
  • Unix-Passwort-Dateien

Die meisten Methoden des Pakets liefern im Fall eines Fehlers ein PEAR_Error-Objekt zurück.


Rheinwerk Computing

5.5.1 Grundsätzliche Funktionsweise  downtop

Das Paket besteht aus mehreren einzelnen Klassen. Für jeden der Datei-Typen ist eine eigene Klasse vorgesehen, wobei alle Klassen eine Grundmenge von Funktionen aus der Klasse File_Passwd_Common übernehmen. Bevor ich auf die einzelnen Datei-Typen eingehe, werde ich daher auf die grundsätzliche Funktionsweise und die Methoden eingehen, die in allen Klassen vorhanden sind.

Nachdem Sie mithilfe des zuständigen Konstruktors ein neues Objekt zur Verwaltung der Passwort-Datei abgeleitet haben, muss die Datei geladen werden, wofür die Methode load() vorgesehen ist. Sollte die Datei (noch) nicht existieren, kann das in einem Fehlverhalten des Pakets resultieren. Daher sollten Sie vor dem Laden der Datei auf jeden Fall prüfen, ob sie existiert, und sie gegebenenfalls anlegen. Das könnte beispielsweise so aussehen:

require_once ('File/Passwd/Authbasic.php'); 
$file_name = "geheim/.htpasswd"; 
 
$file = new File_Passwd_Authbasic($file_name); 
 
if (false===file_exists($file_name)) 
{ 
   touch($file_name); // Anlegen einer leeren Datei 
} 
$file->load();

Auch kann es nicht schaden zu prüfen, ob die Datei zum Lesen und Schreiben verfügbar ist, da das Paket erst merkt, ob die Datei geschrieben werden kann, wenn es versucht, die Datei zu speichern.

Nachdem die Datei geladen wurde, ist es sinnvoll, zuerst die Validität mithilfe der Methode parse() zu prüfen. Sie liefert ein PEAR_Error-Objekt, wenn sie feststellt, dass die Datei inkonsistent ist. Ein unschöner Nebeneffekt der Methode ist, dass Sie die Datei noch einmal mit load() laden müssen.

Um einen Überblick zu bekommen, welche User momentan in der betreffenden Datei vorhanden sind, können Sie auf die Member-Funktion listUser() zurückgreifen. Sie liefert ein assoziatives Array zurück, bei dem Usernamen als Schlüssel fungieren. Ist kein User in der Datei vorhanden, wird ein leeres Array zurückgegeben. Die verschlüsselten Passwörter sind in dem Array als Werte enthalten. Auch wenn die Passwörter verschlüsselt sind und nicht entschlüsselt werden können, sollten Sie diese nicht öffentlich zugänglich machen.

userExists() ist vorgesehen, um zu prüfen, ob ein bestimmter Username bereits vergeben ist, was immer dann sinnvoll ist, wenn Sie einen User neu anlegen wollen. Die Methode bekommt einen Usernamen übergeben, prüft, ob dieser vorhanden ist, und bestätigt das mit einem true oder verneint es mit dem Rückgabewert false.

Gleichermaßen ist für alle Typen von Passwort-Dateien die Methode delUser() zum Löschen eines übergebenen Usernamens vorhanden. Sollte der Username nicht gefunden werden, wird ein PEAR_Error-Objekt zurückgegeben.

Haben Sie alle Änderungen an einer Datei vorgenommen, muss sie mit save() gespeichert werden. Andernfalls gehen alle Änderungen verloren. In Listing 5.3 finden Sie ein kleines Beispiel, das die meisten Methoden noch einmal in Kombination verwendet und dazu dient, einen bestehenden User aus einer .htpasswd-Datei zu entfernen.

require_once"File/Passwd/Authbasic.php"; 
 
$file_name = ".htpasswd"; 
 
// User, der geloescht werden soll 
$del_user=$_POST["user"]; 
 
$fp = new File_Passwd_Authbasic($file_name); 
 
// Gibt es die Datei? 
if (false==file_exists($file_name)) 
{  // Nein, also muessen wir sie anlegen 
   touch($file_name); 
} 
// Datei laden 
$res=$fp->load(); 
if (PEAR::isError($res)) 
{ 
   die ("Datei konnte nicht ge&ouml;ffnet 
         werden<br />".$res->getMessage()); 
} 
// Datei analysieren, ob sie gueltig ist 
$res=$fp->parse(); 
if (PEAR::isError($erg)) 
{ 
   die ($res->getMesasage()); 
} 
 
// Datei wegen des Parsens erneut laden 
$fp->load(); 
 
// Gibt es den User? 
if (false===$fp->userExists($del_user)) 
{  // User existiert nicht - Meldung ausgeben 
   echo ("Der User existiert nicht<br />"); 
} 
else 
{  // User existiert, also muss er geloescht werden 
   $res=$fp->delUser($del_user); 
   if (PEAR::isError($res)) 
   { 
      die ("Fehler beim L&ouml;schen des 
            Users".$res->getMessage()); 
   } 
   echo ("Der User wurde geloescht"); 
} 
// Aenderungen speichern 
$res=$fp->save(); 
// Ist ein Fehler beim Speichern aufgetreten? 
if (PEAR::isError($res)) 
{ 
   die ("Datei konnte nicht gespeichert 
         werden<br />".$res->getMessage()); 
}

Listing 5.3 Löschen eines bestehenden Users

In den nachfolgenden Abschnitten finden Sie die Erläuterungen zu den Methoden und Funktionen, die speziell für bestimmte Datei-Typen ausgelegt sind. Anzumerken ist noch, dass die Benutzernamen für alle Klassen auf identische Art und Weise geprüft werden. Hierbei gilt, dass Benutzernamen nur aus den Buchstaben von A-Z (in Groß- und Kleinschrift), dem Binde- und Unterstrich sowie den Ziffern von 0–9 bestehen dürfen, wobei das erste Zeichen ein Buchstabe sein muss. Des Weiteren muss ein Benutzername immer eindeutig sein und darf somit nicht doppelt vorkommen.


Rheinwerk Computing

5.5.2 .htpasswd-Dateien  downtop

Der Apache-Webserver unterstützt die Möglichkeit, einzelne Unterverzeichnisse mithilfe von Passwörtern zu schützen. Dies wird häufig mit Dateien gemacht, die die Namen .htaccess und .htpasswd tragen. .htaccess-Dateien definieren, wie der Zugriffsschutz aussieht, welche User Zugriff haben und Ähnliches. Die Passwörter und Benutzernamen hingegen sind in der .htpasswd-Datei enthalten. Da die Namen der Dateien frei konfigurierbar sind, können sie im Einzelfall auch mal anders heißen.

Standardmäßig werden zwei Authentifizierungsmechanismen unterstützt: die Basic- und die Digest-Authentifikation, wobei die Digest-Authentifikation eher unüblich ist. Daher werde ich mich hier auf die Basic-Authentifikation beschränken.

Um einen User hinzuzufügen, steht die Methode addUser() zur Verfügung. Sie bekommt den Namen des neuen Users sowie das Passwort als Strings übergeben. Da bis zu drei verschiedene Möglichkeiten zur Verfügung stehen, wie ein Passwort verschlüsselt sein kann, analysiert das Paket erst die vorhandenen Passwörter und ermittelt den genutzten Algorithmus. Ist noch kein Benutzername vorhanden, greift die Methode per Default auf eine SHA-Verschlüsselung zurück. Möchten Sie eine andere Verschlüsselung nutzen, stellt sich zuerst die Frage, welche Algorithmen auf Ihrem System zur Verfügung stehen. Dies lässt sich mithilfe von listModes() ermitteln. Der Rückgabewert ist hierbei ein indiziertes Array mit maximal drei Elementen. Die Werte stellen die Namen der Verschlüsselungsmethoden dar. Neben md und sha ist auf UNIX-Derivanten meist auch eine des-Verschlüsselung verfügbar, wobei diese unter Windows nicht nutzbar ist. Einer dieser Strings kann nun an die Methode setMode() übergeben werden, die den Verschlüsselungsmodus festlegt. Bitte setzen Sie den Modus nur dann von Hand, wenn eine Passwort-Datei noch leer ist. Andernfalls kann das in einer ungültigen Datei resultieren.

Möchten Sie bei einem bestehenden Benutzer das Passwort ändern, können Sie changePasswd() nutzen. Die Methode, die im Fehlerfall ein PEAR_Error-Objekt zurückgibt, bekommt den Namen eines bereits existierenden Benutzers sowie das neue Passwort übergeben. In diesem Zusammenhang kann die Methode verifyPasswd() sehr hilfreich sein. Sie ermittelt, wenn ihr ein Benutzername und ein Passwort übergeben wurden, ob das Passwort mit den Inhalten in der Passwort-Datei übereinstimmt, und bestätigt das gegebenenfalls mit einem true. In eine ähnliche Richtung geht die Member-Funktion staticAuth(). Sie kann statisch aufgerufen werden und ermöglicht es, einen User gegen eine Datei zu authentifizieren, ohne sie vorher laden zu müssen.

require_once "File/Passwd/Authbasic.php"; 
 
//Parameter: Dateiname,User,Passwort,Verschluesselungsmethode 
$res=File_Passwd_Authbasic::staticAuth(".htpasswd","user", 
                                         "passwort","des"); 
if (PEAR::isError($res)) 
{ 
   die ("Ein Fehler ist aufgetreten: ".$res->getMessage()); 
} 
// Userdaten OK? 
if (true===$res) 
{ 
   echo ("Kombination aus Usernamen und 
          Passwort ist g&uuml;ltig"); 
} 
else 
{ 
   echo ("Kombination aus Usernamen und Passwort ist 
          ung&uuml;ltig 
}

Die beiden Methoden können Sie gut nutzen, um einen Benutzer zu authentifizieren und ihm dann eine Möglichkeit zu geben, selbstständig sein Passwort zu ändern.


Rheinwerk Computing

5.5.3 Unix-User verwalten  downtop

Wie ich schon erwähnt habe, kann das Paket auch System-User auf Unix-Derivaten verwalten. Bevor ich zu den eigentlichen Funktionalitäten komme, noch ein Wort zur Sicherheit. Die Benutzerverwaltung bei Linux und den meisten Unix-Systemen basiert auf zwei Dateien. Das ist zum einen die Datei /etc/passwd und zum anderen die Datei /etc/shadow. Die erste enthält die Benutzernamen und weitere Informationen wie User-ID, Heimat-Verzeichnis und Ähnliches. Die zweite ist dient zur Speicherung der verschlüsselten Passwörter. Normalerweise hat nur der Benutzer root die Rechte, um die Inhalte dieser Dateien zu verändern. Wenn Sie ein Script über den Webserver ausführen, so besteht das Problem, dass es unter dem Benutzer des Webservers ausgeführt wird und nicht unter root. Somit können Sie normalerweise nicht direkt auf die System-Dateien zugreifen. Eine Möglichkeit ist, dass ein entsprechendes Script nicht über den Webserver, sondern über die Kommandozeile ausgeführt wird. Das heißt, dass Sie sich lokal beim System anmelden und das Script dann nicht über den Webserver, sondern über das CLI (Command Line Interface) starten. [Informationen, wie Sie PHP für die Kommandozeile nutzen, finden Sie hier: http: //de2.php.net/features.commandline ]  Die zweite Möglichkeit besteht darin, den Webserver mit suPHP [suPHP können Sie über http://www.suphp.org beziehen. ] auszustatten. Hierbei handelt es sich um ein Paket, das Ihnen die Möglichkeit gibt, Scripts über den Webserver mit root-Rechten auszuführen.

Die Rechte der System-Dateien zu verändern oder den Webserver unter dem User root auszuführen wäre wirklich keine gute Idee, und ich möchte dringend davon abraten, das zu tun.

Ein weiteres Problem ist, dass das Paket seinen vollen Leistungsumfang nur auf Systemen entfalten kann, bei denen die Passwörter nicht in die Datei /etc/shadow ausgelagert wurden. Da das aber in den meisten Fällen Standard ist, beschränken sich die effektiven Möglichkeiten der Klasse darauf, Benutzerdaten auszulesen. Möchten Sie User anlegen oder Passwörter ändern, können Sie nur auf die System-Befehle wie useradd, passwd etc. zurückgreifen und sie z. B. mit system() ausführen.

Die Klasse ist in der Datei File/Passwd/Unix.php definiert, und der Konstruktor verlangt nach dem Pfad zur Passwort-Datei (üblicherweise /etc/passwd). Um zu überprüfen, ob das System mit einer Shadow-Datei arbeitet, können Sie nach dem Laden der Passwort-Datei die Methode isShadowed() aufrufen, die das im Normalfall mit einem true bestätigen wird.

Einen Überblick, welche Benutzer einen Account auf dem System haben, können Sie sich auch hier mit der Methode listUser() verschaffen. Sie liefert allerdings ein etwas komplexeres Ergebnis zurück. Die Benutzernamen fungieren als Schlüssel der Elemente. Jedes Element hat als Wert allerdings ein Array, dessen Aufbau Sie in Tabelle 5.4 finden.


Tabelle 5.4 Aufbau des Arrays mit User-Daten
Schlüssel Erläuterung
pass Verschlüsseltes Passwort; arbeitet das System mit einer Shadow-Datei, ist hier ein x enthalten.
uid User-ID
gid Gruppen-ID
gecos Kommentar
home Heimat-Verzeichnis des Benutzers (z. B. /home/neuerUser)
shell Shell des Users (z. B. /bin/bash)

Wenn Sie die Methode listUser() nutzen, ist es also recht einfach, die User des Systems ausgeben zu lassen. Listing 5.4 zeigt ein kleines Beispiel.

require_once"File/Passwd/Unix.php"; 
 
$fp = new File_Passwd_Unix("/etc/passwd"); 
 
$res=$fp->load(); 
if (PEAR::isError($res)) 
{ 
   die ("Datei konnte nicht ge&ouml;ffnet 
         werden<br />".$res->getMessage()); 
} 
 
$arr_users=$fp->listUser(); 
 
foreach ($arr_users as $user => $data) 
{ 
   echo ("<p>User: $user<br />Details: "); 
   echo implode (":",$data)."</p>"; 
}

Listing 5.4 Auslesen aller User aus /etc/passwd

Das Script aus Listing 5.4 gibt für jeden Benutzer zwei Zeilen aus, die jeweils so aussehen:

User: moehrke 
Details: x : 655 : 100 : moehrke : /home/moehrke : /bin/bash

Falls Ihre Applikation über Schreibrechte für die passwd-Datei verfügt, können Sie die Eigenschaften eines Users verändern. Die Methode modUser(), die das für Sie übernimmt, erwartet einen Benutzernamen und ein Array mit dem Aufbau, der in Tabelle 5.4 beschrieben ist. Wichtig hierbei ist, dass das Feld pass nur dann einen anderen Wert als ein x enthalten darf, wenn das System nicht mit einer Shadow-Datei arbeitet. Benutzt das System eine Shadow-Datei, muss hier ein x enthalten sein.

Damit sind die sinnvollen Methoden von File_Auth_Unix auch leider schon erschöpft. Wie gesagt, wenn Sie mit einem System arbeiten sollten, das die Passwörter nicht in einer Shadow-Datei ablegt, kann das Paket auch mehr leisten. Hierzu möchte ich Sie auf die Online-Dokumentation [Diese finden Sie in der jeweils aktuellen Version unter http://pear.php.net/package/File_Passwd/docs/. ] verweisen.

Mit ein wenig Aufwand können Sie auf Basis dieses Pakets allerdings auch Klassen erstellen, die ohne Probleme mit »geshadowten« Systemen zurechtkommen. Dazu müssen Sie dann allerdings entweder eine neue Klasse auf Basis dieses Pakets erstellen oder die Sicherheitsabfragen entfernen, die eine Arbeit mit solchen Systemen verhindern.


Rheinwerk Computing

5.5.4 Samba-Passwort-Dateien  downtop

Der Samba-Server stellt eine der beliebtesten Möglichkeiten dar, um Laufwerksfreigaben auf Unix- bzw. Linux-Systemen zu realisieren, und ist auch für Windows-Systeme verfügbar. Die Benutzerverwaltung erfolgt über die Datei smbpasswd, deren Pfad an den Konstruktor übergeben werden muss. Auch hier gilt, dass Ihre Applikation natürlich Schreibrechte auf diese Datei benötigt.

Der Konstruktor braucht den Pfad zur Passwortdatei und ist in der Datei File/Passwd/Smb.php definiert. Die Methode addUser(), die einen neuen Benutzer anlegt, verlangt in dieser Klasse mindestens drei Parameter. Neben dem Usernamen und dem Passwort ist noch ein Array erforderlich. Hierbei handelt es sich um ein assoziatives Array mit den Schlüsseln userid und comment. Das erste Element enthält hierbei die uid des dazugehörigen System-Accounts. Mithilfe des zweiten, optionalen Elements können Sie noch einen zusätzlichen Kommentar angeben. Nach dem Array ist es des Weiteren möglich, einen booleschen Wert zu platzieren. Hiermit können Sie steuern, ob es sich um einen »Maschinen-Account« oder einen »User-Account« handelt. Ersterer ist immer dann erforderlich, wenn der Samba-Server als PDC (Primary Domain Controller) in einem Windows-Netz fungieren soll. Geben Sie keinen Wert oder false an, wird ein User-Account angelegt und bei Übergabe des Wertes true ein Maschinen-Account.

Um einen bestehenden Account zu verändern, stehen zwei Member-Funktionen zur Verfügung. Zum einen ist das changePasswd(). Sie dient zum Ändern eines Passworts und bekommt einen existierenden Benutzernamen und das neue Passwort übergeben. Die Methode modUser() gibt Ihnen die Möglichkeit, weitere Eigenschaften des Users zu verändern. Sie bekommt den Namen eines bestehenden Users und ein Array mit den zu modifizierenden Werten übergeben. Das Array muss assoziativ sein und unterstützt die Schlüssel, die Sie in Tabelle 5.5 finden.

[http://us3.samba.org/samba/docs/man/smbpasswd.5.html ]
Tabelle 5.5 Aufbau das Arrays für modUser(  )
Schlüssel Erläuterung
flags String mit Flags, die definieren, ob es sich um einen Maschinen- oder User-Account handelt. Der String muss 13 Zeichen lang sein und von eckigen Klammern eingeschlossen sein. Welche Flags hier möglich sind, entnehmen Sie bitte der Samba-Dokumentation.
userid User-ID eines bestehenden System-Accounts
comment Kommentar zu dem Account
nthash NT-Passwort-Hash (Passwort in MD4-Verschlüsselung)
lmhash LANMAN-Passwort-Hash (Passwort in DES-Verschlüsselung)

Der Vorteil der Methode modUser() besteht darin, dass Sie ihnen systemnähere Möglichkeiten zur Beeinflussung der Accounts gibt. Beim Anlegen eines neuen Users können Sie beispielsweise nur mithilfe des vierten Parameters die Flags beeinflussen. Die Flags, die Sie hier angeben können, werden aber direkt in die Passwort-Datei übernommen. Möchten Sie das Passwort des Benutzers mit dieser Methode ändern, ist es wichtig, dass die Array-Felder die verschlüsselten Passwörter enthalten. Um ein Passwort korrekt zu verschlüsseln, steht die Methode generatePasswd() zur Verfügung. Sie kann statisch aufgerufen werden und bekommt das zu kodierende Passwort übergeben, das sie standardmäßig in der NT-Verschlüsselung zurückgibt. Allerdings können Sie als zweiten Parameter den String lanman übergeben und erhalten dann die zweite Verschlüsselungsvariante.

Sollte der Benutzer nicht existieren, liefern die beiden Methoden modUser() und changePasswd() ein PEAR_Error-Objekt zurück.

Zum Aufbau eines Authentifizierungssystems, mit dem der Benutzer beispielsweise selbst sein Passwort ändern kann, können Sie die Methoden staticAuth() oder verifyPasswd() nutzen. Erstere können Sie statisch aufrufen. Sie bekommt neben dem Pfad zur Datei noch einen Benutzernamen und ein Passwort übergeben. Ob der User authentifiziert werden konnte, meldet die Methode mithilfe von booleschen Werten zurück. Falls ein Fehler auftritt, ist der Rückgabewert ein PEAR_Error-Objekt.

require_once "File/Passwd/Smb.php"; 
$res=File_Passwd_Smb::staticAuth("/etc/samba/smbpasswd", 
                                 "user","geheim"); 
if (true===$res) 
{ 
   echo ("Sie sind eingeloggt"); 
} 
else 
{ 
   if (PEAR::isError($erg)) 
   { 
      echo "Ein Fehler ist aufgetreten!<br />"; 
      echo $res->getMessage(); 
   } 
   else 
   { 
      echo "Sie konnten nicht authentifiziert werden!"; 
   } 
}

Listing 5.5 Statische Authentifizierung mit einer Samba-Passwortdatei


Rheinwerk Computing

5.5.5 CVS-Passwort-Dateien  toptop

Die letzte Variante von Passwortdateien, die das Paket unterstützt, sind CVS-Passwort-Dateien. Die Datei /File/Passwd/Cvs.php enthält die notwendigen Definitionen. Zum Ableiten eines neuen Objekts benötigt der Konstruktor File_Passwd_Cvs() den Pfad und den Namen der Passwort-Datei. Die Methode addUser() verhält sich ähnlich wie in der Samba-Variante. Sie bekommt den Namen des Users, der angelegt werden soll, und das dazugehörige Passwort übergeben. Des Weiteren können Sie als dritten Parameter den Usernamen eines System-Users übergeben, falls der CVS-Account mit einem System-Account verknüpft werden soll.

Um einen bestehenden CVS-Account zu verändern, können Sie die Methoden changeSysUser() und changePasswd() nutzen. Die erste kann einen CVS-Account einem anderen System-User zuordnen, und die zweite ist gedacht, um ein CVS-Passwort zu verändern. Beide bekommen als ersten Parameter einen Usernamen übergeben und als zweiten den neuen System-User bzw. das neue Passwort. Beide Methoden liefern im Fall eines Fehlers, beispielsweise wenn der User nicht gefunden wird, ein PEAR_Error-Objekt zurück.

Zum Aufbau eines Authentifizierungssystems steht auch hier eine Methode staticAuth() zur Verfügung, die statisch aufgerufen werden kann und den Pfad zur Passwort-Datei sowie einen Usernamen und ein Passwort übergeben bekommt. Eine korrekte Authentifizierung bestätigt sie mit true. Können die übergebenen Daten nicht verifiziert werden, gibt sie ein false und im Fehlerfall ein PEAR_Error-Objekt zurück.

Die Methode listUser() liefert Ihnen ein Array mit allen Usern zurück. Der Name des CVS-Users fungiert hierbei als Schlüssel. Der Inhalt des Feldes ist dann jeweils ein neues Array, das aus zwei Werten besteht und die Schlüssel passwd und system hat. Das erste Feld enthält das verschlüsselte Passwort, und das zweite kann den Namen des dazugehörigen System-Users enthalten.

 <<   zurück
     
  Zum Rheinwerk-Shop
Zum Rheinwerk-Shop: PHP PEAR
PHP PEAR
Jetzt Buch bestellen!
 Ihre Meinung?
Wie hat Ihnen das Openbook gefallen?
Ihre Meinung

 Buchtipps
Zum Rheinwerk-Shop: PHP 5.6 und MySQL 5.7






 PHP 5.6 und
 MySQL 5.7


Zum Rheinwerk-Shop: Einstieg in PHP 5.6 und MySQL 5.6






 Einstieg in PHP 5.6
 und MySQL 5.6


Zum Rheinwerk-Shop: Responsive Webdesign






 Responsive Webdesign


Zum Rheinwerk-Shop: Moderne Websites entwickeln






 Moderne Websites
 entwickeln


Zum Rheinwerk-Shop: MySQL 5.6






 MySQL 5.6


 Lieferung
Versandkostenfrei bestellen in Deutschland, Österreich und der Schweiz
InfoInfo








Copyright © Rheinwerk Verlag GmbH 2007
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das Openbook denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt.
Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.


Nutzungsbestimmungen | Datenschutz | Impressum

Rheinwerk Verlag GmbH, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, service@rheinwerk-verlag.de

Cookie-Einstellungen ändern