किसी उपयोगकर्ता की सदस्यता लेना

सबसे पहले, उपयोगकर्ता से पुश मैसेज भेजने की अनुमति लें. इसके बाद, हम PushSubscription पर जाएं.

ऐसा करने के लिए JavaScript API का इस्तेमाल करना काफ़ी आसान है. इसलिए, लॉजिक फ़्लो के बारे में पूरी जानकारी लेते हैं.

सुविधा की पहचान करने की सुविधा

सबसे पहले हमें यह देखना होगा कि मौजूदा ब्राउज़र वाकई में पुश मैसेज की सुविधा देता है या नहीं. हम यह पता लगा सकते हैं कि पुश, दो आसान जांचों से काम करता है या नहीं.

  1. नेविगेटर पर serviceWorker को देखें.
  2. विंडो पर PushManager के बारे में जानकारी पाएं.
if (!('serviceWorker' in navigator)) {
  // Service Worker isn't supported on this browser, disable or hide UI.
  return;
}

if (!('PushManager' in window)) {
  // Push isn't supported on this browser, disable or hide UI.
  return;
}

सर्विस वर्कर और पुश मैसेज, दोनों के लिए ब्राउज़र सपोर्ट तेज़ी से बढ़ रहा है. इसलिए, बेहतर होगा कि आप इन दोनों सुविधाओं का पता लगाएं और इन्हें बेहतर तरीके से बेहतर बनाएं.

सर्विस वर्कर रजिस्टर करें

सुविधा के पता लगाने से हमें पता चलता है कि सर्विस वर्कर और पुश, दोनों काम करते हैं. अगला चरण है हमारे सर्विस वर्कर को "रजिस्टर करना".

किसी सर्विस वर्कर को रजिस्टर करके, हम ब्राउज़र को बताते हैं कि हमारी सर्विस वर्कर फ़ाइल कहां है. फ़ाइल अब भी सिर्फ़ JavaScript है, लेकिन ब्राउज़र इसे सर्विस वर्कर एपीआई को "ऐक्सेस देगा", जिसमें पुश शामिल है. ज़्यादा सटीक होने के लिए, ब्राउज़र फ़ाइल को सर्विस वर्कर एनवायरमेंट में चलाता है.

सर्विस वर्कर को रजिस्टर करने के लिए, navigator.serviceWorker.register() को कॉल करें और हमारी फ़ाइल के पाथ को पास करें. इसलिए:

function registerServiceWorker() {
  return navigator.serviceWorker
    .register('/service-worker.js')
    .then(function (registration) {
      console.log('Service worker successfully registered.');
      return registration;
    })
    .catch(function (err) {
      console.error('Unable to register service worker.', err);
    });
}

यह फ़ंक्शन ब्राउज़र को बताता है कि हमारे पास सर्विस वर्कर फ़ाइल है और वह कहां मौजूद है. इस मामले में, सर्विस वर्कर फ़ाइल /service-worker.js पर है. पर्दे के पीछे ब्राउज़र register() को कॉल करने के बाद नीचे दिए गए कदम उठाएंगे:

  1. सर्विस वर्कर फ़ाइल डाउनलोड करें.

  2. JavaScript चलाएं.

  3. अगर सब कुछ ठीक से काम करता है और कोई गड़बड़ी नहीं है, तो register() से मिला प्रॉमिस समाधान हो जाएगा. अगर किसी भी तरह की गड़बड़ियां होती हैं, तो प्रॉमिस अस्वीकार कर दिया जाएगा.

अगर register() अस्वीकार कर दिया जाता है, तो Chrome DevTools में टाइपिंग / गड़बड़ियों के लिए अपने JavaScript की दोबारा जांच करें.

जब register() ठीक हो जाता है, तो यह ServiceWorkerRegistration दिखाता है. हम इस रजिस्ट्रेशन का इस्तेमाल PushManager API को ऐक्सेस करने के लिए करेंगे.

