Beispiel für Login

[pl]

Hab ich Dir ja auch geschrieben: Da kannst Du Dir den Umweg über Globale Variablen auch sparen. MfG

Ich glaube, du hast es immer noch nicht verstanden. Man verwendet Umgebungsvariablen, damit man die Konfiguration einer einzelnen Installation nicht im Repository hat.

Umgebungsvariablen verwenden heißt, sich in Sachen Konfiguration vom Server abhängig zu machen. Zweckmäßiger ist es jedoch, gerade im shared hosting Segment, es genau umgekehrt zu tun, also auch das, was normalerweise in der Serverkonfiguration angesiedelt ist, zu einer Angelegenheit der eignen Konfiguration zu machen.

Konkretes Beispiel (und passend zu diesem Thread): Nicht der Webserver greift auf die Datei mit den Passwords, sondern die eigene Anwendung definiert eine eigene Schnittstelle zu dieser Datei. So kann man das mit dem Apache mitgelieferte Utility htpasswd nutzen zum Erstellen, Bearbeiten der Passwortdatei und diese Datei dann sowohl für Authorization Basic als auch für eigene Loginprozesse verwenden. Unabhängig davon kann man Passworte natürlich auch in einer DB hinterlegen.

Abstrakt: Der Webserver wird nur soweit konfiguriert um sämtliche weitere Konfigurationsparameter in einer eigenen Konfiguration ansiedeln zu können. Wenn ich z.b. in meinem FW eine AuhBasic brauche, kann ich die mit $self->auth() an jeder xBeliebigen Stelle in die Anwendung einbauen ohne daß ich hierzu eine .htaccess anpassen muss.

Was natürlich nicht heißt daß man auf Umgebungsvariablen völlig verzichten kann.

Und was draußen gerade Mode und gängige Praxis ist, lieber Christian, das heiß noch lange nicht daß es ebenso zweckmäßig ist, ganz im Gegenteil. Solange ich noch berufstätig war, habe ich Praktiken erlebt die man lieber nicht machen sollte. MfG

PS: Mein Beispiel analog zu Deinem betreff eines auf /index.html liegenden Webservice:

[/index.html]
auth=manager.realm
interface=webservice

deklariert die Paswortdatei namentlich und beim Request käme entweder Authorization Baisc ins Spiel über $self->auth() oder die Anwendung (interface=webservice) nutzt mit $self->checkpass() lediglich die Schnittstelle zur Datei deren Name in der Konfiguration deklariert ist.

Ansonsten laufen meine Webservices wie RPCs über dasselbe Framework wie jeder andere Request auch. D.h., daß da nichts zusätzliches installiert oder an der Serverkonfiguration angepasst werden muss. Für jede Domäne/Realm gibt es bei mir eine Konfigurationsdatei deren Einzelwerte der [default] Sektion gemäß OOP Maxime für jeden URL überschrieben werden können. Wenn da z.B. für MySQL der Name dbh=myweb notiert ist, kann für den speziellen URL /webalizer der Name mit dbh=logger anders festgelegt werden. Ein Aufruf von $self->dbh() stellt dann automatisch die Verbindung zur richtigen DB her und findet die Credentials in $self->{FILEDIR}/dbh.ini ganz von selbst.

Die Datei dbh.ini definiert den Schlüsselworten entsprechende Sektionen, [myweb], [shop] usw.