Push Nachricht per PHP versenden - komisches Verhalten bei Dev Tokens

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Push Nachricht per PHP versenden - komisches Verhalten bei Dev Tokens

    Hallo zusammen,

    ich versuche per PHP Push Nachrichten zu versenden. Das funktioniert soweit auch ohne Probleme. Mich macht nur eine Sache stutzig. Bisher war es so das wenn ich eine Push Nachricht mit einem Produktiven Zertifikat an einen Device Token der von einem Testgerät schicke, dann bricht die SSL Verbindung direkt ab. Soweit so gut. Bei folgendem Code Beispiel bricht der aber in dem Fall nicht ab. Ideen warum?

    Code:

    PHP-Quellcode

    1. if ($open == false) {
    2. $streamContext = stream_context_create();
    3. stream_context_set_option($streamContext, 'ssl', 'local_cert', WWW_ROOT . 'files/certificates/' . $certificate);
    4. stream_context_set_option($streamContext, 'ssl', 'passphrase', $passphrase);
    5. $fp = stream_socket_client(
    6. NotificationsController::$_ENVIROMENTS[$enviroment],
    7. $errorNumber,
    8. $errorString,
    9. 60,
    10. STREAM_CLIENT_CONNECT,
    11. $streamContext);
    12. if ($errorString) {
    13. $open = false;
    14. break;
    15. }
    16. else {
    17. $open = true;
    18. }
    19. }
    20. if (!fwrite($fp, $payload)) {
    21. $status[$ids[$counter]] = '1';
    22. $buffer=fgets($fp);
    23. if($buffer) {
    24. $text=unpack("c2chars/Nint",$buffer);
    25. if($text['chars1'] == 8) {
    26. $open = false;
    27. $status[$ids[$counter]] = '8';
    28. fclose($fp);
    29. }
    30. }
    31. }
    32. else {
    33. $status[$ids[$counter]] = '0';
    34. }
    Alles anzeigen


    Schicke ich an einen Dev Token eine produktive Nachricht gibt fwrite trotzdem ein true zurück. Warum?

    Und die Variablen Passphrase, Certificate,... sind alle korrekt gefüllt.

    Gruß Tuni
  • fwrite gibt die Anzahl der geschriebenen Bytes (int) zurück und kein bool. Daraus kann man maximal erkennen, das eine Nachricht erfolgreich versendet wurde. Ist also kein Feedback von apple.
    Ich vermute mal, wenn Du apple über das Gateway ein "Hello World" sendest, erhälst Du auch ein True (int: 11) zurück. Ob Apple aber was mit der Nachricht anfangen kann ist eine andere Sache.

    produktive Nachricht: damit meint er wahrscheinlich. (Produktionsserver/echte app/apple gateway/produktive Nachricht) - (Testserver,DevApp/sandbox gateway/debug Nachricht)
    (äh. sehe gerade er schickt mit einem Dev token eine "produktive Nachricht"... ok. ist doch unklar. )

    Was meinst Du überhaupt mit abbrechen? ein gewolltes "close"?
    ich würde übrigens den gleichen Code für Dev/Produktiv App verwenden, ansonsten pflegst Du das ganze ja zweimal.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von margroth ()

  • Ja habe ich gerade auch entdeckt als ich mir den Code und die Apple Doku nochmals in Ruhe angeguckt habe. Habe das völlig falsch verstanden wie das genau ablaufen soll... Bloß mich verwundert eben das er nach dem 1. ungültigen Token weiterschreibt und keine Fehler zurückgibt. Sollte die Verbindung dann nicht geschlossen werden und fwrite auf einen Fehlr laufen? Also wenn ich ein produktive Nachricht an einen Sandbox Token schicke sollte es doch den Fehler 8 geben und die SSL Verbindung dürfte geschlossen werden.

    Produktive Nachricht geht an ssl://gateway.push.apple.com:2195, die Sandbox Nachricht an ssl://gateway.sandbox.push.apple.com:2195

    Ich nutze doch jeweils den gleichen Code. Hinter dem Skript oben steckt ein ganzes Portal welches die Push Verwaltung für dutzende Apps nutzt. Alle versenden über das Skript.

    Edit: Fehlercodes habe ich von hier:

    developer.apple.com/library/ma…/uid/TP40008194-CH101-SW1

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Tuni ()

  • so. noch mal schnell.

    ich verstehe dich nicht ganz. Du meinst vermutlich, dass Du an dein Testapp mit einem produktiv Zertifikat eine "echte Nachricht" versendest und Dich wunderst, warum das geht?

    Hast Du verstanden, was ich oben meine? fwrite schreibt nur. Egal was. Das überprüfen der Zertifikate passiert schon beim Öffnen des Streams. Ist dieser offen, kannst Du schreiben was Du willst.
    Ob das dann von apple verstanden wird ist eine andere Sache.
    Selbst wenn Du sinnvolle Sachen schreibst (nur mit falschem, nicht vorhandenen Token), wird fwrite Dir niemals ein Feedback von apple zurückgeben. übrigens glaube ich, dass apple Dir auch beim nachfolgenden fputs Dir keine Tokenfehlermeldung (nach dem Motto: Token existiert nicht) ausgeben würde.... oh. sorry. da lag ich falsch.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von margroth ()

  • Nein. Ich habe hier 2 Geräte liegen auf denen die Testapp lief. In Xcode kompiliert und auf dem Gerät getestet. Push Token im System eingetragen und an die beiden Geräte Nachrichten geschickt. => funktioniert

    Danach die App in den Store gestellt. App wurde geprüft, alles super. Die App aus dem Store auf einem anderen iPhone installiert und auf das eine Nachricht (mit dem Produktiven Zertifikat) geschickt. => funktioniert

    Soweit alles klar und auch richtig. Nun sollte es aber so sein, dass wenn ich eine Nachricht mit dem produktiven Zertifikat mit einem der beiden Tokens von den Testgeräten verschicke Apple mir einen Fehler auswirft (Code 8 ) und die SSL Verbindung dicht macht. Oder habe ich das falsch verstanden?

    Weil die Tokens zwischen Debug und Release Modus der App sind soweit ich weiß unterschiedlich, daher hat man dann für die Testversion (Debug) und die Produktive Version für den Store (Release) unterschiede.
  • Leider ist es so, dass nach einem ungültigen Token zwar abgebrochen wird aber leider bekommst du das nicht sofort mit. Der Stream bricht erst irgendwann später zusammen. Deshalb habe ich mein Tutorial damals erweitert um ein php Script das genau diesen Fall abfängt. Mit der einfachen Methode bekommst du übrigens überhaupt keinen Fehler mit. Das geht nur mit der erweiterten. Das hat mich damals auch viel Nerven gekostet.

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)
  • Tuni schrieb:

    Soweit alles klar und auch richtig. Nun sollte es aber so sein, dass wenn ich eine Nachricht mit dem produktiven Zertifikat mit einem der beiden Tokens von den Testgeräten verschicke Apple mir einen Fehler auswirft (Code 8 ) und die SSL Verbindung dicht macht. Oder habe ich das falsch verstanden?
    Du beziehst Dich wahrscheinlich auf
    APNs may consider connections that are rapidly and repeatedly established and torn down as a denial-of-service attack. Upon error, APNs closes the connection on which the error occurred.
    Ich glaube, damit meint apple eher "technische Probleme", wenn dein Script versucht 1000 mal einen Stream zu öffnen (für jeden Token)... oder ähnliche Probleme.
    Und nicht, wenn mal ein token "invalid"ist. Das kann ja bei tausenden Tokens häufig der Fall sein.... da willst Du ja nicht immer wieder einen Stream öffnen wollen... und apple möchte das auch nicht.
    Innerhalb der Versendung der Tokens bleibt der Stream offen. Kannst Du ja auch bei den Devs testen. Einfach 3 erfinden und der vierte ist echt. die Nachricht an den vierten Token wird ankommen.

    Aber das muss noch mal ein alter Hase bestätigen.

    @Thallius: Hmm. Bist Du Dir sicher, das der abbruch deines Streams nicht an was anderem lag? maximale Laufzeitlänge PHP-Script oder so?
    Wenn die Verbindung von apple tatsächlich nach einem solchen Error unterbrochen wird, geht sofort danach nichts mehr, denn würde sofort fwrite nicht mehr funktionieren. Oder?
  • Ganz sicher. Habe ich nämlich lange nach gesucht. Ich hatte die Dev-Tokens meiner Beta-Tester, welche sich mit der Develper Version registriert hatten, nicht aus der DB genommen. Diese Tokens waren mit der Distribution nicht mehr gültig und haben immer zu einem zusammenbruch des Streams geführt. War absolut reproduzierbar. Warum das so ist weiß ich auch nicht

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)