PHP Modus vivendi: anmelden mit facebook-Account

cumulonimbus8

Fleet Admiral
Registriert
Apr. 2012
Beiträge
19.475
Hallo…

Ich liebe facebook… Innigst… Kurz: ich habe keine blassen Schimmer, außer, dass ich das nur mit der Beißzange anfasse. Und jetzt will der Chef eine Funktion haben, dass man sich auch per facebook-Account anmelden kann.

OK, mir ist klar (und deshalb Präfix PHP), dass ich einen User in meiner Datenbank mit irgendwas flaggen muss um ihn wiederzuerkennen (unique ID, wie an so schön sagt). Deshalb gleich hier die entscheidende Frage: Was bekomme ich von facebook geliefert wenn ich deren unter /development beschriebene Codeschnipsel auslöse?

Ob nun ein bisschen automatisches Script auf meiner Login-Page irgendwie ermittelt ob der User gerade bei facebook eingeloggt ist, ob ein regelmäßiges Polling ihn bei mir abtrennt wenn er sich ausloggt, das nenne ich erst mal Begleiterscheinungen.

Da es heißt, dass man bei facebook sich wohl mit einer Mailadresse einloggt, die man aber fröhlich austauschen kann, ist mir einfach nicht ersichtlich was ich von Zuckerberg bekomme. Denn da muss ein User ja (auch s)eine eindeutige ID haben, egal welche Mailadresse zz. opportun ist. Bekomme ich nämlich diese stehe ich im Wald. Oder muss ich Daten an facebook mit all denen liefen die ihr OK für ein Einloggen-per-facebook gegeben haben (über irgend so eine App-ID)?

CN8
 
…da werde ich morgen einiges zu verdauen haben ;)

CN8


2013-10-02 11-09-45
Ich habe das gelesen - und nach meinem Geschmack war das ziemlich viel Wiederholung um ungelegte Eier, aber nichts was mir konkret für meinen bescheidenen Fall weiterhilft.

Also mal eine logische Kette von Gedankengängen damit ich den Mechanismus begreife:
• Meinem User will ich ich facebook-Anmeldung erlauben. Ich kennen meinen User und - dann weiß ich nicht wie es weitergeht. Eine App (von facebook) wird ausgelöst die feststellt, dass mein User bei facebook ist; für mich logisch dadurch, dass er durch die fb-Anmeldung muss[te] und so irgendwas an mich liefert.
• Das heißt, es muss eine Art 1. Registrierungsschritt für diese fb-Anmeldeerlaubnis von meiner Seite aus geben. Der könnte unauffällig im Hintergrund laufen (Skript fragt fb an, bekommt eine Positivmeldung, trägt ID hier ein), oder sollte man sich besser ein OK geben lassen? Wie auch immer, ich habe nun also meinen User plus dessen fb-ID in meiner Datenbank.
• Somit kann ich die gewöhnliche fb-Anmeldungs-Schaltfläche anlaufen lassen und bekomme (sei der User bei fb eingeloggt oder tue er dies nun auf Anfrage) die bewusste fb-ID die wiederum meine Skripte mit meiner Datenbank abgleichen und bei Erfolg diesen User hier einloggen?
• Sonderfälle wie falsche oder unbekannte IDs müssen irgendwie intelligent abgefangen werden, aber das hat mit dem Grundmechanismus um den es mir geht erst mal nichts zu schaffen.

Bin ich damit so weit auf der richtigen Spur wie der Grundprozess ablaufen soll?
 
Zuletzt bearbeitet:
Step 11 beinhaltet alle Infos die du brauchst. Wie du das dann löst ist deine Sache aber immo mit der Anleitung aus dem Link die praktisch alles beinhaltet kein Problem..
 
Auch Schritt 11 wirft nur mit Code und Worthülsen um sich, beantwortet aber nicht meine Fragen: Was bekomme ich von fb; oder genauer, was ist das was ich da vom Skript bekomme? Von tollen Namen kann ich mir nichts kaufen, ID kann sonst was sein…

CN8
 
Das ist die User-ID von Facebook, denke ich mal. Es muss ja einen eindeutigen Identifikator geben, wenn sich alle anderen Daten ändern können.

Wenn du das Prinzip verstehen willst, lies mal hier. Bereits nach ~25 Seiten hast du das Prinzip begriffen.

P.S.: Ich hab von dem Facebook-Kram keine Ahnung. Ich hab OAuth2 aber auf einer Plattform implementiert, wo eben diese Plattform quasi in der Rolle ist, die in deinem Fall Facebook spielt. Ich sende dabei auch unsere User-ID mit raus, damit die externe Plattform den User noch identifizieren kann, wenn sich seine E-Mail bei uns geändert hat. Sie updaten dann ihre Daten entsprechend. Ohne die unveränderbare ID ginge das nicht.
 