PushManager API ब्राउज़र के साथ काम करता है

ब्राउज़र सहायता

  • 42
  • 17
  • 44
  • 16

सोर्स

अनुमति का अनुरोध किया जा रहा है

हमने अपने सर्विस वर्कर को रजिस्टर कर लिया है और उपयोगकर्ता की सदस्यता लेने के लिए तैयार हैं. अगला कदम उपयोगकर्ता से पुश मैसेज भेजने की अनुमति लेना है.

अनुमति पाने का एपीआई आम तौर पर आसान है. इसकी कमी यह है कि एपीआई में हाल ही में कॉलबैक लेने के बजाय, प्रॉमिस को वापस करने का तरीका बदला गया है. इसमें समस्या यह है कि हम यह नहीं बता सकते कि मौजूदा ब्राउज़र, एपीआई का कौनसा वर्शन लागू करता है. इसलिए, आपको दोनों वर्शन लागू करने होंगे और दोनों को मैनेज करना होगा.

function askPermission() {
  return new Promise(function (resolve, reject) {
    const permissionResult = Notification.requestPermission(function (result) {
      resolve(result);
    });

    if (permissionResult) {
      permissionResult.then(resolve, reject);
    }
  }).then(function (permissionResult) {
    if (permissionResult !== 'granted') {
      throw new Error("We weren't granted permission.");
    }
  });
}

ऊपर दिए गए कोड में, कोड का अहम स्निपेट, Notification.requestPermission() को कॉल है. इस तरीके से उपयोगकर्ता को एक अनुरोध दिखेगा:

डेस्कटॉप और मोबाइल Chrome पर अनुमति का संकेत.

जब उपयोगकर्ता, अनुमति दें, ब्लॉक करें या बस उसे बंद करके, अनुमति के अनुरोध से इंटरैक्ट करता है, तब हमें स्ट्रिंग के तौर पर नतीजा मिलता है: 'granted', 'default' या 'denied'.

ऊपर दिए गए सैंपल कोड में, अनुमति मिलने पर askPermission() से मिला प्रॉमिस इसका समाधान हो जाता है. ऐसा न होने पर, प्रॉमिस अस्वीकार करते समय गड़बड़ी होती है.

एक एज केस जिसे आपको हैंडल करने की ज़रूरत तब होती है जब उपयोगकर्ता 'ब्लॉक करें' बटन पर क्लिक करता है. अगर ऐसा होता है, तो आपका वेब ऐप्लिकेशन, उपयोगकर्ता से दोबारा अनुमति नहीं मांग पाएगा. उन्हें आपके ऐप्लिकेशन की अनुमति की स्थिति को बदलकर, सेटिंग पैनल में मौजूद ऐप्लिकेशन को मैन्युअल तरीके से "अनब्लॉक" करना होगा. इस बारे में ध्यान से सोचें कि आप लोगों से कब और कैसे अनुमति मांगते हैं, क्योंकि अगर वे 'ब्लॉक करें' पर क्लिक करते हैं, तो इस फ़ैसले को वापस लेना आसान नहीं होता.

अच्छी बात यह है कि ज़्यादातर उपयोगकर्ता अगर यह जानते हैं कि अनुमति क्यों मांगी जा रही है, तो उन्हें अनुमति देने में खुशी होती है.

हम यह देखेंगे कि कुछ लोकप्रिय साइटें बाद में अनुमति कैसे मांगती हैं.

PushManager की मदद से किसी उपयोगकर्ता की सदस्यता लेना

हमारे सर्विस वर्कर को रजिस्टर करने और अनुमति मिलने के बाद, हम registration.pushManager.subscribe() पर कॉल करके किसी उपयोगकर्ता की सदस्यता ले सकते हैं.

