Skip to content

Set up web push on a custom HTTPS subdomain

Jump to bottom Edit New page
Jason Pang edited this page Mar 16, 2017 · 3 revisions

Introduction

Web push is not supported on insecure non-HTTPS sites. As a workaround, we and other push providers simulate web push on HTTP sites by opening a popup to a subdomain of our own secure site (e.g. https://subdomain.onesignal.com).

Users are then subscribing to https://subdomain.onesignal.com, and not subscribing to the parent HTTP site itself. This is why notifications from HTTP sites are displayed as being from subdomain.onesignal.com; the notification is really from the subdomain of our site and the HTTP site itself isn't part of any of this.

You'd like to do something similar, except using your-custom-subdomain.yoursite.com.

This guide will walk you through how.

Points to Know

  • OneSignal will not be used on yoursite.com

  • OneSignal will only be used on your-custom-subdomain.yoursite.com

  • You should open a popup to your-custom-subdomain.yoursite.com to subscribe users

  • You should also keep an iFrame open from yoursite.com --> to your-custom-subdomain.yoursite.com to interact with the OneSignal integration present only on your-custom-subdomain.yoursite.com

    This is to know whether the user is subscribed or not, and to perform other SDK operations. You will need to perform cross-domain messaging to the iFrame pointing to your-custom-subdomain.onesignal.com. An iFrame is required, because only same-origin pages are allowed to read data stored on the origin's IndexedDB database (due to the same-origin policy), and the iFrame post-messages this data back to the host page.

Online Demo

You will need to implement both components. This is a working open-source demo.

Open Source At:

Technical Implementation

Note 1: When in doubt, look at the source code of our demo.

Note 2: Be sure to substitute critical values like appId with your own app ID. Also make sure step #2 has been completed before moving on to step #3 so that a manifest.json file exists.

Note 3: Please don't skip step 6. It ensures that the web SDK your users use will always be up to date. Important bug fixes get made, so be sure to do step #6!

  1. Choose a subdomain to subscribe users on (e.g. https://push.yoursite.com). Create a blank (for now) subscription page like https://push.yoursite.com/subscribe where users will be redirected to in the HTTP subscription popup. Create another blank page (just for now) like https://push.yoursite.com/iframe to be used later for the iframe you'll place on each of your sites.

    What you've made: A subdomain to subscribe users on, and two blank pages to be used later on in this guide (e.g. /subscribe and /iframe).

  2. Follow our HTTPS web push setup guide for https://push.yoursite.com/subscribe. You should be able to subscribe yourself on https://push.yoursite.com/subscribe for now, just to know your initial integration is correct. The way users subscribe will be modified further down this guide, since users from each of your sites share the same subscription on https://push.yoursite.com/subscribe, and we have to differentiate users coming from a.com, b.com, and c.com.

    Note that for new apps you're creating, do not obtain your own web push keys from Google. Use our shared keys.

    What you've made: A working https://push.yoursite.com/subscribe page that can subscribe visitors to push notifications. This isn't our final page yet though! A lot of modifications need to be made to this page.

  3. For https://push.yoursite.com/iframe.html, see the starter code for our demo iframe.html.

    What you've made: An iframe that can accept queries from the host page for the user's subscription state, OneSignal ID, and stored tags.

  4. On yoursite.com, create a hidden iFrame pointing to push.yoursite.com/iframe.html. see the starter code for our demo iframe-init.js.

    What you've made: Some code on the host page that can open the popup for subscribing users.

  5. For https://push.yoursite.com/subscribe.html, see the starter code for our demo subscribe.html.

  6. Push notifications are subscribed to and displayed via a new browser feature called service workers. These are basically background workers that can still run code even when your site isn't running (and it's how notifications are displayed when your site isn't open). Service workers are a JavaScript file of regular JavaScript code (with special APIs).

    Our web SDK automatically registers a service worker when users subscribe in the popup.

    Due to your special integration case, you'll have to make it such that, if a browser requests https://push.yoursite.com/OneSignalSDKWorker.js or https://push.yoursite.com/OneSignalSDKUpdaterWorker.js, return the same importScripts('...') string with a random query parameter.

    The browser will automatically check this endpoint every 24 hours and automatically update our worker if there's a change. This is important so that visitors are always using our latest web SDK! We're making major improvements in the way users receive notifications in the next few weeks, and we continue to release bug fixes for existing issues.

    For example, if I were to request https://push.yoursite.com/OneSignalSDKUpdaterWorker.js 5 times, your server might return:

    importScripts('https://cdn.onesignal.com/sdks/OneSignalSDK.js?v=1');
importScripts('https://cdn.onesignal.com/sdks/OneSignalSDK.js?v=2');
importScripts('https://cdn.onesignal.com/sdks/OneSignalSDK.js?v=3');
importScripts('https://cdn.onesignal.com/sdks/OneSignalSDK.js?v=4');
importScripts('https://cdn.onesignal.com/sdks/OneSignalSDK.js?v=5');

    As long as a different query parameter is returned (random or incrementing string), the service worker should be able to update itself.

Add a custom footer
Add a custom sidebar
Clone this wiki locally