Wie übertrage ich die Facebook ID sicher von Client zu Server?

8

Ich habe eine Facebook-Canvas-App. Ich verwende das JS SDK, um den Benutzer auf der Browserseite zu authentifizieren und verschiedene Informationen über FB.api anzufordern (z. B. Name, Freunde, etc.).

Ich möchte auch einige zusätzliche Benutzerinformationen (nicht auf Facebook) in der Datenbank auf meinem Server durch einen Ajax-Aufruf beibehalten:

%Vor%

Um dies auf dem Server zu speichern und mit dem richtigen Benutzer zu verbinden, muss ich die Facebook-UID kennen und das stellt ein Problem dar. Wie übergebe ich die UID vom Client an den Server.

Option 1: Fügen Sie der AJAX-Anfrage eine UID hinzu :

%Vor%

Das ist offensichtlich nicht gut. Es wäre trivial für jedermann, eine Ajax-Anfrage an meinen Web-Service zu stellen, indem er die Facebook-ID eines anderen benutzt und seine Lieblingsfarbe ändert.

Option 2: Extrahieren Sie auf dem Server die uid von einem Cookie : Ist das überhaupt möglich? Ich habe gelesen, dass Facebook einen Cookie mit der UID und dem Zugangstoken setzt, aber habe ich Zugriff auf diesen Cookie auf meiner Domain? Noch wichtiger, kann ich sicher die UID aus dem Cookie extrahieren oder ist diese genauso wie Option 1 für Spoofing offen.

Option 3: Benutzerserverseitige Authentifizierung auf dem Server : Ich könnte die serverseitige Authentifizierung verwenden, um die Benutzeridentität auf meinem Server zu überprüfen. Aber funktioniert das, wenn ich die clientseitige Authentifizierung bereits im Browser verwende? Erhalte ich zwei verschiedene Zugriffstoken? Ich möchte FB.api Anfragen vom Browser machen, also brauche ich das Zugriffstoken auf dem Client (nicht nur auf dem Server).

Dies muss ein sehr häufiges Szenario sein, daher denke ich, dass mir etwas Grundlegendes fehlt. Ich habe eine Menge der Facebook-Dokumentation (verschiedene Authentifizierungsabläufe, Zugriffstoken, signed_request usw.) und viele Posts zu SO gelesen, aber ich verstehe immer noch nicht, wie clientseitige Authentifizierung und serverseitige Authentifizierung gut zusammenspielen / p>

Kurz gesagt, ich möchte die Identität des Benutzers auf dem Server wissen, aber immer noch Anfragen an die Facebook API aus dem Client-Browser machen?

(Ich verwende ASP.NET und das Facebook C # SDK auf dem Server)

BEARBEITEN : Kopfgeld hinzugefügt. Ich hatte gehofft, eine difnitive, offizielle Empfehlung zu bekommen, wie man mit dieser Situation oder sogar einem Beispiel umgehen sollte. Wie gesagt, ich habe bereits viele der offiziellen FB-Dokumente über Authentifizierungsabläufe gelesen, aber ich kann immer noch nichts definitives darüber finden, wie clientseitige und serverseitige Authentifizierung zusammenarbeiten.

    
njr101 24.05.2012, 13:05
quelle

4 Antworten

3

Option 1: Der einfachste Weg, den ich mir vorstellen kann, ist, den accessToken in JS aufzunehmen und ihn mit dem Ajax-Aufruf zu übergeben.

Option 2: Verwenden Sie das gleiche wie Option 1, senden Sie das signedRequest jedoch, anstatt nur den accessToken zu senden.

Auf der Serverseite können Sie es mit ( TryParseSignedRequest method) dekodieren, was Ihnen UserID : -)

gibt

Hinweis: signedRequest ist mit der Anwendung Secret verschlüsselt. Du bist der Einzige, der es wissen sollte, damit du sicher bist.

Haftungsausschluss:

Ich habe keine Programmiererfahrung in C #, aber eine kleine Suche in Google gab mir das:

Facebook C # SDK für ASP.NET

Erstellen von AJAX-Anfragen mit dem Facebook C # SDK

    
Roni 29.05.2012, 15:48
quelle
1