function subscribeUserToPush() {
  return navigator.serviceWorker
    .register('/service-worker.js')
    .then(function (registration) {
      const subscribeOptions = {
        userVisibleOnly: true,
        applicationServerKey: urlBase64ToUint8Array(
          'BEl62iUYgUivxIkv69yViEuiBIa-Ib9-SkvMeAtA3LFgDzkrxZJjSgSnfckjBJuBkr3qBUYIHBQFLXYp5Nksh8U',
        ),
      };

      return registration.pushManager.subscribe(subscribeOptions);
    })
    .then(function (pushSubscription) {
      console.log(
        'Received PushSubscription: ',
        JSON.stringify(pushSubscription),
      );
      return pushSubscription;
    });
}

subscribe() तरीके को कॉल करते समय, हम एक विकल्प ऑब्जेक्ट पास करते हैं. इसमें ज़रूरी और वैकल्पिक पैरामीटर, दोनों शामिल होते हैं.

आइए उन सभी विकल्पों पर नज़र डालते हैं जिन्हें हम अपना सकते हैं.

uservisibleOnly विकल्प

जब ब्राउज़र में पहली बार पुश नोटिफ़िकेशन जोड़ा गया था, तब यह तय नहीं हो पाया कि डेवलपर को पुश मैसेज भेजने और कोई सूचना न दिखाने की सुविधा दी जानी चाहिए या नहीं. आम तौर पर, इसे साइलेंट पुश के रूप में जाना जाता है, क्योंकि उपयोगकर्ता को यह पता नहीं चलता कि बैकग्राउंड में कुछ हुआ है.

चिंता यह थी कि डेवलपर, उपयोगकर्ता की जानकारी के बिना लगातार किसी उपयोगकर्ता की जगह की जानकारी को ट्रैक करने जैसी गलत गतिविधियां कर सकते थे.

इस स्थिति से बचने और खास लेखकों को इस सुविधा के साथ काम करने का बेहतर तरीका देने के लिए, userVisibleOnly विकल्प को जोड़ा गया और true की वैल्यू में पास करना, ब्राउज़र के साथ किया जाने वाला एक प्रतीक है. इसे वेब ऐप्लिकेशन पर हर बार पुश किए जाने पर एक सूचना दिखाई जाएगी (यानी कि कोई साइलेंट पुश नहीं होना चाहिए).

फ़िलहाल, आपको true की वैल्यू में पास होना ज़रूरी है. false में userVisibleOnly बटन या पास शामिल नहीं करने पर, आपको यह गड़बड़ी दिखेगी:

फ़िलहाल, Chrome में Push API का इस्तेमाल सिर्फ़ उन सदस्यताओं के लिए किया जा सकता है जिनसे उपयोगकर्ताओं को मैसेज मिलेंगे. इसके बजाय, pushManager.subscribe({userVisibleOnly: true}) को कॉल करके यह जानकारी दी जा सकती है. ज़्यादा जानकारी के लिए, https://goo.gl/yqv4Q4 पर जाएं.

फ़िलहाल, ऐसा लग रहा है कि Chrome में ब्लैंकेट साइलेंट पुश की सुविधा कभी लागू नहीं होगी. इसके बजाय, खास जानकारी देने वाले लेखक ऐसे बजट एपीआई के बारे में खोज रहे हैं जिससे वेब ऐप्लिकेशन को वेब ऐप्लिकेशन के इस्तेमाल के आधार पर कुछ संख्या में साइलेंट पुश मैसेज मिलेंगे.

ऐप्लिकेशनServerKey विकल्प

हमने पिछले सेक्शन में, "ऐप्लिकेशन सर्वर कुंजियां" के बारे में कम शब्दों में बताया है. "ऐप्लिकेशन सर्वर कुंजियों" का इस्तेमाल पुश सेवा, उपयोगकर्ता की सदस्यता लेने वाले ऐप्लिकेशन की पहचान करने के लिए करती है. साथ ही, यह पक्का करती है कि उस ऐप्लिकेशन से उपयोगकर्ता को मैसेज किया जा रहा हो.

