Notiz an mich:
Wenn dieser Fehler auftritt, habe ich mal wieder versucht, ein SimpleXML-Objekt in die Session zu packen. Das hätte ich besser nicht getan, denn die Dinger kann PHP nun mal nicht gescheit serialisieren. Scroob, merk’s Dir endlich!
Heute melde ich mich mal mit einem ausführlichen Essay zum Thema PHP-Entwicklung.
Vor kurzem stand ich vor der Aufgabe, für einen Kunden Facebook in dessen CMS zu integrieren. Mittels der Facebook-API ist das auch relativ komfortabel. Mal abgesehen davon, daß selbst auf developers.facebook.com verschiedene PHP-APIKits herumschwirren und dort widersprüchliche Anweisungen gegeben werden, ist es dennoch recht schnell schaffbar, eine komplexere Facebook-App zu schreiben.
Bei mir war jedoch die Anforderung gegeben, daß die Applikation zeitgesteuert Daten auf Facebook veröffentlichen können sollte. Asynchron, ohne jegliche Benutzerinteraktion. Das entwickelte sich schleunigst zu einem Problem. Denn bevor die Facebook-API die Arbeit aufnimmt, verlangt sie ein Facebook-Login-Cookie, das nur begrenzt haltbar ist.
Alle meine Versuche, dieses Cookie zu faken scheiterten an einer UID, die Facebook erst nach einer Browser-Anmeldung herausrückt. Im Netz fand ich diverse HowTo’s, wie man das Login curlt und danach ebenfalls via curl seinen Status updaten kann. Aber damit wars das auch schon. Kein Löschen möglich, keine Links posten, Notizen, etc. bla. Und ich wollte ja die volle API-Funktionalität nutzen können.
Also habe ich die cURL-Idee ein wenig modifiziert:
Facebook checkt den Login mit der API-Methode $fb->require_login($permission); – Ist der User nicht bereits in der aktuellen Browser-Session angemeldet, gibts einen Redirect zur “Ja, diese App darf auf meine Daten zugreifen”-Seite und im Anschluß erst einen Redirect zurück zur App, zusammen mit dem begehrten Auth Token. Was an sich schonmal schlecht ist, denn das CMS des Kunden liegt in dessen Intranet, nix mit externer Erreichbarkeit. Mal abgesehen davon, daß das Script ja zeitgesteuert per Cron laufen soll.
Anstelle des Facebook-eigenen Redirects lasse ich mir das API-Kit die entsprechende URL erstellen und curle diese Login-Seite. Dort parse ich alle relevanten Parameter und übergebe sie dem Login-Formular wieder, zusammen mit meinem Benutzernamen und Passwort. Den Redirect fange ich ab und werte statt dessen die zurückgegebenen Header aus. Dort steht nämlich praktischerweise der Auth Token direkt in der zweiten Redirect-URL.
Jaaaa! ENDLICH!
Vor wenigen Minuten ist der Relaunch mit über 3h Verspätung live gegangen! Erster Eindruck vom Kunden: Huch, das ist ja geflutscht!
[demscroob@lnxp-salmakis:~/b2/php/rating]$ w
18:54:28 up 555 days, 8:52, 13 users, load average: 0.22, 0.23, 0.33
Mmmh… ich würd ma sagen: Caching funzt. 
Jetzt erstma Schampus. Und dann gehts ans Testing…
Ach ja… der TPM, im Begriff, das Script für den Livegang zu starten.
Ich soll für einen Kunden die Wartung und ggfs. ein komplettes Code-Refactoring für ein paar Tools übernehmen. Meine erste Analyse für den Kunden beginnt wie folgt:
WTF?!
Parse error: syntax error, unexpected T_PAAMAYIM_NEKUDOTAYIM
WTF..?!
Hallo und willkommen zu unserer aktuellen Nerd-Runde.
Für alle Nicht-Nerds eine kurze Erklärung zum Unix-Timestamp: Dieser wird in der Software-Entwicklung sowie in der “Entwicklung-Light” (Scripting) häufig verwendet, um ein bestimmtes Datum samt Uhrzeit darzustellen. Dieser Timestamp besteht aus Ganzzahlen (Integer), die die Sekunden angeben, die seit dem 01.01.1970 00:00:00 Uhr vergangen sind. (Deshalb zeigen übrigens oft auch viele Rechner nach einer vollständigen Stromtrennung dieses Datum an.)
Wie ich soeben erfahren habe, hatten wir vor kurzem einen witzigen Timestamp. Und zwar waren dieses Jahr am Valentinstag, genauer: am 14.02.2009 um 12:31:30 exakt 1234567890 Sekunden seit dem 01.01.1970 vergangen.
Naja, wen’s interessiert. Ich war knapp zu spät, jetzt sinds bereits 1234954450 Sekunden… 
Parse error: syntax error, unexpected T_PAAMAYIM_NEKUDOTAYIM in[...]
Wtf..?!
Letzte Kommentare