Facebook API: Hochauflösende valide Image-URLs

Guten Tag.

Über die FB-API bekommt man vergleichsweise kryptische Image-URLs, nämlich die Direktlinks in deren CDN. Diese haben drei Probleme:

1. Die URL zeigt auf die gering aufgelöste Version des Bildes, zu erkennen am “_s.jpg” (“s” für “small). Der gängige Ansatz, um an die hochauflösende Version zu kommen, besagt, dass man “_s” durch “_n” (für “normal?) zu ersetzen (einige empfehlen auch “_o” für “original”). Das funktioniert meistens, aber eben nicht immer. Korrekt scheint dieser (selbstverständlich undokumentierte) Ansatz, der quasi analog zur Profilbild-URL funktioniert:

<object_id> kommt aus der API. Achtung: Das funktioniert nur für Posts vom Typ “photo”; Posts vom Typ “link” müssen nach wie vor über die URL im Feld “picture” gehen! Und damit kommen wir direkt zum nächsten Problem:

2. Facebook nutzt Proxy-Skripte zur Generierung der niedrig aufgelösten Bilder. Zu erkennen an …/safe_image.php?…&url=<url_codiert> oder …/app_full_proxy.php?…&src=<url_codiert>. Diese muss man rausfilter, die tatsächliche URL dekodieren:

3. Profilbilder von altersbeschränkten Seiten sind ebenfalls altersbeschränkt 🙂 Für Zugriff muss man den Access Token anhängen (Quelle finde ich gerade nicht mehr wieder):

ggf. benötigt man das auch für die unter 1. genannten Bilder.

HTH

Twitter API: Ziel der t.co-Short-URLs

Twitter kürzt URLs mit dem hauseigenen Dienst t.co. Die so (de facto) verschleierten URLs werden auf twitter.com zwar über den Link-Text (bis zu einer gewissen Länge) wieder aufgelöst, aber die URL dahinter bleibt die von t.co. Über die API bekommt man denn auch erst mal nur die t.co-Version. Im Netz kursieren Links zu “Unshorten”-Services (Beispiel), die aber gar nicht (mehr?) nötig sind: Der Parameter “include_entities” erweitert den Response bsplw. der Suche um alle Felder, die man benötigt (hier nur die Entities):

 

Facebook: API-Zugriff auf altersbeschränkte Seite

Der API-Zugriff auf die Posts einer Seite sieht in PHP eigentlich so aus:

Aber: Wenn die Seite altersbeschränkt ist, dann ist der Response leer.

Man kann das umgehen, indem man einen Access Token mitgibt. Da stellen sich allerdings zwei Fragen:

  1. Wie gibt man einen Token mit?
  2. Woher bekommt man so einen Token?

Zu Frage 1 schlägt das Internet von Query-Parametern bis Request-Header alles mögliche vor, dabei ist es recht einfach:

Wichtig ist dabei offenbar, dass der übergebene Access Token zur Art des Zugriffs passt. Anders gesagt: Es gibt verschiedene Arten von Tokens, nämlich User Access-, App Access-, Page Access-, und Client Token. Wenn ich, wie oben, mittels einer App-ID auf die API zugreife, dann scheint das nur mit einem App Access Token zu funktionieren. Das ist wichtig zu wissen für die folgende Art, so einen Token zu generieren (Quelle, und hier):

  1. Man öffne den Graph API Explorer
  2. Man wähle ganz oben unter “App” die App, über die man auf die API zugreifen will
  3. Man klicke “Zugriffsschlüssel anfordern” (“Get Access Token”)
  4. Man öffne den Tab “Extended Permissions”
  5. Man selektiere “manage_pages” und “
  6. Man klicke “Get Access Token”, akzeptiere die Permissions im Popup
  7. der erzeugte Token gilt für 1 Stunde, was man hier überprüfen kann (einfach rein pasten)
  8. mit diesem “short-lived access_token” kann man einen 60 Tage gültigen Token erzeugen, indem man ihn zusammen mit der App ID und dem App Secret in diese URL einsetzt:

https://graph.facebook.com/oauth/access_token?client_id=FB_APP_ID&client_secret=FB_APP_SECRET&grant_type=fb_exchange_token&fb_exchange_token=FB_PAGE_ACCESS_TOKEN_SHORT

Twitter für WordPress

Es gibt viele Plugins für WordPress, um seine Tweets anzuzeigen.

Das Problem von fast allen: Sie rufen serverseitig ab, und zwar dynamisch. Ein Problem ist das deshalb, weil Twitter die Anfragen auf 150/Stunde/IP beschränkt. Wenn man, wie ich, keinen dedizierten Server mit eigener IP hat, dann sind die 150 Requests schnell aufgebraucht. Sehr schnell. Ich habe gerade (unter der Woche, gegen 23 Uhr) etwa 7 Minuten gebraucht. Wenn das Plugin nun serverseitig die Nachrichten abruft, dann kommen also keine Ergebnisse – und darüber hinaus hängt die Seite schlimmstenfalls, weil das PHP-Skript auf Twitter wartet.

Eine schlechte Eigenschaft von vielen Plugins darüber hinaus: Sie zeigen keine Retweets an.

Mindestens das folgende Plugin umgeht die oben beschriebenen Probleme: Tweet Blender. Erstens zeigt es auch Retweets an. Dann legt es einen Cache an, und verwendet diesen, statt jedes mal Twitter anzupingen. Dieser Cache wird nach dem Laden der Seite per Javascript geholt; die Seite hängt also nicht.

Außerdem zeigt es den aktuellen Serverstatus in Bezug auf verbleibende Requests an (siehe Bild; das hat mich überhaupt erst auf das Thema gebracht); auf Wunsch auch als Nachricht für den Nutzer. Es unterstützt übrigens auch mehrere Accounts (was mir persönlich schnurz war).

Das Ergebnis seht ihr rechts; morgen (oder so) werde ich das mal ein wenig skinnen.

Alternativen für Facebook-Posts aus Actionscript

Wer mit der Facebook-API für Actionscript Posts absetzen will, kann das direkt machen:

oder als Javascript-Overlay:

oder als Pop-Up

Das data-Object beinhaltet die in den Docs unter “Publishing” beschriebenen Parameter.

Facebook Actionscript API und Extended Permissions

Die Facebook Actionscript API ist schön und gut (sic!), aber sehr schlecht dokumentiert. Ein Beispiel? Die Klassen com.facebook.commands.stream.* existieren, stehen aber nicht in der Doku^^

Von daher hat es etwas gedauert, um das folgende Problem zu identifizieren: Wenn man sich per Connect bei Facebook einloggt, können Extended Permissions direkt beim Login abgefragt werden (Parameter req_perms). Die AS API bietet dies aber nicht an; in der Klasse com.facebook.session.DesktopSession (Funktion onLogin()) werden sie zwar verwendet, aber man kann keine eigene Auswahl festlegen. Also: Sourcen runterladen, ändern:

Der wichtige Punkt hier ist es, URLVariables zu verwenden!

Quelle, ich musste aber zwei Parameter entfernen, um es zum Laufen zu kriegen.

HTH