{Seufz} Ich wills mal so formulieren:

Mein Problem - Erhöhung der Bevölkerungszahl auf der Welt.
Antwort - Lies das Kamasutra. (Hübsche Bilder. He, das macht sogar Spaß!)
Aber kein Wort, dass man dazu primär mal Babys braucht, die man sogar selbst herstellen kann. Unter Zuhilfenahme von Frau und Mann. Wwie die das machen (können), das weiß ich jetzt, das Warum fehlt aber noch. Und um Nebenwirkungen wie Samenqualität, gebärfähiges Alter oder fruchtbare Tage kümmere ich mich später.

Welchen Wirkmechanismus setzt man da ein, nicht wie setzt man da Skripte ein - das möchte ich wissen; was soll\muss ich tun, nicht wie\womit. Strategie, nicht Taktik. (@Tumbleweed: auch dein Link ist eben nur das Wie.)

CN8
 
Im RFC steht doch das Prinzip, keine konkrete Implementierung. Es gibt bei diesem Standard

  • einen resource owner (der User), der Daten hat, für deren Zugriff du Autorisierung (durch den User selbst) willst
  • einen client (du, bzw. deine Web-App), der Autorisierung wünscht
  • einen authorization server (hier Facebook), dem der User bereits vertraut, denn er hat dort seinen Daten (inkl. Login) hinterlegt
  • einen resource server (auch Facebook), wo die User-Daten hinterlegt sind (man merkt schon, das ist oft gleichzeitig auch der authorization server)

Der Standard bietet 4 Wege der Autorisierung. Einer davon ist empfohlen, da er nicht vom Vertrauen zwischen client und authorization server abhängig ist. Diesen benutzt meines Wissens nach auch Facebook. Dabei öffnet der Client entweder ein iFrame oder ein neues Fenster (Popup), in dem der User auf vertrautem Terrain (Facebook-Website) seine Login-Daten eingeben kann. Er muss dadurch nicht darauf vertrauen, dass der client sorgfältig mit diesen Daten umgeht, da sie direkt beim client landen. Als Parameter wird bei diesem redirect noch eine client_id (die Identifikation deiner Web-App gegenüber authorization server) und eine redirect_uri mitgegeben. Alle diese Parameter sind Teil des Standards. Einige sind optional. Die Schreibweise ist entsprechend von Bedeutung und muss standardkonform sein.
Hat der User sich dort erfolgreich eingeloggt, redirected der authorization server zurück an die vom client per Parameter übergebene redirect URI. Dabei hängt er einen authorization code als Parameter an, den der client haben möchte.
Diesen code nimmt der client und geht rein serverseitig nochmal zum authorization server. Dafür gibt es dort in der Regel einen separaten token endpoint, den ich z.B. als Servlet implementiert habe. Dort schlägt der client nun samt authorization code, client id und client secret auf. Dadurch identifiziert sich der client gegenüber authorization server eindeutig (sonst könnte ja jeder kommen, der den auth code abgegriffen hat). Stimmt die Konstellation von client id, client secret und auth code, dann erhält der client einen access token, der ihm die Berechtigung erteilt auf bestimmte Daten zuzugreifen. Dieser token kann zudem per scope begrenzt sein. Ist aber optional.
In diesem Moment ist implizit der Login-Vorgang genehmigt und du kannst den User bei dir einloggen, denn nun kommst du ja an dessen Daten. Der Login ist quasi nur ein Nebenprodukt, denn bei OAuth geht es in erster Linie um Autorisierungen für Datenzugriffe.

So, genauer geht es nun aber wirklich nicht mehr. :p

Der Standard sieht an einigen Stellen Variationen vor, d.h. hier und da kann Facebook einen geringfügig anderen Weg nutzen (andere Parameter, die optional sind im Standard). Aber für sowas muss man nunmal die Doku lesen. Das gehört zum Job eines Web-Devs. Bei jenen, die damit ihre Brötchen verdienen, umso mehr. :freaky:
 
@Blackbenji
Du kannst dir ja gar ich vorstellen welche Site ich zuallererst ansurfte als man das an mich herantrug.

@Tumbleweed
Du beschreibst wieder nur Wege und Kochrezepte…
Es interessiert mich nicht, dass es resource owner, clients, authorization server und resource server gibt. So wenig wie es mich interessiert, dass ein Auto Räder hat, Benzin braucht, über einen Motor verfügt und sogar einen Sitzplatz für einen Fahrer - wenn es darum geht irgendwie von München nach Hamburg zu kommen: die Route muss geplant werde, die Verkehrsregeln muss ich kennen, nicht wie man Luft aufpumpt oder den Sitz verstellt.

