[aerogear-dev] Firefox Push API with UnifiedPush Server

Wed Jul 27 20:13:22 EDT 2016

I've improved WebPushNotificationSender. Now it can send push notifications
to both push notification providers: FCM and MPS. See the last commit in
this PR [1].

I also updated a demo web app for Push API [2]. Everything works perfect in
Chrome and Firefox with UPS and WebPush Variant :)

[1] https://github.com/aerogear/aerogear-unifiedpush-server/pull/745
[2] https://github.com/aerogear/aerogear-js-cookbook/pull/15

Best regards,
Idel Pivnitskiy
--
Twitter: @idelpivnitskiy <https://twitter.com/idelpivnitskiy>
GitHub: @idelpivnitskiy <https://github.com/idelpivnitskiy>

On Tue, Jul 26, 2016 at 1:48 PM, Idel Pivnitskiy <idel.pivnitskiy at gmail.com>
wrote:

> Can't we just name the variant a "WebPush", with a special field for the
>> user to provide info, WHAT provider will be used? e.g. on that WebPush
>> Variant; TYPE: Firefox ?
>
>
> Provider should be defined for each Installation (device/client/endpoint),
> not for the whole Variant.
>
> Best regards,
> Idel Pivnitskiy
> --
> Twitter: @idelpivnitskiy <https://twitter.com/idelpivnitskiy>
> GitHub: @idelpivnitskiy <https://github.com/idelpivnitskiy>
>
> On Tue, Jul 26, 2016 at 1:16 PM, Matthias Wessendorf <matzew at apache.org>
> wrote:
>
>> Can't we just name the variant a "WebPush", with a special field for the
>> user to provide info, WHAT provider will be used? e.g. on that WebPush
>> Variant; TYPE: Firefox ?
>>
>> On Tue, Jul 26, 2016 at 12:15 AM, Idel Pivnitskiy <
>> idel.pivnitskiy at gmail.com> wrote:
>>
>>> I've sent a separate PR with renamed Firefox Variant to Webpush Variant
>>> [1]. Will try to make it workable with Google Chrome and FCM too tomorrow.
>>>
>>> [1] https://github.com/aerogear/aerogear-unifiedpush-server/pull/745
>>>
>>> Best regards,
>>> Idel Pivnitskiy
>>> --
>>> Twitter: @idelpivnitskiy <https://twitter.com/idelpivnitskiy>
>>> GitHub: @idelpivnitskiy <https://github.com/idelpivnitskiy>
>>>
>>> On Mon, Jul 25, 2016 at 5:21 PM, Idel Pivnitskiy <
>>> idel.pivnitskiy at gmail.com> wrote:
>>>
>>>> It's a bit early to talk about Safari, because it has not implemented
>>>> Push API, Service Worker API and push message encryption yet. And no
>>>> information about their plans to do this. Currently Apple uses their own
>>>> protocol for push notifications. I've asked my friend to register a test
>>>> app from his Apple developer's account for me, and I'm going to test how it
>>>> will work now, with APNs Variant.
>>>>
>>>> Here is info, that Microsoft started development of Push API for Edge
>>>> [1].
>>>>
>>>> I decided to create a variant for Firefox just because variant saves
>>>> authentication tokens for push service provider and later uses it's own
>>>> notification sender for a specific push service provider. And I started to
>>>> work on this, when here was no info that Chrome supports PushMessageData
>>>> and push message encryption. But now it may be reasonable to create a
>>>> WebPush variant. Or wait Push API in Edge and decide how to move forward
>>>> after the third player in the game.
>>>>
>>>> If we will create WebPush variant the advantages are:
>>>>
>>>>    1. User have to create just one variant
>>>>    2. Unique extended Installation entity with "auth secret" and
>>>>    "public key" from the browser.
>>>>
>>>> but disadvantages are:
>>>>
>>>>    1. Required registration on each push notification provider: FCM,
>>>>    MPS, etc. (but advantage that the user will not forgot something)
>>>>    2. Determine browser on client side, store it in Installation
>>>>    during registration of device and make decision which push notification
>>>>    provider should be chosen before sending each message.
>>>>
>>>> If we will create variant for each push notification provider the
>>>> advantages are:
>>>>
>>>>    1. Keep our rule, that each variant has it's own push message
>>>>    provider and auth information.
>>>>
>>>> but disadvantages are:
>>>>
>>>>    1. Determine browser on client side and choose appropriate variant
>>>>    secret.
>>>>    2. For FCM make decision about should we encrypt the message before
>>>>    sent (if the client is Chrome) or not.
>>>>
>>>> Also here is a chance, that FCM, MPS and others will implement totally
>>>> identical push services, according to the specification [2], with
>>>> acknowledgment, receipts, HTTP/2, etc. So it may be reasonable to focus on
>>>> one WebPush variant. It will not be a problem for me to rename Firefox to
>>>> WebPush now. I can open a separate PR this evening.
>>>>
>>>> Any thoughts?
>>>>
>>>> [1]
>>>> https://developer.microsoft.com/en-us/microsoft-edge/platform/status/pushapi
>>>> [2] https://tools.ietf.org/html/draft-ietf-webpush-protocol
>>>>
>>>> Best regards,
>>>> Idel Pivnitskiy
>>>> --
>>>> Twitter: @idelpivnitskiy <https://twitter.com/idelpivnitskiy>
>>>> GitHub: @idelpivnitskiy <https://github.com/idelpivnitskiy>
>>>>
>>>> On Mon, Jul 25, 2016 at 4:25 PM, Luke Holmquist <lholmqui at redhat.com>
>>>> wrote:
>>>>
>>>>> I'm tempted to say that there should be a "WebPush" variant instead
>>>>> which could be chrome/ff/safari, but i think chrome and safari are to
>>>>> closely related to Android/iOS atm that it wouldn't make sense.
>>>>>
>>>>> Somewhat related to this is the JS SDK for the ups and how it works
>>>>> for push on the web.  It was initially created to just handle registering
>>>>> SimplePush clients, since there was no browsers doing push.  Then Safari
>>>>> introduced push, then chrome and FF.   with regards to the UPS, these are 3
>>>>> different variants,  so to create 1 app that handles all three you would
>>>>> need to make sure to register 3 "clients" in the js sdk.  I don't know if
>>>>> there is anyway we can help the user out with this. Safari is different
>>>>> enough that it would be easy for the user, but there is no real difference
>>>>> between the registration code in FF and chrome.(perhaps these 2 should be
>>>>> the "WebPush" variant) so a user agent parse would probably need to
>>>>> happen.  i'm not really a big fan of including that in the library,  but
>>>>> maybe we should have an example that shows push for FF and chrome in the
>>>>> same example.
>>>>>
>>>>>
>>>>>
>>>>> On Sun, Jul 24, 2016 at 9:05 PM, Idel Pivnitskiy <
>>>>> idel.pivnitskiy at gmail.com> wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I've added a Firefox Variant to support Push API in Mozilla Firefox
>>>>>> for UPS [1]. It works well with my previous example for Chrome [2]. I also
>>>>>> created a new PR to adapt comments in this example and notice that Firefox
>>>>>> also supported [3].
>>>>>>
>>>>>> Current implementation of Firefox Variant does not support
>>>>>> PushMessageData [4]. Looks like it will require significant changes of UPS.
>>>>>> I will initiate a separate thread for this discussion.
>>>>>>
>>>>>> [1] https://github.com/aerogear/aerogear-unifiedpush-server/pull/744
>>>>>> [2] https://github.com/aerogear/aerogear-js-cookbook/pull/13
>>>>>> [3] https://github.com/aerogear/aerogear-js-cookbook/pull/14
>>>>>> [4] https://developer.mozilla.org/en-US/docs/Web/API/PushMessageData
>>>>>>
>>>>>> Best regards,
>>>>>> Idel Pivnitskiy
>>>>>> --
>>>>>> Twitter: @idelpivnitskiy <https://twitter.com/idelpivnitskiy>
>>>>>> GitHub: @idelpivnitskiy <https://github.com/idelpivnitskiy>
>>>>>>
>>>>>> _______________________________________________
>>>>>> aerogear-dev mailing list
>>>>>> aerogear-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> aerogear-dev mailing list
>>>>> aerogear-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> twitter: http://twitter.com/mwessendorf
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20160728/491c3e19/attachment-0001.html 