Account auf anderer Domain anlegen?

Hatte schonmal was techinsches zu dem Sachverhalt geschrieben.

Jetzt eher ne moralische/rechtliche Frage:

Wenn sich ein user auf Domain B registriert, und ich lege ihm automatisch einen "Universal-Account" auf Domain A an, mit dem er sich dann auch bei Projekt C, D, usw. einloggen kann. Denkt ihr, das ist ok?

Bzw. unter welchen Umständen fändet ihr es ok?

1) Der User registriert sich, bekommt dann eine Bestätigungsmail, in der er erfährt, dass er sich mit dem Account auch hier und dort anmelden kann.

2) Bei der Registrierung steht (im Kleingedruckten), dass er sich hiermit einen "Universal-Account" anlegt, mit dem er sich auch auf anderen Websites/Projekten einloggen kann.

3) Der user wird bei Klick auf Registrieren auf Domain A weitergeleitet, um sich dort den Account anzulegen, den er dann auch auf B benutzen kann.

Also ich denke mal, 2 und 3 wären auf jeden Fall ok. 3 fände ich zu umständlich.
Ich überlege aber auch, die info beim regsitrieren direkt (2) wegzulassen, weil ich die Registrierung möglichst einfach und ohne viel Lesequal gestalten will.

Die Frage ist also, ob man sich verarscht vorkommen würde, wenn man erst in der Mail erfährt, dass der Account "weitreichender" ist, als man zuerst dachte, und ob es vielleicht sogar rechtlich fragwürdig ist.

Ich wuerde ganz klar 3. bevorzugen. Fuehle mich als User bevormundet, wenn man mich in Portale zwaengt, bei denen ich mich nicht anmelden moechte. Ich wuerde dann wahrscheinlich direkt meinen Account loeschen, wenn ich das spaeter erst erfahre oder es im Kleingedruckten versteckt ist und man es im Normalfall dennoch erst spaeter merkt.

Das ist auch kein bischen aufwendiger als jede andere Loesung, wenn man das Design ein wenig modular embedded. An einer Weiterleitung sollte es doch nicht scheitern? Im Grunde spart es sogar Aufwand, weil man nur ein Registrierungssystem braucht.

Also ka wie es unter rechtlichen Gesichtspunkten aussieht, aber aus moralischer Sicht finde ich es nicht akzeptabel, den User einem Service unterzuschieben, an dem derjenige vielleicht nicht interessiert ist.

Original von Kallisti

Das ist auch kein bischen aufwendiger als jede andere Loesung, wenn man das Design ein wenig modular embedded. An einer Weiterleitung sollte es doch nicht scheitern? Im Grunde spart es sogar Aufwand, weil man nur ein Registrierungssystem braucht.

Wie meinst du das genauer, mit "modular embedded"?

Meinst du, das Registrierungsformular in einen extra layer oder iframe oder irgendwas laden?

Ein neues Browserfenster-Popup wäre echt nervig.

Ich befürchte halt auch, dass Leute abgeschreckt werden, wenn sie sich einen Account auf B anlegen wollen, dann aber plötzlich das Logo von A bei der Registrierung auftaucht.

wegen 2): Das mit dem Kleingedruckten war auch mehr ne Option. Man kann es natürlich auch direkt ins Formular reinschreiben. Wäre das dann akzeptabler?

Ich meinte, dass die Registrierung - obwohl unter anderer URL - ja im selben Design auftauchen koennte, wie die Seite auf der man sich urspruenglich anmelden wollte. Wuerde da auch kein Popup oder so oeffnen sondern schlichtweg ganz normal verlinken.

Der User geht also auf "abc.de/", klickt auf "register", landet auf "xyz.de/register", wo im Formular deutlich und nicht zu uebersehen, vermerkt ist, dass er einen Account auf "xyz.de/" registriert, der unter anderem fuer "abc.de/" gueltig ist. Nach der Registrierung wird der User wieder auf "abc.de/" weitergeleitet und automatisch eingeloggt / darauf verwiesen, dass er die Mail bestaetigen soll.

Wenn man es so macht, ist es absolut transparent und verstaendlich fuer den User. Moechte man noch einen drauflegen, kauft man sich noch ein SSL Zertifikat fuer "xyz.de/", um seine Integritaet und das Bewusstsein fuer Datenschutz zu unterstreichen. ;)

Original von Blabbo