ऐप्लिकेशन सर्वर कुंजियां, सार्वजनिक और निजी पासकोड का जोड़ा होता है. यह आपके ऐप्लिकेशन के लिए खास होता है. निजी कुंजी आपके ऐप्लिकेशन में गोपनीय होनी चाहिए और सार्वजनिक कुंजी को बेझिझक शेयर किया जा सकता है.

subscribe() कॉल में पास किया गया applicationServerKey विकल्प, ऐप्लिकेशन की सार्वजनिक कुंजी है. उपयोगकर्ता की सदस्यता लेते समय ब्राउज़र, इसे पुश सेवा पर भेजता है. इसका मतलब है कि पुश सेवा, आपके ऐप्लिकेशन की सार्वजनिक कुंजी को उपयोगकर्ता के PushSubscription से जोड़ सकती है.

नीचे दिए गए डायग्राम में ये चरण दिखाए गए हैं.

  1. आपका वेब ऐप्लिकेशन, ब्राउज़र में लोड होता है और आपने subscribe() को कॉल किया है. यह आपकी सार्वजनिक ऐप्लिकेशन सर्वर कुंजी को पास करता है.
  2. इसके बाद, ब्राउज़र किसी पुश सेवा को नेटवर्क अनुरोध भेजता है, जो एंडपॉइंट जनरेट करेगा. इसके बाद, इस एंडपॉइंट को ऐप्लिकेशन की सार्वजनिक कुंजी से जोड़ा जाएगा और एंडपॉइंट को ब्राउज़र को वापस भेज दिया जाएगा.
  3. ब्राउज़र इस एंडपॉइंट को PushSubscription से जोड़ देगा, जिसे subscribe() प्रॉमिस के ज़रिए दिखाया जाता है.

सार्वजनिक ऐप्लिकेशन सर्वर कुंजी का उदाहरण, सदस्यता लेने के तरीके में इस्तेमाल किया जाता है.

बाद में कोई पुश मैसेज भेजने के लिए, आपको एक ऑथराइज़ेशन हेडर बनाना होगा. इसमें आपके ऐप्लिकेशन सर्वर की निजी कुंजी से साइन की गई जानकारी होगी. जब पुश सेवा को पुश मैसेज भेजने का अनुरोध मिलता है, तब यह साइन किए गए अनुमति हेडर की पुष्टि कर सकती है. इसके लिए, उस एंडपॉइंट से लिंक की गई सार्वजनिक कुंजी देखी जा सकती है जिसे अनुरोध मिला हो. अगर सिग्नेचर मान्य है, तो पुश सेवा को यह पता चल जाता है कि उसे ऐप्लिकेशन सर्वर से, मिलती-जुलती निजी कुंजी के साथ मिला होना चाहिए. यह मूल रूप से एक सुरक्षा उपाय है, जो किसी अन्य व्यक्ति को ऐप्लिकेशन के उपयोगकर्ताओं को संदेश भेजने से रोकता है.

किसी संदेश को भेजते समय निजी ऐप्लिकेशन सर्वर कुंजी
का उपयोग कैसे किया जाता है

तकनीकी रूप से, applicationServerKey ज़रूरी नहीं है. हालांकि, Chrome पर सबसे आसानी से लागू करने के लिए ऐसा करना ज़रूरी है और अन्य ब्राउज़र में आने वाले समय में इसकी ज़रूरत पड़ सकती है. यह Firefox पर वैकल्पिक है.

ऐप्लिकेशन सर्वर कुंजी क्या होनी चाहिए, यह बताने वाला स्पेसिफ़िकेशन VAPID स्पेसिफ़िकेशन है. जब भी आप "ऐप्लिकेशन सर्वर कुंजियां" या "VAPID कुंजियां" के बारे में कुछ पढ़ें, तो बस याद रखें कि ये एक ही चीज़ हैं.

ऐप्लिकेशन सर्वर कुंजियां बनाने का तरीका