Was muss ich machen wenn ich ein fb-Login erlauben will, nicht womit - denn das zu wissen nützt nichts wenn ich das Was nicht kenne was als Ziel zu erreichen ist.

CN8
 
cumulonimbus8 schrieb:
Was muss ich machen wenn ich ein fb-Login erlauben will, nicht womit - denn das zu wissen nützt nichts wenn ich das Was nicht kenne was als Ziel zu erreichen ist.

Den oben schon mehrfach gezeigten Weg so in deiner PHP Webapplikation einbinden, das sie eine gültige Loginsession erzeugt. Wie du das in FB hinterlegen musst, steht dort ebenfalls. Genauso wie da steht welche Informationen durch FB zurückgegeben werden die du dafür verwenden kannst (eg die UserID des FB Users z.B.) Keine Ahnung was du nun genau willst. Solls dir jemand in deine Webanwendung einprogrammieren oder was genau ist eigentlich dein Problem? Brauchste nen PHP Grundkurs im Sessionhandling?

Ohne Code und Hintergrund zu deiner Anwendung können wir dir nicht sagen wie du von "München nach Hamburg" kommst.
 
Ich brauche keinen Kurs in Automechanik, auch keine Fahrschule - ich will wissen was ich auf dem Weg von München nach Hamburg beachten muss.

Code existiert keiner. Eben weil ich noch keinen Marschplan habe was alle zu codieren wäre. Wenn mich unser Mensch der die DB verwaltet fragt: „Was kriege ich von dir?“ müsste ich ihm antworten, dass er… →

Ich kenne Facebook nicht. Ich habe keinen Plan was ich über eine dortigen User wissen muss oder nicht. Keine Idee was genau fb mir zur Verfügung stellt. Namen können vieles sein.

→ …eine eindeutige User-ID des Users bei/von fb von fb (in einer Variable Namens soundso in PHP) bekommt die er dann seiner DB einverleibt um vergleichen zu können. Nun frage ich unseren Hompagespezialisten wo (in seiner Mechanik der Aufrufe) wir den hier viel angepriesenen Code einflechten können nachdem besprochen wurde wie wir mit bestimmten Zuständen [ist User bei fb eingeloggt oder nicht, Auto-Einloggen wenn er unsere Seite besucht…] umzugehen wünschen. Wie der Homepageexperte dem DB-Experten die ID zuspielt müsste eruiert werden.
Und ich sitze als Armes Würstchen wie die Spinne im Netz, grundsätzlich wissend wie man eine DB verwaltet, grundsätzlich wissend was eine Ziele in einem Skript auslöst - und wohl wissend wo ich den Kollegen nicht in deren Handwerk pfusche wie es bei mir nicht tun.
Ich soll Eckdaten liefern auf denen eine Strategie gebaut wird - und dann kommt die Taktik welche App (wer verwaltet dieselbe?) und welches Skript wo und wie eingebaut wird. Das weiß das Tutorial.

CN8
 
Wie wärs einfach damit: Du schnappst dir das oAuth-Plugin eines beliebigen Open Source CMS und orientierst dich an dem Code?
Außerdem: https://developers.facebook.com/docs/facebook-login/login-flow-for-web-no-jssdk/

Und zu guter Letzt: Warum gibt es separate Spezialisten für Homepage (du meinst wohl: HTML+CSS), Datenbank und dich dazwischen? Und was tangiert dich überhaupt die Arbeitsweise der anderen 2? Genau dafür gibt es Design-Pattern, die so etwas abstrahieren. Der DB-Spezi liefert Daten, du schreibst Kontrollstrukturen für diese Daten und der Frontend-Entwickler stellt die von dir verarbeiteten Daten in verschiedensten Formen aus. Davon abgesehen, dass man sich auf einige wenige gemeinsame Berührungspunkte einigt (eben diese Abstraktionsschicht) geht es dich einen feuchten Furz an, wie die anderen Elemente des Systems funktionieren.
 
Und was tangiert dich überhaupt die Arbeitsweise der anderen 2?
Die tangiert meine Arbeitsweise, wenn wir das so sagen wollen. Wir sind eine kleine Firma mit Mitarbeiten die nicht eine Tür weiter hausieren und die noch andere Tätigkeiten ausführen. Besagte Anfragen landen fröhlich bei mir {seufz} und ich muss sehen was ich damit anstelle weil ich wenigstens von allem genug verstehe um zu wissen was da grundsätzlich passiert.

Und wenn jetzt mein lokaler Testserver liefe könnte ich die Rückmeldungen der vorgeschlagenen Skripte wenigstens mal testen…

CN8
 
Anmelden mit facebook-Account / FB klemmt

Hallo erneut!

