pushManager.subscribe() returns broken subscription info |
|||||||||
Issue descriptionVersion: 52.0.2743.116 / 54.0.2831.0 canary OS: OS X What steps will reproduce the problem? (1) Call pushManager.subscribe() *without* providing an applicationServerKey. - A https://android.googleapis.com/gcm/send endpoint is returned in the subscription info. (2) Without unsubscribing, call pushManager.subscribe() *with* applicationServerKey. - A https://fcm.googleapis.com/fcm/send endpoint is returned in the subscription info. It does not appear to be possible to send messages to the client using these subscription details. What is the expected output? Messages can be sent to the client using the "upgraded" subscription details. The old subscription is either destroyed, or can be used in conjunction with the new one. What do you see instead? Messages cannot be sent to the client; the error is HTTP/1.1 400 UnauthorizedRegistration. (See below.) The old subscription can still be used. A few more notes: - If the initial subscribe() call includes applicationServerKey, the messages can be sent to the client. The problem only occurs when upgrading (or downgrading). - If the client unsubscribes between (1) and (2), the subscription information received in (2) can be used to send messages. - In Firefox, the pushManager.subscribe() of (2) fails with "A subscription with a different application server key already exists." - With this behavior, it seems the only way to upgrade a client (Chrome or FF) from a subscription initialized without applicationServerKey (GCM?) to one with is via periodic speculative unsubscribing and re-subscribing, which is inconvenient. $ echo -ne '\x40\x0c\x50\xc7\xbd\x1c\xeb\x41\xb6\x56\xfb\xd5\x5e\x33\xc1\x9b\x99\x53\xc4\x11\xc2\xaa\x1b\xc4\x72\x52\x54\xb6\x66\x7d' | curl -v -H 'Content-Type: application/octet-stream' -H 'Content-Encoding: aesgcm' -H 'Encryption: keyid=p256dh;salt=Za4cXS3x4Fu_v6Oc-YB6sA' -H 'Crypto-Key: keyid=p256dh;dh=BD6raYLqPC9nut4l4ZRJ9nScdH7aCtKbPaPKOidBrGnoMcbYQ2bKZblEQlfU1oVnS1JdWIVq4avs-wEp4nmf9Gk;p256ecdsa=BEWnbW1JD6mZjLNUWnoqB4kwCkISACYZ_Hpmn1awLYLT_j90Y_enfiC7cT7hUSRiNwLOYVrC4ro5QRcRYpEJ5iI' -H 'Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJFUzI1NiJ9.eyJhdWQiOiJodHRwczovL2ZjbS5nb29nbGVhcGlzLmNvbSIsImV4cCI6MTQ3MTYwOTkxNywic3ViIjoiaHR0cHM6Ly9naXRodWIuY29tL3dlYi1wdXNoLWxpYnMvd2ViLXB1c2gifQ.huCU0t0gRGgy0I-fVW_BU6qA5kxOxoncJqhKW7tHoIVTExAr9ZqNvw3ZtAptEHha5i0WJLGuYIwpLq_ZQfhpLA' -H 'TTL: 2419200' -H 'Content-Length: 30' 'https://fcm.googleapis.com/fcm/send/eMdyo2AM-Dc:APA91bGRu7cUM8XIKHKOYXlg7mOq9TGEbNF6C_wH6jTi0tzPe6T7rSpJIlcDKniu5vZnIqj9so_lQHCeschNkDnx2nuU2FdNWKnFOxK94WJNd5WiiuURe2v_vegecQSOLBMzVm5jdyJ8' --data-binary @- * Hostname was NOT found in DNS cache * Trying 2a00:1450:400c:c01::5f... * Connected to fcm.googleapis.com (2a00:1450:400c:c01::5f) port 443 (#0) * successfully set certificate verify locations: * CAfile: none CApath: /etc/ssl/certs * SSLv3, TLS handshake, Client hello (1): * SSLv3, TLS handshake, Server hello (2): * SSLv3, TLS handshake, CERT (11): * SSLv3, TLS handshake, Server key exchange (12): * SSLv3, TLS handshake, Server finished (14): * SSLv3, TLS handshake, Client key exchange (16): * SSLv3, TLS change cipher, Client hello (1): * SSLv3, TLS handshake, Finished (20): * SSLv3, TLS change cipher, Client hello (1): * SSLv3, TLS handshake, Finished (20): * SSL connection using ECDHE-RSA-AES128-GCM-SHA256 * Server certificate: * subject: C=US; ST=California; L=Mountain View; O=Google Inc; CN=*.googleapis.com * start date: 2016-08-10 18:12:00 GMT * expire date: 2016-11-02 18:12:00 GMT * subjectAltName: fcm.googleapis.com matched * issuer: C=US; O=Google Inc; CN=Google Internet Authority G2 * SSL certificate verify ok. > POST /fcm/send/eMdyo2AM-Dc:APA91bGRu7cUM8XIKHKOYXlg7mOq9TGEbNF6C_wH6jTi0tzPe6T7rSpJIlcDKniu5vZnIqj9so_lQHCeschNkDnx2nuU2FdNWKnFOxK94WJNd5WiiuURe2v_vegecQSOLBMzVm5jdyJ8 HTTP/1.1 > User-Agent: curl/7.35.0 > Host: fcm.googleapis.com > Accept: */* > Content-Type: application/octet-stream > Content-Encoding: aesgcm > Encryption: keyid=p256dh;salt=Za4cXS3x4Fu_v6Oc-YB6sA > Crypto-Key: keyid=p256dh;dh=BD6raYLqPC9nut4l4ZRJ9nScdH7aCtKbPaPKOidBrGnoMcbYQ2bKZblEQlfU1oVnS1JdWIVq4avs-wEp4nmf9Gk;p256ecdsa=BEWnbW1JD6mZjLNUWnoqB4kwCkISACYZ_Hpmn1awLYLT_j90Y_enfiC7cT7hUSRiNwLOYVrC4ro5QRcRYpEJ5iI > Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJFUzI1NiJ9.eyJhdWQiOiJodHRwczovL2ZjbS5nb29nbGVhcGlzLmNvbSIsImV4cCI6MTQ3MTYwOTkxNywic3ViIjoiaHR0cHM6Ly9naXRodWIuY29tL3dlYi1wdXNoLWxpYnMvd2ViLXB1c2gifQ.huCU0t0gRGgy0I-fVW_BU6qA5kxOxoncJqhKW7tHoIVTExAr9ZqNvw3ZtAptEHha5i0WJLGuYIwpLq_ZQfhpLA > TTL: 2419200 > Content-Length: 30 > * upload completely sent off: 30 out of 30 bytes < HTTP/1.1 400 UnauthorizedRegistration < Content-Type: text/html; charset=UTF-8 < Date: Thu, 18 Aug 2016 12:32:40 GMT < Expires: Thu, 18 Aug 2016 12:32:40 GMT < Cache-Control: private, max-age=0 < X-Content-Type-Options: nosniff < X-Frame-Options: SAMEORIGIN < X-XSS-Protection: 1; mode=block * Server GSE is not blacklisted < Server: GSE < Alternate-Protocol: 443:quic < Alt-Svc: quic=":443"; ma=2592000; v="35,34,33,32,31,30" < Accept-Ranges: none < Vary: Accept-Encoding < Transfer-Encoding: chunked < <HTML> <HEAD> <TITLE>UnauthorizedRegistration</TITLE> </HEAD> <BODY BGCOLOR="#FFFFFF" TEXT="#000000"> <H1>UnauthorizedRegistration</H1> <H2>Error 400</H2> </BODY> </HTML> * Connection #0 to host fcm.googleapis.com left intact
,
Aug 18 2016
The spec[1] matches Firefox's behavior: "If any attribute on allOptions contains a different value to that stored for subscription, then reject promise with an InvalidStateError and terminate these steps." We should probably update to match that. > With this behavior, it seems the only way to upgrade a client (Chrome or FF) > from a subscription initialized without applicationServerKey (GCM?) to one > with is via periodic speculative unsubscribing and re-subscribing, which is > inconvenient. Once Chrome matches the spec, it should be possible to catch the InvalidStateError and only unsubscribe in that case. From Chrome 54 a workaround will also be possible (thanks to issue 626627 ): pushManager.getSubscription().then(ps => { if (ps && ps.options && ps.options.applicationServerKey && ps.options.applicationServerKey != myApplicationServerKey) { // Need to unsubscribe before subscribing. } }); [1]: https://w3c.github.io/push-api/#widl-PushManager-subscribe-Promise-PushSubscription--PushSubscriptionOptionsInit-options
,
Aug 19 2016
,
Sep 16 2016
,
Oct 21 2016
,
Oct 21 2016
,
Oct 21 2016
,
Oct 25 2016
,
Nov 8 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/b9dabcc3e279cb499c74e7d7e57765af5c21d91e commit b9dabcc3e279cb499c74e7d7e57765af5c21d91e Author: awdf <awdf@chromium.org> Date: Tue Nov 08 20:04:02 2016 Disallow repeated PushManager.subscribes with different sender ids - Now we throw an InvalidStateError if you try to subscribe again with a different sender id without unsubscribing first (instead of confusingly returning the end point associated with the previous sender id). - This still allows resubscribing with no key if the first subscription used a numeric gcm sender id and the second subscription is from a service worker (see crbug.com/659230 ) BUG= 638924 Review-Url: https://codereview.chromium.org/2436393002 Cr-Commit-Position: refs/heads/master@{#430692} [modify] https://crrev.com/b9dabcc3e279cb499c74e7d7e57765af5c21d91e/chrome/browser/push_messaging/push_messaging_browsertest.cc [modify] https://crrev.com/b9dabcc3e279cb499c74e7d7e57765af5c21d91e/chrome/test/data/push_messaging/push_test.js [modify] https://crrev.com/b9dabcc3e279cb499c74e7d7e57765af5c21d91e/chrome/test/data/push_messaging/service_worker.js [modify] https://crrev.com/b9dabcc3e279cb499c74e7d7e57765af5c21d91e/content/browser/push_messaging/push_messaging_message_filter.cc [modify] https://crrev.com/b9dabcc3e279cb499c74e7d7e57765af5c21d91e/content/child/push_messaging/push_provider.cc [modify] https://crrev.com/b9dabcc3e279cb499c74e7d7e57765af5c21d91e/content/public/common/push_messaging_status.cc [modify] https://crrev.com/b9dabcc3e279cb499c74e7d7e57765af5c21d91e/content/public/common/push_messaging_status.h [add] https://crrev.com/b9dabcc3e279cb499c74e7d7e57765af5c21d91e/third_party/WebKit/LayoutTests/http/tests/push_messaging/subscribe-failure-mismatched-sender-id.html [modify] https://crrev.com/b9dabcc3e279cb499c74e7d7e57765af5c21d91e/third_party/WebKit/Source/modules/push_messaging/PushError.cpp [modify] https://crrev.com/b9dabcc3e279cb499c74e7d7e57765af5c21d91e/third_party/WebKit/public/platform/modules/push_messaging/WebPushError.h [modify] https://crrev.com/b9dabcc3e279cb499c74e7d7e57765af5c21d91e/tools/metrics/histograms/histograms.xml
,
Nov 9 2016
|
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 by stillers@google.com
, Aug 18 2016Something I forgot to note: in the case of a "broken" subscription id, nothing appears in chrome://gcm-internals. In all cases the subscription info appears reasonable. Case (1) (initial subscribe(), works): {"endpoint":"https://android.googleapis.com/gcm/send/fImZbojcS7A:APA91bGIn9P-MToQW6aHhFLpXu_xFjsaBEmx3evNqItRhnW6awR42vb2rrhJmsHCgorWg9Qo-J6lwazd7Wwbl0TUNbXZZ0AjL-qVByWJsBFDXQaUI5IYDo16wX3AK7e1SbqcNfAJBHTr","keys":{"p256dh":"BD2zeuWSADCQYhiIZBlRdau15GW6OQ7HZEUSB5aAvnb9WXxxTp-q6Q00yWGXNcazAcoSThZTxuQvNDi5BY7pEI8=","auth":"pSI19rrPM07Y48q6OolT8Q=="}} Case (2) (upgrade, broken): {"endpoint":"https://fcm.googleapis.com/fcm/send/fImZbojcS7A:APA91bGIn9P-MToQW6aHhFLpXu_xFjsaBEmx3evNqItRhnW6awR42vb2rrhJmsHCgorWg9Qo-J6lwazd7Wwbl0TUNbXZZ0AjL-qVByWJsBFDXQaUI5IYDo16wX3AK7e1SbqcNfAJBHTr","keys":{"p256dh":"BD2zeuWSADCQYhiIZBlRdau15GW6OQ7HZEUSB5aAvnb9WXxxTp-q6Q00yWGXNcazAcoSThZTxuQvNDi5BY7pEI8=","auth":"pSI19rrPM07Y48q6OolT8Q=="}} A working subscribe with applicationServerKey: {"endpoint":"https://fcm.googleapis.com/fcm/send/edevO-tfEmM:APA91bFdEZb70tvNn_wEcP7F1MudkwHuGTqbzKI3d5aUdxmDcOJ6BaS9WnXMXrCxsKUodjIKoYbGbh5UGRmNrrhoXbgHuJetDuO40D5ahpq0WomeNoKG9RulO8774X6ekLEoV8z2RNjC","keys":{"p256dh":"BP-zfIn80jQQ2HwweR8jx7SPkxrnx37HRpCeYC6j86B2Ir_EHnqomnaj_WHyBdpxO-rk2PX3W9i5PFKz6jKvAE8=","auth":"qiRawYQFuEAVTD8vkvMHYw=="}}