Sie befinden sich hier: TYPO3 / Anleitungen / Frontend-User-Login gegen eigene Datenquelle
Donnerstag, 14.12.2017

FE-User gegen andere Datenquelle authentifizieren

TYPO3 bringt von Haus aus eine flexible und leistungsfähige Möglichkeit der Benutzerauthentifikation gegen die lokale Datenbank mit. Auch Gruppenrechte sind damit problemlos möglich.

Manchmal ist es aber notwendig oder gewünscht, dass die Websitebesucher sich nicht gegen die lokale Datenbank anmelden, sondern ein anderer Dienst genutzt werden soll. Das kann eine andere Datenbank, ein Login-Service oder ein Webservice sein (oder natürlich auch etwas ganz anderes). Wie bringt man nun aber TYPO3 bei, dass diese Loginquelle benutzt wird?

Auth Services

Zunächst einmal müssen wir verstehen, wie TYPO3 bei einem Login eines Frontend-Users vorgeht. In der Datenbanktabelle fe_users sind die relevanten Informationen gespeichert; diese werden beim Login in einen User-Datensatz geladen, der dann wiederum über die bekannten Mechanismen von allen Plugins und Extensions genutzt werden kann. 

Wir müssen also sicherstellen, dass die Informationen unseres Logins ebenfalls zu einem solchen User-Datensatz führen und die notwendigen Informationen zur Verfügung stellen.

Das bedeutet insbesondere, dass in dieser Datenbanktabelle für jeden Benutzer auch ein Datensatz stehen muss, auch wenn wir gegen eine andere Datenbank oder gegen einen Webservice authentifizieren.

Um einen neuen Auth-Service zu erstellen, müssen wir eine Extension programmieren - die ist zum Glück denkbar einfach, wenn man mit dem Kickstarter umgehen kann.

Im Reiter Services fügen wir einen solchen hinzu - und wählen als Service Type: auth und als Subtypes: getUserFE,authUserFE,getGroupsFE. Die Felder Priority und Quality legen fest, in welcher Reihenfolge unser Auth Service angesprochen werden soll - ein Wert jeweils über 50 wäre also anzuraten, wenn wir unseren Auth-Service vorrangig behandeln wollen.

Keine Personalisierten Inhalte

In manchen Szenarien genügt es, einer Benutzergruppe Zugang zu erlauben oder eben zu verweigern. Das ist immer dann der Fall, wenn im Zugangsbeschränkten Bereich keine personalisierten Texte ausgegeben werden sollen und wenn keine speziellen Rechte vergeben werden. In diesem einfachen Szenario geht es also nur um die Frage, ob ein Benutzer die Inhalte sehen darf oder nicht. 

Hier genügt es, einen einzigen Datensatz in der FE-Usertabelle zu haben und abhängig von der Datenquelle auf diesen Benutzer zu mappen (der Besucher darf "eintreten") oder eben nicht. 

Ein einfacher Auth-Service

Der Kickstarter hat uns nun dankenswerterweise bereits ein Gerüst für unsere Extension erstellt und unter anderem im Verzeichnis typoconf/ext/_unser_key/sv1 eine class._unser_key.sv1.php erstellt. Diese müssen wir nun nur noch ausprogrammieren:

Als erstes benötigen wir folgende Zeile ganz oben in der Datei. Damit werden die Service-Klassen eingelesen, die wir gleich für die Vererbung benötigen.

require_once(PATH_t3lib.'class.t3lib_svbase.php');

Die Zeile

class tx_unser_key_sv1 {

erweitern wir zu

class tx_unser_key_sv1 extends tx_sv_authbase {

und vererben damit die Eigenschaften der Service-Klassen.

AuthServices müssen einige Methoden zu Verfügung stellen. Dies sind insbesondere:

function init() {
  $available = parent::init();
  return $available;
}

Diese Methode initialisiert den Webservice. Im Wesentlichen muss hier nichts weltbewegendes passieren. Ob etwas initialisiert werden muss, kommt natürlich auch auf die Datenquelle an, die man ansprechen möchte. In meinem einfachen Beispiel rufe ich einfach die init-Methode der vererbendenen Klasse auf.

function authUser($user) {
   // Datenquelle abfragen
   // gib false zurück, wenn Auth NICHT geklappt hat
   if ( ... ) return false;

   // auf bestehenden User mappen:
   $loginData['username'] = 'user';
   $loginData['uident'] = 'passwd';

   $loginData = $this->pObj->processLoginData($loginData, 'normal');

   $OK = $this->compareUident($user, $loginData);
   return $OK;

}

Diese Methode implementiert den Authentication Service. Ich habe hier einen SOAP-Service als Datenquelle abgefragt und abhängig von diesem true oder false zurückgegeben. Genauso kann man aber auch externe Datenbanken oder was auch immer abfragen.

Wichtig: Wie oben erwähnt ist es wichtig, dass in der fe_user-Tabelle ein passender Datensatz vorhanden ist. Sollen personalisierte FE-User-Datensätze verwendet werden, genügt es NICHT, auf einen bestehenden User zu mappen - in diesem Fall muss der Datensatz (aus der externen Datenquelle) zuerst in die fe_user-Tabelle geschrieben werden. Anschließend gibt man mit dem Rückgabewert true den Zugang frei. :-)

function getUser()

Diese Funktion wird von TYPO3 aufgerufen, wenn Details zu dem eingeloggten Benutzer abgefragt werden. Auch hier kann natürlich die externe Datenquelle gefragt, in der fe_user-Tabelle nachgeschlagen werden (wenn der Datensatz dort eingetragen wurde) oder ein Standarddatensatz zurückgegeben werden.

Damit ist das Grundgerüst für einen eigenen Auth-Service auch schon fertig. Viel Spaß beim implementieren der eigenen Datenquelle :-)

elp schrieb am 30.10.09 10:43:
super posting, danke! stehe grade vor einem ähnlichen problem - eine frage stellt sich mir: was der benutzer sehen darf und was nicht, wird ja über FE groups definiert - diese sind bei mir auch im webservice hinterlegt - wie kann ich jetzt in der getUser() - methode checken, welche gruppenrechte erforderlich sind bzw. wie kann ich dem webservice - benutzer FEgroups zuweisen?

danke
Marc Willmann schrieb am 30.10.09 22:28:
Hallo Elp,

Ich hoffe, ich verstehe Dich richtig - die Frage ist ja nicht, wie die getUser()-Methode mitbekommt, welche Rechte angefordert werden, sondern sie gibt in ihrem Rückgabewert die Rechte des angemeldeten Users zurück. Zu entscheiden, ob diese ausreichen oder nicht, ist dann die Aufgabe der aufrufenden Methode.

Wie genau der Rückgabewert ausschaut, kann ich auswendig auch nicht sagen - die Core-Ref sollte da aber Auskunft geben.

Viele Grüße aus Lübeck

Marc
elp schrieb am 09.11.09 16:02:
naja, nicht ganz - mein benutzer erhält auch alle gruppen-zuordnung per SOAP - ich habs jetzt über eine gruppen-synchronisierung (per cronjob) gelöst, d.h. der user wird bei jedem login neu in die fe_users tabelle geschrieben, die gruppen existieren bereits in typo3 - so kann ich inhalte auf die entsprechenden gruppen mappen...

danke auf jeden fall...

Kommentar hinzufügen

* - Pflichtfeld

*




CAPTCHA-Bild zum Spam-Schutz
Wenn Sie das Wort nicht lesen können, bitte hier klicken.
*
*