Ich versuche gerade mittels JS Versuchsballons zu starten. Tatsächlich bekam nicht mit Beispielcode die FB-Anmeldebox zu sehen.
Was immer mich dann in den FB-Einstellungen (Apps ► {Testaccount} ► Grundlegendes) geritten hat, offenbar müssen dortige Versuche etwas total verklemmt haben. Klice ich auf meinen Button der die Anmeldung vorholen soll kommt:
«Die Anwendungseinstellungen lassen die angegebene URL nicht zu.: Eine oder mehrere URLs sind in den Einstellungen der App nicht zugelassen. Sie müssen mit der Website-URL oder der Canvas-URL übereinstimmen, oder die Domain muss Subdomain einer der App-Domains sein.»

Wobei die dumme erste Frage wäre wo ich eine URL angegeben hätte. Nicht in meiner Test-HTML-Page [2 Versionen, selbe Meldung - ergo…], also bei Facebook an der o.g. Stelle. Das hatte ich mal versucht… {irgendwas}.anydns.info:19999/fb/, was mein lokaler XAMPP ist..:
«Fehler App Domains: {irgendwas}.anydns.info:19999/fb/ is not a valid domain.»
OK; ich habe schon gelernt, dass ich kein www. oder http:// voranstellen darf. Aber das da wäre theoretisch gültig. Was bleibt mir als das wieder zu löschen und ein paar Minuten zu warten? Nur kommt seit dem dieser Rattenschwanz von Meldung oben - den ich maximal so verstehe da was angeben zu müssen was mir die 2. Meldung um die Ohren haut.


Google hat dazu schlicht nichts geliefert, also hoffe, ich dass Programmiere beim Testen das Schlagloch schon mal hatte und wissen wie man es umfährt.

CN8
 
ich rate mal: ohne Port und den featurebranch-ordner am Ende hast du es noch nicht versucht?
{irgendwas}.anydns.info dürfte eine valide (sub)domain sein.
 
Seufz… Hatte ich auch schon, die Idee. Da das aber zu meiner Büchse durch den Router muss komme ich ohne Port nicht fort.

CN8


Hmtja…
Vielleicht hatte ich mich ungewollt doch angemeldet (was ich meinte extra ausgelassen zu haben), wenigstens hatte ich den IE mit dem ich das unabhängig von FF, in dem die App-Verwaltung offen war, testete nicht geschlossen.
Jedenfalls habe ich das nun von wo anders aus aufgerufen, der Button reagierte und lieferte die Anmeldemaske und nachdem ich die Eingaben tätigte (absichtlich) kam diese Rattenschwanzmeldung - was offenbar direkt beim Klicken des Buttons passiert (passieren muss) wenn ich über die Anmeldeschwelle weg bin.

Damit habe ich also den selben und doch einen anderen Fehler als gedacht vor mir.
 
Zuletzt bearbeitet:
Dann mach Nägel mit Köpfen, lass irgendwo hosten wo du ne echte IP nebst Domain hast...
Spätestens dei Tatsache, dass FB-Apps zur korrekten Funktion SSL-Verbindungen benötigen, würde dir mit deinem DynDNS-Gefrickel eh das Genick brechen.
 
Die Sache gärt immer noch, und die Eingangsfrage was ich (und nun eben: wie) von fb zurückkriege, das müsste ich langsam klären.
Codes die einen Button auslösen oder das übergehen falls man angemeldet ist (Cookie?), die habe ich. Aber ein simples echo das mir dann sagt wie mein User bei fb heißt (oder eben als JS-Ausgabe mit alert), diese unwichtige Info finde ich da im Gemörkse nicht…

Was AnyDNS angeht - das nutze ich notgedrungen weil meine Testumgebung dahinter hängt. Auf dem Server der dafür angepeilt ist habe ich keine Lust rumzufriemeln, ist zu umständlich und ›muss nicht sein‹. Wenn der Code grundsätzlich läuft dann wird es das auf dem Server doch wohl auch zu tun belieben.

CN8
 
ALLES folgt doch dem einfachen Request-Response - Modell. Was hindert dich, diese Response irgendwo hin zu loggen und zu GUCKEN, was du bekommst? "echo" reicht hierbei oftmals nicht, da echo zumindest in PHP eben nur einen String oder eine Zahl ausgibt, aber bereits bei Arrays scheitert.

Und wie ich dir schon sagte: Guck wie es andere machen. Es gibt zig Open Source CMS, die OAuth implementieren. Eines davon wirst du doch wohl zerpflücken können und dann gucken, wie die es machen. Wenn ich mal nicht weiter komme les ich auch andere Projekte mit analoger Problemstellung, um einen Ansatz zu finden.
 
Zurück
Oben