2013-04-30 12 views
8

Ich versuche, einige mp3-Dateien über den html5 Audio-Tag zu spielen. Für den Desktop funktioniert das super (mit Chrome), aber wenn es um die mobilen Browser geht (auch Chrome (für Android)), scheint es einige Schwierigkeiten zu geben:Senden Mobile Browser httpOnly Cookies über den HTML5 Audio-Tag?

Ich habe den Stream mit etwas Passwort geschützt und daher das Streaming Der Server muss einen speziellen Authentifizierungs-Cookie finden (Federsicherung remember-me). Aber irgendwie sendet der mobile Browser diesen Cookie nicht, wenn er über das Audio-Tag auf den mp3-Stream zugreift. Wenn ich die Stream-URL direkt in die Adresszeile eingebe, funktioniert alles einwandfrei.

Während ich nach dem verlorenen Cookie suchte, fand ich heraus, dass der mobile Browser immer noch einige Cookies (z. B. die JSESSIONID) sendet, aber nicht alle. Weitere Untersuchungen (schnelles PoC mit PHP) ergaben, dass sich die mobilen Browser anscheinend weigern, Cookies über das Audio-Tag zu senden, auf dem das HttpOnly-Flag gesetzt ist. Also meine Frage ist:

Ist dies ein bestimmtes Verhalten, warum gibt es Unterschiede zwischen den mobilen und den Desktop-Versionen (von Chrome) und gibt es eine Möglichkeit, das Verhalten von der Client-Seite zu kontrollieren?

Antwort

10

Bei näherer Betrachtung der HTTP-Pakete habe ich festgestellt, dass der Android-Browser den mp3-Stream selbst nicht anfordert, sondern dies an stagefright (einige Android-Multimedia-Clients) delegiert. Eine schnelle Suche ergab, dass für die alten Android-Versionen (vor 4.0) stagefright können keine Cookies behandeln:

Meine eigenen Tests haben dies bestätigt. Der alte Lampenfieber (Android 2.3.x) sendet überhaupt keine Cookies, der Lampenfieber von einem europäischen S3 (Android 4.1.2, Lampenfieber 1.2) sendet nur die Cookies, die NICHT das httpOnly Flag haben.

Ich denke also, dass jeder selbst entscheiden muss, welche Lösung er verwenden möchte:

  • ermöglichen Httponly: Android überhaupt keinen Zugriff hat, aber seine sichere
  • deaktivieren Httponly: weniger sicher gegen XSS, aber arbeitet für Android> 4.0
  • deaktivieren Cookie-Authentifizierung überhaupt: unsicher, funktioniert aber für alle

Hinweis: das Problem mit einfach Httponly zu deaktivieren ist, dass Sie Ihre wh machen ole Anwendung anfällig für Cookie-Hijacker. Eine andere mögliche Lösung wäre ein spezielles Erinnerungs-Cookie für den Stream (ohne httpOnly) und ein weiteres rememberme-Cookie mit httpOnly, das aktiviert ist.

+0

Dieses Problem wurde an Android gemeldet: https://code.google.com/p/android/issues/detail?id=17553, obwohl es als "Spam" markiert wurde. Ich kann das Problem erneut öffnen, da ich die Spam-Lösung nicht verstehe. –

+0

Weitere zu beachtende Probleme: https://code.google.com/p/android/issues/detail?id=66050, https://code.google.com/p/chromium/issues/detail?id=163796 –

+0

Wahrscheinlich das gleiche Problem beim Einbetten/Streaming von Videos mit PHP und Cookie/Session-Authentifizierung, siehe http://stackoverflow.com/q/32181185/1066234 –

0

Ich hatte das gleiche Problem und deaktivieren HttpOnly oder Secure Flags auf Cookies löste das Problem auf Android 4.2 und 4.4 Chrome-Browser nicht.

Endlich dachte ich über die Ursache nach. Ich hatte einen Cookie mit dem Wert, der die Sonderzeichen Doppelpunkt (:) und Pipe (|) enthielt. Nachdem das Cookie mit Sonderzeichen deaktiviert wurde, werden die Videos in Android 4.2 und 4.4 wiedergegeben.

Ich hoffe, das hilft jemandem.

Verwandte Themen