Es ist wirklich sehr einfach.

Wenn der Benutzer Ihre App lädt, verwenden Sie die serverseitige Authentifizierung , holen Sie sich das Zugriffstoken und laden Sie es die Benutzerdaten durch Ausgabe einer API-Anfrage vom Server.
Auf der Server-Seite haben Sie alles, was Sie brauchen und es ist Sandkasten.

Wenn die Seite für den Benutzer gerendert wird, sollten Sie mithilfe der js sdk die Benutzerauthentifizierungsdaten abrufen Sie können FB.getLoginStatus verwenden, da der Benutzer die serverseitige Authentifizierung bereits durchlaufen hat. < br> Jetzt haben Sie auf der Client-Seite auch ein Zugriffs-Token, mit dem Sie die Benutzerdaten aus dem Graphen api holen können.

Die beiden Tokens sind unterschiedlich und haben auch unterschiedliche Ablaufzeiten, aber das sollte kein Problem sein, beide Token sollten so funktionieren, wie Sie es erwarten.
Da beide Seiten ihr eigenes Token und eine Möglichkeit haben, Anfragen an die API zu richten, müssen keine fb-Daten zwischen ihnen gesendet werden.

Die dritte Option, die Sie erwähnt haben, klingt für mich am besten und es ist auch sehr einfach, das zu implementieren.

Bearbeiten

Alle Facebook-SDKs sind nur Wrapper für HTTP-Anfragen, da die gesamte fb-API auf http-Anfragen erstellt wird.
Die SDKs geben Ihnen einfachen und kürzeren Zugriff auf die Daten ohne die Notwendigkeit, die URL selbst zu erstellen (mit all den verschiedenen möglichen Parametern), die Anfrage zu machen und die Antwort zu parsen.

Um ganz ehrlich zu sein, halte ich die Bereitstellung einer Möglichkeit für das C # SDK, die serverseitige Authentifizierung zu unterstützen, für eine sehr schlechte Entscheidung Was bringt es, ein SDK bereitzustellen, das nicht die gesamte API implementiert?

Die beste Antwort auf Ihre Frage ist nach meiner Erfahrung die serverseitige und die clientseitige Authentifizierung, und da das C # SDK dies nicht unterstützt, ist mein Rat an Sie, Ihr eigenes SDK zu erstellen.
Es ist überhaupt nicht kompliziert, ich habe es bereits für Python und Java (zweimal) implementiert, und da Sie es für Ihre eigenen Bedürfnisse entwickeln, kann es genau auf Ihre Bedürfnisse zugeschnitten werden, im Gegensatz zu einem öffentlichen SDK, das alle möglichen Optionen unterstützt.

2. Bearbeiten

Sie müssen kein komplett neues SDK erstellen, Sie können einfach die verwendeten SDKs "erweitern" und die fehlenden Teile, wie z. B. die serverseitige Authentifizierung, hinzufügen.

    
Nitzan Tomer 31.05.2012 10:51
quelle
0

Ich weiß nicht, ob es sprachspezifisch ist, aber die Verwendung sowohl der serverseitigen als auch der clientseitigen Authentifizierung schadet nicht.

Sie können an Option 2 arbeiten, aber ja, das ist auch anfällig für Spoofing.

Wenn Sie Option 3 ausführen, haben Sie ein einziges Zugriffstoken für diese Benutzersitzung, das wäre meiner Meinung nach die beste Wahl, da Sie immer Spoofing-Möglichkeiten haben, wenn Sie Benutzerinformationen von der Clientseite weitergeben.

    
Akshat Goel 24.05.2012 13:12
quelle
0

Ich hatte kürzlich genau die gleiche Frage. Es ist Option 2. Überprüfen Sie diesen Beitrag aus dem Facebook-Blog.

Um ehrlich zu sein, ich bin nicht genug von einem Hacker, um zu wissen, ob Sie die UID im Cookie spoofieren könnten, aber dies scheint die "offizielle" Art zu sein, dies zu tun.

EDIT: zu der anderen Frage unter Option 2, ja, ich glaube, Sie müssen auf diesen Cookie auf Ihrer Domain zugreifen.

    
Ed Hinchliffe 29.05.2012 15:29
quelle