wegen 2): Das mit dem Kleingedruckten war auch mehr ne Option. Man kann es natürlich auch direkt ins Formular reinschreiben. Wäre das dann akzeptabler?

Wenn ich eine "Mehr-In-Eins2-Registrierung anbieten würde, würde es wie oben geschrieben einmal ins Kleingedruckte und zusätzlich noch in ein rotes Infofenster direkt über dem Abschicken-Button setzen. Das ist, denke ich, die einfachste und auch für den User komfortabelste Lösung.

Lösung Nr. 3 würde ihn vermutlich nur verwirren und Lösung 1 fände ich ziemlich dreist, da man den User ja plötzlich vor vollendete Tatsachen stellt.

Und was wäre mit einer Option, dass man mit dieser Anmeldung auch gleich noch auf weitere Spiele zugreifen könnte? Ne einfache Checkbox und fertsch...

Und wie du intern die Daten speicherst (nämlich auf einem anderen Server), interessiert auch nur die wenigsten User (sprich ein Verweis in den AGB oder ähnlichem sollte ausreichen, wenn sowas überhaupt notwendig ist).

Oder gibts einen Grund, dass du so einen universellen Account umbedingt anlegen musst/möchtest?

Original von altertoby

Und was wäre mit einer Option, dass man mit dieser Anmeldung auch gleich noch auf weitere Spiele zugreifen könnte? Ne einfache Checkbox und fertsch...

Und wie du intern die Daten speicherst (nämlich auf einem anderen Server), interessiert auch nur die wenigsten User (sprich ein Verweis in den AGB oder ähnlichem sollte ausreichen, wenn sowas überhaupt notwendig ist).

Oder gibts einen Grund, dass du so einen universellen Account umbedingt anlegen musst/möchtest?

Weiss nicht, ich möchte die Registrierung so einfach und mit so wenig checkboxen wie möglich machen :)
Aus so einer Option ergeben sich für den User ja auch wieder weitere Fragen usw ...

Den UniAccount will ich, weil es

a) für mich praktischer ist, EINE große Userdatenbank zu haben, als mehrere kleine mit sich überschneidenden Usern und

b) soll es natürlich die User dazu bringen, schneller mal auch andere mit dem Account mögliche Projekte anzutesten

Für mich würde es im wesentlichen einen Unterschied machen, ob meine Daten (E-Mail-Adresse, User/Passwort) zentral gespeichert werden, oder an mehrere Projekte weiter gereicht werden. Ersteres wäre für mich ok, mit dem Zweiten hätte ich persönlich ein Problem.

Geh doch einen ganz "anderen Weg", quasi dem technischen folgend:

• Benutzer meldet sich auf Domain B an, dabei wird sein Account auf deinem Universal-Server auf Irgendwo gespeichert (LDAP, Eigenlösung, bei Oma im Küchenschrank); der Account ist für Domain B aktiv
• Benutzer kann sich nur auf Domain B einloggen, aber Domain B kann intern ja bei Universal-Server (ja, der Küchenschrank) nachfragen.. Benutzer merkt nichts, du bist zufrieden
• wenn der Benutzer sich bei dir nochmal anmelden will oder du ihn darauf aufmerksam machen willst, das du ja noch andere nette Projekte/Server/Domains hast, kann er zwischen "Neuen Account" und "Vorhandenen Account auf Domain XY" wählen. Wählt er letztes, muss er das bsp. mit einem Passwort oder E-Mail-Token bestätigen.. hat was von OpenID. Dann steht im Küchenschrank, dass der Account für Domain A und Domain B aktiv ist. Und alle sind zufrieden.

Und was die Formularüberfrachtung angeht: Diesen Switch zwischen "Neuer Benutzer" und "Benutzer übernehmen" kann man bspw. mit Javascript dynamisch austauschen.. und damit das ganze auf eine 2-3 Controls minimieren.

@todi: Weitergereicht würden keine Daten werden. Nur, wenn der User auch in einem anderen Projekt aktiv werden will. Nur, das schnell, einfach und glaubwürdig zu kommunizieren ist die Schwierigkeit.

@knalli: der Nachteil bei deiner Methode ist nur, dass ich ja will, dass der User merkt, dass er einen Universalaccount hat, damit er eben auch auf andere Angebote aufmerksam wird ;).

Man könnte natürlich in der Freischalt-Mail sowas schreiben wie:

"Übrigens kannst du dich mit deiner email und pw auch auf allen anderen Seiten des Netzwerks bla einloggen, ohne einen neuen account anlegen zu müssen.
[Liste der domains]"

Ist das dann Prinzip schon wieder Lösung 1?

Immerhin hätte der User das Gefühl, dass der Account auf der von ihm gewünschten Site angemeldet wurde, und nicht auf einer anderen. Und er bekommt einen "Mehrwert", nämlich, dass er sich auch auf anderen Seiten anmelden kann, aber unverbindlich.

Und was spricht dabei gegen meinen Vorschlag? Da hast du alles genauso ohne den User in irgendetwas hineinzuzwingen, weil er es vorher schon weiss.

naja, das mit dem gleichen design ist z.b. relativ aufwendig, aber sicher machbar.
Du meinst also, ich mach auf xyz.de ne register-seite mit austauschbarem template, das immer ein bestimmtes Template im Stil der aufrufenden Seite benutzt?
Ein bisschen gewurschtelt kommt mir das halt vor.

Und das hin-und-herleiten zwischen 2 Domains könnte evtl. auch befremdlich auf den User wirken.

Die schlechteste Lösung ist es sicher nicht.

Ich werd mir nochmal Gedanken dazu machen.

Danke für die Meinungen und Anregungen!

Weitere sind natürlich willkommen :)

Dann sollte die Registrierung entsprechend aufgebaut sein "Registrierung eines Küchenschrank-Accounts" - einen treffenden Namen solltest du dann für den User wählen. Darunter ein Absatz, der kurz aber deutlich darauf hinweist, dass dieser Account zwar nur für Domain B funktioniert, aber auf _Wunsch_ des Benutzers auch für andere Dienste von Oma zu nutzen ist.

Das klingt in meinen Augen wesentlich besser als "du kannst dich damit übrigens bei allen Tanten anmelden".

Original von knalli

dass dieser Account zwar nur für Domain B funktioniert

Aber das ist doch glatt gelogen?

Er funktioniert ja eben auch für andere "Tanten"

Original von Blabbo

Original von knalli

dass dieser Account zwar nur für Domain B funktioniert

Aber das ist doch glatt gelogen?

Er funktioniert ja eben auch für andere "Tanten"

Ich schrieb ja.. im Küchenschrank steht, dass es nur für Domain B funktioniert. Klarheit bei dir, Klarheit beim Benutzer.

Original von knalli

Original von Blabbo

Original von knalli

dass dieser Account zwar nur für Domain B funktioniert

Aber das ist doch glatt gelogen?

Er funktioniert ja eben auch für andere "Tanten"

Ich schrieb ja.. im Küchenschrank steht, dass es nur für Domain B funktioniert. Klarheit bei dir, Klarheit beim Benutzer.

hehe, ich bin verwirrt!

Es soll doch aber auch für die anderen funktionieren!

Das kann der Universalserver doch handlen.. theoretisch kannst du auch alle Dienste automatisch freischalten. Nur dann hast du das Problem, der Benutzer dies entweder mitbekommt und das gar nicht will oder dass er es sieht und verwirrt ist, wieso er denn einen Account bei A machen muss um B zu nutzen. Über dieses "Freigabesystem" sollte es auch der letzte schnellen - für dich technisch ist das Jacke wie Hose, weil eh das selbe. Es ging dir hier doch eh nur darum, wie du das am Besten verkaufen kannst.

Wenn du mehrere Projekte hast, für die du einen zentralen authentifizierungsserver verwendest wäre dagegen eh nichts zu sagen, die Daten des Benutzers werden ja nicht an verschiedenen Orten ohne sein Wissen gespeichert. Grundsätzlich ist es immer "Best Practice" den Benutzer so weit wie möglich aufgeklärt zu halten, was nun genau mit seinen Daten passiert.

Alternativ:

Was hälst du davon, dem User aus dem Projekt, wo er sich angemeldet hat, einen Login bei anderen deiner Projekte mittels Authtoken zu ermöglichen? Frei nach "der User kommt von Projekt a, bringt einen validen Token mit, daher wird ihm hier Zugang gewählt." Nach authentifizierung bietest du dem User an, notwendige Daten aus dem anderen Spiel zu importieren. (Sie blieben gespeichert wo sie sind, es würde nur vermerkt, dass auch Projekt B Zugang zu diesen Daten bekommt).

Das verursacht dem User wenig arbeit, lässt ihm aber die Kontrolle.

Saludos,

Stefan