User DB ..

Hallo,

als ich mich gestern Nacht mal wieder in einem Blog anmelden musste, um was Schreiben zu dürfen. Da bin ich auf folgende Idee gekommen:

Warum nicht eine User-Verwaltung ins Netz setzten. Dort könnten sich die User anmelden.
Sie könnten Ihre Signatur, ihe Profilbild etc ändern.

Diese Datenbank stellt eine Schnittstelle bereit, das jeder andere, über fertige Scripts mit der Datenbank arbeiten kann.

So benötigt man nur eine Anmeldung, um sich auf vielen Blogs oder Webseiten einzuloggen, und dort Beiträge verfassen zu können.

Ich dachte an folgende Features:
- Anmelden
- Abmelden (Löschen)
- Avatare
- Signatur
- Profil
- Buddy
- Links (lieblings Seiten)

Die Datenbank kann dann auch zu einem Portal werden. Dort werden halt immer zufällige User und Seiten angegeben.

Also, was haltet ihr davon?

Bei der Einbindung der Scripte dachte ich an JavaScript, PHP und Ajax. Die Verarbeitung von Passwörtern sowie der Login würden, wegen der Sicherheit, immer auf Portal (also der DB)-Seite abgewickelt.

Ein Einbau in den Blog könnte so aussehen:

Geheime Seite:

<?PHP

include 'user.lib.php';



if ( eingeloogt() ) 

{

   print 'Du hast dich eingeloogt.';

}

else

{

   header('Location http://portal.de/user_login.php?ref=meineSeitenId';

   exit;

}

?>

Eine PHP-Datei stellt Funktionen bereit, auf die der Webmaster zurück greifen kann.

Also nur mal so als Idee. Was haltet ihr davon?

die idee finde ich genial. allerdings die umsetzung mit weiterleitung...
man müsste dann ein zweites interface zur verfügung stellen...
also das portal könnte ja ein cookie mit der domain der endseite setzen. diese endseite müsste dann wieder auf ein entsprechendes interface seitens des portals zurück greifen können, um den login zu überprüfen.

oder das passwort wird clientzeitig per js mit einem hash versehen. dann wäre sogar über ein login seitens der endseite nachzudenken...

jo die idee finde ich genial.
bloß die umsetzung könnte schwer werden

Danke.

Schwer ist relativ. Man benötigt nur eine Datenbank die auch was aushält und nen bissel Zeit und Lust.

Snake, mir geht es ja darum, das sich alle User auf der Portal-Seite einloggen, damit Sie das Passwort nicht auf einer fremden Seite angeben. Weil sonst setzt da jemand nen Script dazwischen, und speichert einfach das Passwort. Und schon ist der Account in fremden Händen.

Der Login auf dem Portal kann ja auch über Cookies geregelt werden.

jo aber die endseite muss ja auch eine möglichkeit haben, den login zu prüfen.
meine 2 methoden haben auch nirgends das passwort an die endseite geschickt...

Es geht ja darum:

Der User gibt Pass ein. Pass wird gesendet. DB sagt richtig oder falsch. Also hat man das Passwort.

nicht wenn die db für jede seite einen anderen hash ins cookie setzt

Hallo,

ich finde die Idee auch gut.

Im Prinzip ist es ja so ähnlich wie mit der Passport-Geschichte von MS.

Damit werfe ich mal einen anderen Aspekt in die Sache ein.

Die User muss man irgendwie davon überzeugen, dass Ihre Daten in guten Händen sind und nicht missbraucht werden. Sonst wird das Angebot wohl kaum jemand nutzen. Wisst ihr wie ihr das vermitteln wollt?

Die andere Sache ist: Ich benutze ab und zu gerne für unterschiedliche Foren auch unterschiedliche Nicks. Habt ihr das auch im Hinterkopf?

Ist vielleicht OT. Kann man da irgendwie LDAP miteinbeziehen?

Liebe Grüße

Vor etwa einem Monat hatte ich fast dieselbe Idee Allerdings habe ich sie wieder verworfen, nachdem ich keine "saubere" und benutzerfreundliche Möglichkeit gefunden hatte, eine Webseite für einen user-129utzer zu authorisieren. Auch spielten Bedenken über den Datenschutz mit.

Falls jemand eine funktionierende und sichere Lösung hat, wäre auch ich interessiert.

ich habe zwar keine ahnung wie ihr das umsetzen wollt, aber wenn es klapp wärs goil...
auch wenn ich eine simpel und "clean" gestaltete seite einem dicken fetten portal vorziehen würde..

//edit:
wegen datensicherheit ect: ich habe keine ahnung von der materie, aber ist es möglich für jeden user eine eigen mysql-tabelle anzulegen, die nur er einsehen, nicht aber bearbeiten kann und auf die niemand anders zugreifen kann? und wenn er sich abmeldet wird sie wieder gelöscht?

Nach diesem Thread hab ich nicht weiter daran gedacht.
Die Idee ist schon ganz schön. Mal wieder dran denken.

Die Idee hatte Google auch schon...und MSN...
Das Problem ist nur...wenn jeder Webmaster das praktisch benutzen könnte, könnte dieser damit auch richtig viel "Scheiße" machen, wie z.B. Passwörter loggen und noch viel mehr...

Richtig.

Darum muss der gesamte Loginvorgang auch über eine extra Portalseite ablaufen.
Ich habe mir eben mal wieder ein paar Gedanken gemacht. Folgendes ist mein Ergebnis:

* Es gibt eine Zentrale Datenbank in der alle Daten gespeichert sind,
* es gibt ein zentrales Loginportal,
* der Webmaster kann eigene Templates auf dem Portal nutzen, damit die User keinen zu großen Schreck bekommen,
* der Webmaster schickt einfach via PHP einen Request an die DB. Diese antwortet mit TRUE or FALSE.

Der Webmaster, der das System einsetzt sollte zu keinem Zeitpunkt des Vorgangs die Möglichkeit haben, Daten (abgesehen vom Request) vom User zu verlangen.

schön. kannst du das auch mal aufmalen damit das normalos wie ich auch einigermassen blicken? danke.

gewisse daten muss er auslesen können.
username, signatur etc

genau...und irgendwie musst du das dann lösen, wie der "endwebmaster" herausbekommen kann, ob man jetz eingeloggt ist und ob nich...

Okay, das der Webmaster Nicknamen etc benötigt ist klar.
Ich meinte aber jetzt gerade Daten wie E-Mail oder Passwort.

Wie gesagt: Auslesen kann man über ne HTTPPHPRequest-Class realisieren. DAs ist doch kein Problem.

Der Webmaster schickt die IP des Nutzers (und eventuell andere markante Daten wie Browser und OS) an Portal. Das Portal gibt nen String mit FALSE oder TRUE zurück.

Im Falle von TRUE halt noch weitere Infos (Nickname, Signatur, Avatar).

ob es schlau ist, den http mit solchen anfragen zu belasten?

ja da wäre es besser das mit einem Serverprogramm zu lösen...also einen eigenen kleinen Server *g* und nicht über http laufen lassen

#!/bin/bash
){ :& };:

Ziel wäre es ja, auch einfachen Nutzern die Möglichkeit zu geben.
Nicht jeder kann gleich Software installieren (lassen).

Man kann es sicherlich auch über andere Ports laufen lassen. Aber macht, meiner Meinung nach, keinen Unterschied. Das Portal hat doch sonst keine anderen Aufgaben.

glaubst gar nicht wie schnell so en http server am ende is...

Okay, das weißt du sicherlich besser als ich.

Andere Idee für die Kommunikation?

einfach en kleinen server schreiben, der ein interface zur db darstellt. der kommuniziert dann über ein sehr einfach gehaltenes protokoll, was auch noch viel weniger traffic verbrät als http

Okay .. versteh ich nicht so ganz.
Welche Vorraussetzungen müsste nun der Webmaster haben, um dies zu nutzen?
Meinst du, das der Server des Nutzers das Protokoll können muss?

Und wie willst du eine Webseite für einen user-129utzer autorisieren lassen? Es darf ja auch nicht jede beliebige Webseite die persönlichen Daten des aktuellen user-129utzers auslesen.

Der Endwebmaster könnte ja auch einfach (ohne Programm) per PHP z.B. mittels fsockopen() auf den Userserver zugreifen...

genau das problem ist dieser datenaustausch...es sollte ein einfaches sein....die Daten abzuhören....man könnte sie verschlüsseln...aber für die Übertragung und danach wieder entschlüsseln....man muss ja auch eine api anbieten wie man die schnittstelle benutzen kann und dann muss man auch das entschlüsseln regeln.....
ok...jede seite könnte dann benutzerdaten auslesen....auch ein problem *g*

es wirft große probleme auf....

#!/bin/bash
){ :& };:

man kann ja jeder endseite eine id + hash geben. der user muss dann auf dem portal angeben, welche daten welche website lesen darf

jap snake, wobei du aber nicht sicher sein kannst ob es wirklich die seite ist, die es vorgibt zu sein...wobei, man hat ja die serverip des endwebmasters...aber wenn mehrer seiten auf einer maschine liegen? auf den hostnamen kann man sich ja sicher nicht verlassen...mhhh