web-push-codelab.glitch.me पर जाकर ऐप्लिकेशन सर्वर कुंजियों का सार्वजनिक और निजी सेट बनाया जा सकता है या ये काम करके कुंजियां जनरेट करने के लिए वेब-पुश कमांड लाइन का इस्तेमाल किया जा सकता है:

    $ npm install -g web-push
    $ web-push generate-vapid-keys

आपको अपने ऐप्लिकेशन के लिए इन कुंजियों को सिर्फ़ एक बार बनाना होगा, बस निजी कुंजी को निजी रखना न भूलें. (हां, मैंने यही कहा था.)

अनुमतियां और Subscribe()

subscribe() को कॉल करने का एक ही असर है. अगर आपके वेब ऐप्लिकेशन के पास subscribe() को कॉल करते समय सूचनाएं दिखाने की अनुमति नहीं है, तो ब्राउज़र आपके लिए अनुमतियों का अनुरोध करेगा. यह तब काम आता है, जब आपका यूज़र इंटरफ़ेस (यूआई) इस फ़्लो के साथ काम करता हो. हालांकि, अगर आपको ज़्यादा कंट्रोल चाहिए (और मुझे लगता है कि ज़्यादातर डेवलपर ऐसा करेंगे), तो उस Notification.requestPermission() API का इस्तेमाल करें जिसे हमने पहले इस्तेमाल किया था.

Pushसदस्यता क्या है?

हम subscribe() को कॉल करते हैं, कुछ विकल्प पास करते हैं, और बदले में हमें एक प्रॉमिस मिलता है जो PushSubscription में बदल जाता है, जिसके नतीजे में कुछ इस तरह का कोड होता है:

function subscribeUserToPush() {
  return navigator.serviceWorker
    .register('/service-worker.js')
    .then(function (registration) {
      const subscribeOptions = {
        userVisibleOnly: true,
        applicationServerKey: urlBase64ToUint8Array(
          'BEl62iUYgUivxIkv69yViEuiBIa-Ib9-SkvMeAtA3LFgDzkrxZJjSgSnfckjBJuBkr3qBUYIHBQFLXYp5Nksh8U',
        ),
      };

      return registration.pushManager.subscribe(subscribeOptions);
    })
    .then(function (pushSubscription) {
      console.log(
        'Received PushSubscription: ',
        JSON.stringify(pushSubscription),
      );
      return pushSubscription;
    });
}

PushSubscription ऑब्जेक्ट में वह सारी ज़रूरी जानकारी मौजूद होती है जो उस उपयोगकर्ता को पुश मैसेज भेजने के लिए ज़रूरी है. अगर JSON.stringify() का इस्तेमाल करके कॉन्टेंट प्रिंट किया जाता है, तो आपको ये चीज़ें दिखेंगी:

    {
      "endpoint": "https://some.pushservice.com/something-unique",
      "keys": {
        "p256dh":
    "BIPUL12DLfytvTajnryr2PRdAgXS3HGKiLqndGcJGabyhHheJYlNGCeXl1dn18gSJ1WAkAPIxr4gK0_dQds4yiI=",
        "auth":"FPssNDTKnInHVndSTdbKFw=="
      }
    }

endpoint, पुश सेवाओं का यूआरएल है. कोई पुश मैसेज ट्रिगर करने के लिए, इस यूआरएल पर पोस्ट करने का अनुरोध करें.

keys ऑब्जेक्ट में, वे वैल्यू शामिल होती हैं जिनका इस्तेमाल, पुश मैसेज की मदद से भेजे गए मैसेज डेटा को एन्क्रिप्ट (सुरक्षित) करने के लिए किया जाता है. इसके बारे में हम इस सेक्शन में बाद में चर्चा करेंगे.

अपने सर्वर पर सदस्यता भेजना

