Skip to content

Front end configuration

Jump to bottom
Lahiru Jayakody edited this page Dec 2, 2016 · 2 revisions

1. Preparing client-side scripts

Open the project in IntelliJ IDEA.

Guide lines

  1. Browse front-end/keygen.html. Generate and note down the keys.

  2. Set const applicationServerPublicKey value
    in front-end/sw.js and front-end/main.js using generated server public key.

  3. Now your client-side scripts are ready to test on non-safari browsers.

  4. Open front-end/index.html in browser using any HTTP Server. You should be able to access to index.html from similar url as following.
    http://localhost:65124/browser-push/front-end/index.html
    DNS should be localhost. Otherwise, it should be https://
    Press Load script button then Enable Push Messaging. An input box will appear. Note down the JSON string from there as user subscription.

    This JSON object is called user subscription. In production environment, you should send this subscription to your backen-end and it should be persisted against some user identification. Later your back-end will use that user subscription objects to send push notifications to subscribed users. For demonstration purpose, you can copy it now and hard code in server code.

If you need to send notifications to Safari browser, following additional steps are needed.

  1. Create certificates (.p12 and .cer) and a website push id for your domain from Apple developer site. Refer Registering with Apple section in Configuring Safari Push Notifications article.

  2. Replace the var domain value in front-end/main.js with your website push id. It will look like web.com.example

    Then you need to setup a RESTful web service which will be called every time some Safari user is trying to subscribe for your webapp. Therefore, Safari push notification protocol needs 3 components to work together as following figure.

    Safari-handshake

    In above diagram, pink color box Returns push package needs to be done by our RESTful web service. Push package is a zip file which contains some files and it's hashes. Although Apple developer page instructs to build the Push package dynamically, in our implementation we will create it once and RESTful service will serve it as a static resource.

  3. Navigate to back-end/safari_push_package_creator/pushPackage.raw/.
    Modify the files as you needed. Please refer the Building the Push Package section in Configuring Safari Push Notifications article.

    If you are planing to add Safari push notification support to multiple domain names, specify those as "allowedDomains"
    in back-end/safari_push_package_creator/pushPackage.raw/website.json.
    Parameter "webServiceURL" specifies the path where the Safari RESTful service will be deployed at. authenticationToken will be not using to identify users in our implementation. So keep it as it is. Further, you can have your own iconset.

  4. Set $certificate_path, $certificate_password variables
    in back-end\safari_push_package_creator\index.php to match your .p12 certificate.

  5. Run that php file.

    

    6. 





php index.php




6. Then a push package for your webapp will be created at following path    
back-end/safari_webservice_backend/binaries/push-package.zip`
7. Now make the `push-api.war` by packaging project `safari_webservice_backend`.
    ```shell
> mvn package



    

  1. 

    Deploy the push-api.war file in Tomcat or other container. After the deployment, "webServiceURL" specified in website.json should matches the context path of deployed web application.
    
If everything works fine,
    

      

    • 
http://webServiceURL/v1/ should response with BAD REQUEST

      • 

    • 
http://pushPackages/v1/web.com.example should download zip file push-package.bin.
      • 

    

    2. 

  2. 

    Now you can test Safari push notifications using front-end/index.html.
    

    3. 

  3. 

    A confirmation box should be displayed when Load script button is clicked. Otherwise, check developer console outputs. If output is printed with deviceToken=null, this is a problem of your safari RESTful service or created push package. See push-api.war logs for troubleshooting.
    

    4. 

  4. 

    If everything works fine, input box with device a should be appeared. Note down it as Safari subscription. It is needed when sending notifications.
    

    

    In production environment, you should send this subscription to your backen-end and it should be persisted against some user identification. Later your back-end will use that user subscription objects to send push notifications to subscribed users. For demonstration purpose, you can copy it now and hard code in server code.
    

    

    5. 



References


If you encounter any problem with above guide lines, following resources from the original authors will be helpful.



              


          



  
          

            

              

                

                  

                    
Browser Push Github page


                  

                

              


            
Clone this wiki locally