Apr

14

WordPress: Shared Users (+Cookies = SSI)

Es soll ja Fälle geben, in denen man Benutzerdaten nicht mehrfach vorhalten will und sich mit ein und demselben Passwort an mehreren Stellen einloggen mag. Genau so einen Fall hatte ich die Tage zu bearbeiten. Glücklicherweise hatte ich schon vor längerer Zeit einmal „Shared Users“ entdeckt und mich daran erinnert. Damit läßt sich von mehreren WordPress-Installationen (bei gleicher DB) gemeinsam auf die Userdaten einer Installation zugreifen. Klingt einfach, isses aber leider nicht. Zumindest bei mir ging es nicht einfach mit aktivieren und unter Einstellungen die passende „DB“ auswählen. Ich wurde stets ausgeloggt, bevor die Änderung umgesetzt wurde. Sofern man die Präfixe seiner Tabellen kennt, kann man allerdings (unter Komfortverlust) auch direkt in den Einstellungen unter „shared_users_prefix“ das entsprechende Präfix Eintragen. Und schwupps werden die Daten aus Präfix_users bei allen WP-Installationen verwendet. Die Daten in Präfix_usermeta verwaltet jedes WP weiterhin separat (ergo auch die Benutzerrechte). Achja, das Plugin sollte man nur mit einem leeren WP verwenden, oder aber vorher Vorsorge treffen, dass die User in allen WP’s die gleiche ID haben (bei mir gings, ich musste nur 6 User „synchronisieren“, wichtig sind alle Tabellen in denen die UserID vorkommt (_users, _usermeta, _posts, _comments)). So, nun war es soweit, man konnte sich in allen WP’s mit den gleichen Daten anmelden…

Aber irgendwie fehlte noch was… Wie wärs damit, in einem WP Einloggen und bei allen eingeloggt sein (SSI)? Geht, und ist im Grunde auch gar nicht so schwer. Sofern sich die WP’s nicht nur eine Datenbank teilen, sondern auch unter der gleichen Domain laufen, lässt sich dies recht einfach bewerkstelligen. Als erstes muss das „secret“ der WP-Installationen angeglichen werden (unter „Alle Einstellungen“). Als nächtes gilt es die wp-config.php zu erweitern, bei mir haben folgende Einstellungen funktioniert:

// Need some more things
define(‚SECRET_KEY‘, ‚Zufällige Zeichenkombination (inkl. Sonderzeichen)‘);
$cookiehash = md5(‚z.B. domain.de‘);
define(‚COOKIEHASH2‘, $cookiehash);

define(‚USER_COOKIE‘, ‚wordpressuser_‘ . COOKIEHASH2);
define(‚PASS_COOKIE‘, ‚wordpresspass_‘ . COOKIEHASH2);
define(‚AUTH_COOKIE‘, ‚wordpress_‘ . COOKIEHASH2);
define(‚COOKIEPATH‘, ‚/‘ );
define(‚SITECOOKIEPATH‘, ‚/‘ );
define(‚COOKIE_DOMAIN‘, ‚domain.de‘);

Das wars auch schon, zumindest bei mir scheint damit momentan alles ohne Probleme zu funktionieren.

6 Kommentare bis jetzt

  1. Kommentar von scytale:

    Gibt es für diesen Zweck nicht schon OpenID als „ausgereifte“ Lösung? Kurzes googlen ergab, dass es wohl auch schon ein WordPress-Plugin gibt. Da ich mich mit WordPress aber nicht auskenne, weiß ich natürlich nicht ob es auch was taugt… mit drupal funktionierts jedenfalls super!

  2. Kommentar von proog:

    OpenID wär vll ne Idee für das Blog hier (aber wozu soll man sich hier überhaupt anmelden?)… Aber nicht @ux (und genau dort, setze ich es ein)… würde dort mit meiner Idee zur Weiterentwicklung kollidieren ;) (ich will, sobald ich die Zeit finde für die Authentifizierung im Hintergrund LDAP einsetzen und darauf aufbauend noch weitere „Features“ anbinden)…

    btw. wen oder was benutzst du als OpenID-Provider?

  3. Kommentar von scytale:

    Ich verwende es bei mir nicht. Aber viele Entwickler um drupal rum verwenden es. Da ich bei drupal.org sowieso schon angemeldet bin, kann ich mir dann die Registrierung auf den Projektseiten sparen. Das ist ganz cool…

    OpenID gibts auch mit LDAP Support!

  4. Kommentar von proog:

    Wie schauts da eigentlich in Sachen „Spam“ aus. Imho kann ja jeder selbst OpenID-Provider spielen, und wenn man das „System“ unterstützen will, müsste man ja erstmal alle Provider zulassen… und damit würde man auch Bots die Möglichkeit geben sich erfolgreich anzumelden?

    Es lohnt sich bestimmt OpenID zu beobachten, aber für den flächendeckenden Einsatz taugt es (mir) zumindest noch nicht ;)

  5. Kommentar von scytale:

    Dachte du suchst was, wo man sich auf einer deiner Seiten anmeldet und diesen Login dann für alle anderen Seiten verwenden kann. Da musst du doch keine anderen Logins zulassen?

    Wie Spamsicher das ist, hängt ja nur von den verwendeten CAPTCHAs ab bei der Registrierung, nicht von OpenID?

  6. Kommentar von proog:

    mmh, so gesehen ja… Aber dafür würde auch ne LDAP-Authenfizierung reichen… Welchen wirklichen Vorteil hätte OpenID da? (richtiges SSI isses ja auch ned oder?)

    Ich hatte es irgendwie so verstanden, das der wirkliche Vorteil bei OpenID eben der ist, das jeder sich seinen „Provider“ raussuchen kann, dem er vertraut… Vll sollte ich mich da mal genauer einlesen…

Kommentar hinterlassen

You must be logged in to post a comment.

Archiv

Zufällige Bilder

  • LED LENSER M7
  • Philips HD4419/20: Auftauphase...
  • sidebarlogin

Kommentare (28 Tage)

Sonstiges


Bloggeramt.de