पुश सदस्यता मिलने के बाद, उसे अपने सर्वर पर भेजा जा सकता है. यह आपको तय करना होता है कि इसे कैसे किया जाए, लेकिन एक छोटी सी सलाह यह है कि आप JSON.stringify() का इस्तेमाल करके, सदस्यता ऑब्जेक्ट से सभी ज़रूरी डेटा बाहर निकालें. इसके अलावा, एक ही नतीजे को मैन्युअल तौर पर एक साथ जोड़ा जा सकता है, जैसे:

const subscriptionObject = {
  endpoint: pushSubscription.endpoint,
  keys: {
    p256dh: pushSubscription.getKeys('p256dh'),
    auth: pushSubscription.getKeys('auth'),
  },
};

// The above is the same output as:

const subscriptionObjectToo = JSON.stringify(pushSubscription);

वेब पेज पर, सदस्यता भेजने का काम इस तरह से किया जाता है:

function sendSubscriptionToBackEnd(subscription) {
  return fetch('/api/save-subscription/', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
    },
    body: JSON.stringify(subscription),
  })
    .then(function (response) {
      if (!response.ok) {
        throw new Error('Bad status code from server.');
      }

      return response.json();
    })
    .then(function (responseData) {
      if (!(responseData.data && responseData.data.success)) {
        throw new Error('Bad response from server.');
      }
    });
}

नोड सर्वर को यह अनुरोध मिलता है और वह डेटा को बाद में इस्तेमाल करने के लिए, डेटाबेस में सेव करता है.

app.post('/api/save-subscription/', function (req, res) {
  if (!isValidSaveRequest(req, res)) {
    return;
  }

  return saveSubscriptionToDatabase(req.body)
    .then(function (subscriptionId) {
      res.setHeader('Content-Type', 'application/json');
      res.send(JSON.stringify({data: {success: true}}));
    })
    .catch(function (err) {
      res.status(500);
      res.setHeader('Content-Type', 'application/json');
      res.send(
        JSON.stringify({
          error: {
            id: 'unable-to-save-subscription',
            message:
              'The subscription was received but we were unable to save it to our database.',
          },
        }),
      );
    });
});

हमारे सर्वर पर PushSubscription की जानकारी होने से, जब भी हम चाहें, उपयोगकर्ता को मैसेज भेज सकते हैं.

अक्सर पूछे जाने वाले सवाल

यहां कुछ सामान्य सवाल हैं जिन्हें लोग अक्सर पूछते हैं:

क्या ब्राउज़र में इस्तेमाल की जाने वाली पुश सेवा को बदला जा सकता है?

नहीं. पुश सेवा, ब्राउज़र चुनता है और जैसा कि हमें subscribe() कॉल के दौरान दिखा. इस तरह, ब्राउज़र पुश सेवा को नेटवर्क अनुरोध भेजेगा, ताकि PushSubscription से मिली जानकारी की जानकारी मिल सके.

हर ब्राउज़र एक अलग पुश सेवा का इस्तेमाल करता है, क्या उनके पास अलग-अलग एपीआई नहीं हैं?

सभी पुश सेवाएं एक ही एपीआई की उम्मीद करेंगी.

इस सामान्य एपीआई को वेब पुश प्रोटोकॉल कहा जाता है. यह एपीआई, नेटवर्क के उस अनुरोध के बारे में बताता है जो आपके ऐप्लिकेशन को पुश मैसेज ट्रिगर करने के लिए करना होगा.

अगर मैंने किसी दर्शक के डेस्कटॉप पर सदस्यता ली है, तो क्या वह अपने फ़ोन से भी सदस्यता लेगा?

माफ़ करें, ऐसा नहीं है. उपयोगकर्ता को हर उस ब्राउज़र पर पुश के लिए रजिस्टर करना होगा जिस पर वह मैसेज पाना चाहता है. यह भी ध्यान देने वाली बात है कि इसके लिए हर डिवाइस पर अनुमति देने वाले उपयोगकर्ता की ज़रूरत होगी.

आगे कहां जाना है

कोड लैब