From matzew at apache.org Thu Jul 7 07:26:07 2016 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 7 Jul 2016 13:26:07 +0200 Subject: [aerogear-dev] Status code for /health endpoint ? Message-ID: Hi, we have a /health endpoint: https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/util/HealthCheck.java#L54-L69 that gives indication if the DB and the supported push-networks are reachable. If all goes well, it returns '200' and a response like: {"status":"ok","details":[{"description":"Database connection","result":"connected","runtime":191,"test_status":"ok"},{"description":"Google Cloud Messaging","result":"online","runtime":143,"test_status":"ok"},{"description":"Apple Push Network Sandbox","result":"online","runtime":260,"test_status":"ok"},{"description":"Apple Push Network Production","result":"online","runtime":263,"test_status":"ok"},{"description":"Windows Push Network","result":"online","runtime":351,"test_status":"ok"}],"summary":"Everything is ok"} If something, like DB, is not reachable, it also returns '200', and describes the problems in the JSON response: {"status":"crit","details":[{"description":"Database connection","result":"org.hibernate.exception.JDBCConnectionException: could not extract ResultSet","runtime":26,"test_status":"crit"},{"description":"Google Cloud Messaging","result":"online","runtime":14,"test_status":"ok"},{"description":"Apple Push Network Sandbox","result":"online","runtime":32,"test_status":"ok"},{"description":"Apple Push Network Production","result":"online","runtime":211,"test_status":"ok"},{"description":"Windows Push Network","result":"online","runtime":149,"test_status":"ok"}],"summary":"There is 1 error found"} Questions: * do we continue to return '200' in the later case? * Or should we give a 500 if there is at least one problem ? Please report your desire :-) -Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20160707/a1826b00/attachment.html From rsmeral at redhat.com Thu Jul 7 07:50:32 2016 From: rsmeral at redhat.com (=?UTF-8?Q?Ron_=c5=a0meral?=) Date: Thu, 7 Jul 2016 13:50:32 +0200 Subject: [aerogear-dev] Status code for /health endpoint ? In-Reply-To: References: Message-ID: <577E4208.8030100@redhat.com> Hi, the health endpoint is an HTTP server. Regardless of what information the endpoint provides, HTTP status codes should reflect the state of the server itself. A 500 error would mean that the health endpoint itself is unhealthy. My 2c. Ron On 7.7.2016 13:26, Matthias Wessendorf wrote: > Hi, > > we have a /health endpoint: > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/util/HealthCheck.java#L54-L69 > > that gives indication if the DB and the supported push-networks are reachable. > > If all goes well, it returns '200' and a response like: > {"status":"ok","details":[{"description":"Database connection","result":"connected","runtime":191,"test_status":"ok"},{"description":"Google Cloud Messaging","result":"online","runtime":143,"test_status":"ok"},{"description":"Apple Push Network Sandbox","result":"online","runtime":260,"test_status":"ok"},{"description":"Apple Push Network Production","result":"online","runtime":263,"test_status":"ok"},{"description":"Windows Push Network","result":"online","runtime":351,"test_status":"ok"}],"summary":"Everything is ok"} > > > > If something, like DB, is not reachable, it also returns '200', and describes the problems in the JSON response: > {"status":"crit","details":[{"description":"Database connection","result":"org.hibernate.exception.JDBCConnectionException: could not extract ResultSet","runtime":26,"test_status":"crit"},{"description":"Google Cloud Messaging","result":"online","runtime":14,"test_status":"ok"},{"description":"Apple Push Network Sandbox","result":"online","runtime":32,"test_status":"ok"},{"description":"Apple Push Network Production","result":"online","runtime":211,"test_status":"ok"},{"description":"Windows Push Network","result":"online","runtime":149,"test_status":"ok"}],"summary":"There is 1 error found"} > > > Questions: > * do we continue to return '200' in the later case? > * Or should we give a 500 if there is at least one problem ? > > Please report your desire :-) > > > -Matthias > > -- > 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 -- Ron Smeral Technical Writer, RHMAP Brno -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20160707/7bd112d7/attachment.html From supittma at redhat.com Thu Jul 7 08:56:14 2016 From: supittma at redhat.com (Summers Pittman) Date: Thu, 7 Jul 2016 08:56:14 -0400 Subject: [aerogear-dev] Status code for /health endpoint ? In-Reply-To: References: Message-ID: On Thu, Jul 7, 2016 at 7:26 AM, Matthias Wessendorf wrote: > Hi, > > we have a /health endpoint: > > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/util/HealthCheck.java#L54-L69 > > that gives indication if the DB and the supported push-networks are > reachable. > > If all goes well, it returns '200' and a response like: > {"status":"ok","details":[{"description":"Database > connection","result":"connected","runtime":191,"test_status":"ok"},{"description":"Google > Cloud > Messaging","result":"online","runtime":143,"test_status":"ok"},{"description":"Apple > Push Network > Sandbox","result":"online","runtime":260,"test_status":"ok"},{"description":"Apple > Push Network > Production","result":"online","runtime":263,"test_status":"ok"},{"description":"Windows > Push > Network","result":"online","runtime":351,"test_status":"ok"}],"summary":"Everything > is ok"} > > > > If something, like DB, is not reachable, it also returns '200', and > describes the problems in the JSON response: > {"status":"crit","details":[{"description":"Database > connection","result":"org.hibernate.exception.JDBCConnectionException: > could not extract > ResultSet","runtime":26,"test_status":"crit"},{"description":"Google Cloud > Messaging","result":"online","runtime":14,"test_status":"ok"},{"description":"Apple > Push Network > Sandbox","result":"online","runtime":32,"test_status":"ok"},{"description":"Apple > Push Network > Production","result":"online","runtime":211,"test_status":"ok"},{"description":"Windows > Push > Network","result":"online","runtime":149,"test_status":"ok"}],"summary":"There > is 1 error found"} > > > Questions: > * do we continue to return '200' in the later case? > Yes > * Or should we give a 500 if there is at least one problem ? > No, unless the server is unable to fufll the health request. > > Please report your desire :-) > > > > -Matthias > > -- > 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/20160707/6d5e72c1/attachment.html From lholmqui at redhat.com Thu Jul 7 09:00:00 2016 From: lholmqui at redhat.com (Luke Holmquist) Date: Thu, 7 Jul 2016 09:00:00 -0400 Subject: [aerogear-dev] Status code for /health endpoint ? In-Reply-To: References: Message-ID: On Thu, Jul 7, 2016 at 8:56 AM, Summers Pittman wrote: > > > On Thu, Jul 7, 2016 at 7:26 AM, Matthias Wessendorf > wrote: > >> Hi, >> >> we have a /health endpoint: >> >> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/util/HealthCheck.java#L54-L69 >> >> that gives indication if the DB and the supported push-networks are >> reachable. >> >> If all goes well, it returns '200' and a response like: >> {"status":"ok","details":[{"description":"Database >> connection","result":"connected","runtime":191,"test_status":"ok"},{"description":"Google >> Cloud >> Messaging","result":"online","runtime":143,"test_status":"ok"},{"description":"Apple >> Push Network >> Sandbox","result":"online","runtime":260,"test_status":"ok"},{"description":"Apple >> Push Network >> Production","result":"online","runtime":263,"test_status":"ok"},{"description":"Windows >> Push >> Network","result":"online","runtime":351,"test_status":"ok"}],"summary":"Everything >> is ok"} >> >> >> >> If something, like DB, is not reachable, it also returns '200', and >> describes the problems in the JSON response: >> {"status":"crit","details":[{"description":"Database >> connection","result":"org.hibernate.exception.JDBCConnectionException: >> could not extract >> ResultSet","runtime":26,"test_status":"crit"},{"description":"Google Cloud >> Messaging","result":"online","runtime":14,"test_status":"ok"},{"description":"Apple >> Push Network >> Sandbox","result":"online","runtime":32,"test_status":"ok"},{"description":"Apple >> Push Network >> Production","result":"online","runtime":211,"test_status":"ok"},{"description":"Windows >> Push >> Network","result":"online","runtime":149,"test_status":"ok"}],"summary":"There >> is 1 error found"} >> >> >> Questions: >> * do we continue to return '200' in the later case? >> > Yes > >> * Or should we give a 500 if there is at least one problem ? >> > No, unless the server is unable to fufll the health request. > +1 to this option. Please report your desire :-) >> > > > > >> >> >> -Matthias >> >> -- >> 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 >> > > > _______________________________________________ > 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/20160707/60ab5481/attachment-0001.html From matzew at apache.org Thu Jul 7 09:13:11 2016 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 7 Jul 2016 15:13:11 +0200 Subject: [aerogear-dev] Status code for /health endpoint ? In-Reply-To: References: Message-ID: On Thu, Jul 7, 2016 at 3:00 PM, Luke Holmquist wrote: > > > On Thu, Jul 7, 2016 at 8:56 AM, Summers Pittman > wrote: > >> >> >> On Thu, Jul 7, 2016 at 7:26 AM, Matthias Wessendorf >> wrote: >> >>> Hi, >>> >>> we have a /health endpoint: >>> >>> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/util/HealthCheck.java#L54-L69 >>> >>> that gives indication if the DB and the supported push-networks are >>> reachable. >>> >>> If all goes well, it returns '200' and a response like: >>> {"status":"ok","details":[{"description":"Database >>> connection","result":"connected","runtime":191,"test_status":"ok"},{"description":"Google >>> Cloud >>> Messaging","result":"online","runtime":143,"test_status":"ok"},{"description":"Apple >>> Push Network >>> Sandbox","result":"online","runtime":260,"test_status":"ok"},{"description":"Apple >>> Push Network >>> Production","result":"online","runtime":263,"test_status":"ok"},{"description":"Windows >>> Push >>> Network","result":"online","runtime":351,"test_status":"ok"}],"summary":"Everything >>> is ok"} >>> >>> >>> >>> If something, like DB, is not reachable, it also returns '200', and >>> describes the problems in the JSON response: >>> {"status":"crit","details":[{"description":"Database >>> connection","result":"org.hibernate.exception.JDBCConnectionException: >>> could not extract >>> ResultSet","runtime":26,"test_status":"crit"},{"description":"Google Cloud >>> Messaging","result":"online","runtime":14,"test_status":"ok"},{"description":"Apple >>> Push Network >>> Sandbox","result":"online","runtime":32,"test_status":"ok"},{"description":"Apple >>> Push Network >>> Production","result":"online","runtime":211,"test_status":"ok"},{"description":"Windows >>> Push >>> Network","result":"online","runtime":149,"test_status":"ok"}],"summary":"There >>> is 1 error found"} >>> >>> >>> Questions: >>> * do we continue to return '200' in the later case? >>> >> Yes >> >>> * Or should we give a 500 if there is at least one problem ? >>> >> No, unless the server is unable to fufll the health request. >> > > +1 to this option. > ok, so we stay as is today - yay! > > Please report your desire :-) >>> >> >> >> >> >>> >>> >>> -Matthias >>> >>> -- >>> 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 >>> >> >> >> _______________________________________________ >> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20160707/3ea3fedb/attachment.html From matzew at apache.org Wed Jul 20 06:08:45 2016 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 20 Jul 2016 12:08:45 +0200 Subject: [aerogear-dev] FCM topics are not compatible with the 'receive' checkbox on the UI Message-ID: Hi, Julio did report [1], and when defaulting to topics, this is not working - as have no direct control. We can do the following: * do an unsubscribe when the checkbox is disabled AND re-subscribe when it's enabled again. We could leverage code from Oleg's TopicMgr ([2]) * remove the 'receive' checkbox * give some context, on when it is working (for Android) -Matthias [1] https://issues.jboss.org/browse/AEROGEAR-1742 [2] https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/service/src/main/java/org/jboss/aerogear/unifiedpush/service/util/FCMTopicManager.java#L87 -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20160720/4f657268/attachment.html From supittma at redhat.com Wed Jul 20 08:58:38 2016 From: supittma at redhat.com (Summers Pittman) Date: Wed, 20 Jul 2016 08:58:38 -0400 Subject: [aerogear-dev] FCM topics are not compatible with the 'receive' checkbox on the UI In-Reply-To: References: Message-ID: On Wed, Jul 20, 2016 at 6:08 AM, Matthias Wessendorf wrote: > Hi, > > Julio did report [1], and when defaulting to topics, this is not working - > as have no direct control. > > We can do the following: > * do an unsubscribe when the checkbox is disabled AND re-subscribe when > it's enabled again. We could leverage code from Oleg's TopicMgr ([2]) > I don't think this is terrible. As long as you mean an unsubscribe from the topic and not an unsubscribe from FCM ;) > * remove the 'receive' checkbox > * give some context, on when it is working (for Android) > If a user disables the receive checkbox will UPS deliver messages addressed directly to the alias of the device? > > -Matthias > > [1] https://issues.jboss.org/browse/AEROGEAR-1742 > [2] > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/service/src/main/java/org/jboss/aerogear/unifiedpush/service/util/FCMTopicManager.java#L87 > > -- > 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/20160720/08dd1ead/attachment.html From Mischa.Neumann at init.de Wed Jul 20 08:35:44 2016 From: Mischa.Neumann at init.de (Neumann, Mischa (init)) Date: Wed, 20 Jul 2016 12:35:44 +0000 Subject: [aerogear-dev] broken push notification in UPS 1.1.3.Final Message-ID: <5119322b08c949b68a2c947e67bd6ebd@VEX1A.init.de> Hi, we noticed some strange behavior when sending notifications to all variants of an app: - we have 3 ios devices - 7 android devices - when sending a notification to all variants, 4 devices are notified This applies to the REST interface too. When sending messages to only one variant, the number of recipients is correct for both the web and the rest interface. It would be nice to get some hint what could be wrong... Regards Mischa -------------- next part -------------- A non-text attachment was scrubbed... Name: server.log Type: application/octet-stream Size: 48872 bytes Desc: server.log Url : http://lists.jboss.org/pipermail/aerogear-dev/attachments/20160720/6e1b7cef/attachment-0001.obj From matzew at apache.org Wed Jul 20 10:02:42 2016 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 20 Jul 2016 16:02:42 +0200 Subject: [aerogear-dev] broken push notification in UPS 1.1.3.Final In-Reply-To: <5119322b08c949b68a2c947e67bd6ebd@VEX1A.init.de> References: <5119322b08c949b68a2c947e67bd6ebd@VEX1A.init.de> Message-ID: On Wed, Jul 20, 2016 at 2:35 PM, Neumann, Mischa (init) < Mischa.Neumann at init.de> wrote: > Hi, > > we noticed some strange behavior when sending notifications to all > variants of an app: > - we have 3 ios devices > - 7 android devices > - when sending a notification to all variants, 4 devices are notified > instead of 10 - that's wrong :) Can you share the CURL for the rest call? In the log, I see that sometimes FCM is hit - that means all devices are notified via one FCM topic - the logging says: Loaded batch #1, containing 1 tokens but, all devices, on that (global) topic, should get a message -Matthias > > This applies to the REST interface too. > When sending messages to only one variant, the number of recipients is > correct for both the web and the rest interface. > > It would be nice to get some hint what could be wrong... > > Regards > Mischa > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20160720/49e1dc74/attachment.html From michael at 410labs.com Thu Jul 21 16:27:12 2016 From: michael at 410labs.com (Michael Doo) Date: Thu, 21 Jul 2016 16:27:12 -0400 Subject: [aerogear-dev] Swift 2.3 updates to AeroGearOAuth2 & AeroGearHttp Message-ID: Hello, There are two new pull requests to the AeroGearOAuth2 and AeroGearHttp libraries to bring them up to date with the latest Xcode 8 beta (beta 3) and Swift 2.3. They are PR #53 on OAuth2 and #70 on Http. Note that for the Http project, PR #70 overrides previously submitted PR #67. Once these are merged in, I plan to open new branches for iOS 10 targets and Swift 3. Both will potentially be pretty hairy, as iOS 10 changed a number of behaviors related to NSURL and Swift 3 contains a whole host of changes to the language. I don't think there will be any harm in having minimum targets for either project be at least iOS 9, but they should also be compatible with iOS 10. Best, Michael Doo 410 Labs -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20160721/57c791b1/attachment.html From mischa.neumann at init.de Fri Jul 22 03:00:23 2016 From: mischa.neumann at init.de (mischa) Date: Fri, 22 Jul 2016 00:00:23 -0700 (MST) Subject: [aerogear-dev] broken push notification in UPS 1.1.3.Final In-Reply-To: <5119322b08c949b68a2c947e67bd6ebd@VEX1A.init.de> References: <5119322b08c949b68a2c947e67bd6ebd@VEX1A.init.de> Message-ID: <1469170823127-12632.post@n5.nabble.com> we worked around this by explicitely filtering for all known variants when sending a push message through the REST interface... -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-broken-push-notification-in-UPS-1-1-3-Final-tp12629p12632.html Sent from the aerogear-dev mailing list archive at Nabble.com. From mischa.neumann at init.de Fri Jul 22 03:09:04 2016 From: mischa.neumann at init.de (mischa) Date: Fri, 22 Jul 2016 00:09:04 -0700 (MST) Subject: [aerogear-dev] broken push notification in UPS 1.1.3.Final In-Reply-To: References: <5119322b08c949b68a2c947e67bd6ebd@VEX1A.init.de> Message-ID: <1469171344786-12633.post@n5.nabble.com> Matthias Wessendorf wrote > On Wed, Jul 20, 2016 at 2:35 PM, Neumann, Mischa (init) < > Mischa.Neumann@ >> wrote: > >> Hi, >> >> we noticed some strange behavior when sending notifications to all >> variants of an app: >> - we have 3 ios devices >> - 7 android devices >> - when sending a notification to all variants, 4 devices are notified >> > > instead of 10 - that's wrong :) > > Can you share the CURL for the rest call? no curl, but the payload (REST) is something like {"message":{"alert":"unit-test alert message","badge":-1,"priority":"NORMAL","windows":{"type":null,"duration":null,"badge":null,"tileType":null,"toastType":null,"images":[],"textFields":[],"page":null},"apns":{"content-available":false},"user-data":{"warningId":12}},"criteria":{"categories":["unit-test"]},"config":{"ttl":-1}} and from the WEB interface { "alert": "an alle ohne kategorie", "priority": "normal", "criteria": { "categories": null, "variants": null, "alias": null, "deviceType": null }, "config": { "ttl": -1 } } Mischa -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-broken-push-notification-in-UPS-1-1-3-Final-tp12629p12633.html Sent from the aerogear-dev mailing list archive at Nabble.com. From matzew at apache.org Fri Jul 22 03:09:06 2016 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 22 Jul 2016 09:09:06 +0200 Subject: [aerogear-dev] broken push notification in UPS 1.1.3.Final In-Reply-To: <1469170823127-12632.post@n5.nabble.com> References: <5119322b08c949b68a2c947e67bd6ebd@VEX1A.init.de> <1469170823127-12632.post@n5.nabble.com> Message-ID: Not sure I follow here On Fri, Jul 22, 2016 at 9:00 AM, mischa wrote: > we worked around this by explicitely filtering for all known variants when > sending a push message through the REST interface... > > > > -- > View this message in context: > http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-broken-push-notification-in-UPS-1-1-3-Final-tp12629p12632.html > Sent from the aerogear-dev mailing list archive at Nabble.com. > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20160722/6ada1eec/attachment.html From matzew at apache.org Fri Jul 22 03:11:25 2016 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 22 Jul 2016 09:11:25 +0200 Subject: [aerogear-dev] broken push notification in UPS 1.1.3.Final In-Reply-To: <1469171344786-12633.post@n5.nabble.com> References: <5119322b08c949b68a2c947e67bd6ebd@VEX1A.init.de> <1469171344786-12633.post@n5.nabble.com> Message-ID: when you say 4 devices - out of 10 are receiving notifications: are that all 3 ios devices, and just one Android device? what version of the Android SDK are you using ? On Fri, Jul 22, 2016 at 9:09 AM, mischa wrote: > Matthias Wessendorf wrote > > On Wed, Jul 20, 2016 at 2:35 PM, Neumann, Mischa (init) < > > > Mischa.Neumann@ > > >> wrote: > > > >> Hi, > >> > >> we noticed some strange behavior when sending notifications to all > >> variants of an app: > >> - we have 3 ios devices > >> - 7 android devices > >> - when sending a notification to all variants, 4 devices are notified > >> > > > > instead of 10 - that's wrong :) > > > > Can you share the CURL for the rest call? > > no curl, but the payload (REST) is something like > > {"message":{"alert":"unit-test alert > > message","badge":-1,"priority":"NORMAL","windows":{"type":null,"duration":null,"badge":null,"tileType":null,"toastType":null,"images":[],"textFields":[],"page":null},"apns":{"content-available":false},"user-data":{"warningId":12}},"criteria":{"categories":["unit-test"]},"config":{"ttl":-1}} > > and from the WEB interface > > { > "alert": "an alle ohne kategorie", > "priority": "normal", > "criteria": { > "categories": null, > "variants": null, > "alias": null, > "deviceType": null > }, > "config": { > "ttl": -1 > } > } > > Mischa > > > > -- > View this message in context: > http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-broken-push-notification-in-UPS-1-1-3-Final-tp12629p12633.html > Sent from the aerogear-dev mailing list archive at Nabble.com. > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20160722/45944f15/attachment-0001.html From mischa.neumann at init.de Fri Jul 22 03:13:44 2016 From: mischa.neumann at init.de (mischa) Date: Fri, 22 Jul 2016 00:13:44 -0700 (MST) Subject: [aerogear-dev] broken push notification in UPS 1.1.3.Final In-Reply-To: References: <5119322b08c949b68a2c947e67bd6ebd@VEX1A.init.de> <1469170823127-12632.post@n5.nabble.com> Message-ID: <1469171624224-12636.post@n5.nabble.com> Matthias Wessendorf wrote > Not sure I follow here > > On Fri, Jul 22, 2016 at 9:00 AM, mischa < > mischa.neumann@ > > wrote: > >> we worked around this by explicitely filtering for all known variants >> when >> sending a push message through the REST interface... when sending {"message":{"alert":"unit-test alert message","badge":-1,"priority":"NORMAL","windows":{"type":null,"duration":null,"badge":null,"tileType":null,"toastType":null,"images":[],"textFields":[],"page":null},"apns":{"content-available":false},"user-data":{"warningId":12}},"criteria":{"categories":["unit-test"],"variants":["65bac606-5b73-42d8-9641-d70948c9717e","f2eed0fb-6e9a-42c6-8759-457e2241daae"]},"config":{"ttl":-1}} all devices are notified, with {"message":{"alert":"unit-test alert message","badge":-1,"priority":"NORMAL","windows":{"type":null,"duration":null,"badge":null,"tileType":null,"toastType":null,"images":[],"textFields":[],"page":null},"apns":{"content-available":false},"user-data":{"warningId":12}},"criteria":{"categories":["unit-test"]},"config":{"ttl":-1}} not Mischa -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-broken-push-notification-in-UPS-1-1-3-Final-tp12629p12636.html Sent from the aerogear-dev mailing list archive at Nabble.com. From matzew at apache.org Fri Jul 22 03:30:50 2016 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 22 Jul 2016 09:30:50 +0200 Subject: [aerogear-dev] broken push notification in UPS 1.1.3.Final In-Reply-To: <1469171624224-12636.post@n5.nabble.com> References: <5119322b08c949b68a2c947e67bd6ebd@VEX1A.init.de> <1469170823127-12632.post@n5.nabble.com> <1469171624224-12636.post@n5.nabble.com> Message-ID: only Android devices are not getting the message ? On Fri, Jul 22, 2016 at 9:13 AM, mischa wrote: > Matthias Wessendorf wrote > > Not sure I follow here > > > > On Fri, Jul 22, 2016 at 9:00 AM, mischa < > > > mischa.neumann@ > > > > wrote: > > > >> we worked around this by explicitely filtering for all known variants > >> when > >> sending a push message through the REST interface... > > when sending > {"message":{"alert":"unit-test alert > > message","badge":-1,"priority":"NORMAL","windows":{"type":null,"duration":null,"badge":null,"tileType":null,"toastType":null,"images":[],"textFields":[],"page":null},"apns":{"content-available":false},"user-data":{"warningId":12}},"criteria":{"categories":["unit-test"],"variants":["65bac606-5b73-42d8-9641-d70948c9717e","f2eed0fb-6e9a-42c6-8759-457e2241daae"]},"config":{"ttl":-1}} > all devices are notified, with > {"message":{"alert":"unit-test alert > > message","badge":-1,"priority":"NORMAL","windows":{"type":null,"duration":null,"badge":null,"tileType":null,"toastType":null,"images":[],"textFields":[],"page":null},"apns":{"content-available":false},"user-data":{"warningId":12}},"criteria":{"categories":["unit-test"]},"config":{"ttl":-1}} > not > > Mischa > > > > -- > View this message in context: > http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-broken-push-notification-in-UPS-1-1-3-Final-tp12629p12636.html > Sent from the aerogear-dev mailing list archive at Nabble.com. > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20160722/25c9edf3/attachment.html From mischa.neumann at init.de Fri Jul 22 03:33:35 2016 From: mischa.neumann at init.de (mischa) Date: Fri, 22 Jul 2016 00:33:35 -0700 (MST) Subject: [aerogear-dev] broken push notification in UPS 1.1.3.Final In-Reply-To: References: <5119322b08c949b68a2c947e67bd6ebd@VEX1A.init.de> <1469171344786-12633.post@n5.nabble.com> Message-ID: <1469172815285-12638.post@n5.nabble.com> Matthias Wessendorf wrote > when you say 4 devices - out of 10 are receiving notifications: > are that all 3 ios devices, and just one Android device? > > what version of the Android SDK are you using ? yes, you are right, now: - we have 26 android and 5 ios devices, all registered to the category "PRODUCTS" - {"message":{"alert":"unit-test alert message","badge":-1,"priority":"NORMAL","windows":{"type":null,"duration":null,"badge":null,"tileType":null,"toastType":null,"images":[],"textFields":[],"page":null},"apns":{"content-available":false},"user-data":{"warningId":12}},"criteria":{"categories":["PRODUCTS"]},"config":{"ttl":-1}} is delivered to 6 devices (5 ios and 1 android) the devices are not registering themselves at the UPS but the backend server does this as a delegate. sample from unit test: >> "Authorization: Basic ZjJl..." >> "{"alias":"42","categories":["FOOD","PRODUCTS"],"deviceToken":"aaaaaaaa >> aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa 302087"}" << "{"id":"6b186514-f0d7-461a-b996-b6efee732a04","enabled":true,"deviceToken":"aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa 302087","deviceType":null,"operatingSystem":null,"osVersion":null,"alias":"42","categories":[{"name":"PRODUCTS"},{"name":"FOOD"}],"platform":null}[\r][\n]" --> works like a charm Mischa -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-broken-push-notification-in-UPS-1-1-3-Final-tp12629p12638.html Sent from the aerogear-dev mailing list archive at Nabble.com. From mischa.neumann at init.de Fri Jul 22 03:37:13 2016 From: mischa.neumann at init.de (mischa) Date: Fri, 22 Jul 2016 00:37:13 -0700 (MST) Subject: [aerogear-dev] broken push notification in UPS 1.1.3.Final In-Reply-To: References: <5119322b08c949b68a2c947e67bd6ebd@VEX1A.init.de> <1469170823127-12632.post@n5.nabble.com> <1469171624224-12636.post@n5.nabble.com> Message-ID: <1469173033491-12639.post@n5.nabble.com> Matthias Wessendorf wrote > only Android devices are not getting the message ? exactly, all ios and one android device... Mischa -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-broken-push-notification-in-UPS-1-1-3-Final-tp12629p12639.html Sent from the aerogear-dev mailing list archive at Nabble.com. From matzew at apache.org Fri Jul 22 04:23:06 2016 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 22 Jul 2016 10:23:06 +0200 Subject: [aerogear-dev] broken push notification in UPS 1.1.3.Final In-Reply-To: <1469172815285-12638.post@n5.nabble.com> References: <5119322b08c949b68a2c947e67bd6ebd@VEX1A.init.de> <1469171344786-12633.post@n5.nabble.com> <1469172815285-12638.post@n5.nabble.com> Message-ID: Ah, I think the delegate is the issue; because it lacks the FCM topic code from Android SDK On Friday, 22 July 2016, mischa wrote: > Matthias Wessendorf wrote > > when you say 4 devices - out of 10 are receiving notifications: > > are that all 3 ios devices, and just one Android device? > > > > what version of the Android SDK are you using ? > > yes, you are right, now: > - we have 26 android and 5 ios devices, all registered to the category > "PRODUCTS" > - {"message":{"alert":"unit-test alert > > message","badge":-1,"priority":"NORMAL","windows":{"type":null,"duration":null,"badge":null,"tileType":null,"toastType":null,"images":[],"textFields":[],"page":null},"apns":{"content-available":false},"user-data":{"warningId":12}},"criteria":{"categories":["PRODUCTS"]},"config":{"ttl":-1}} > is delivered to 6 devices (5 ios and 1 android) > > the devices are not registering themselves at the UPS but the backend > server > does this as a delegate. > sample from unit test: > > >> "Authorization: Basic ZjJl..." > >> "{"alias":"42","categories":["FOOD","PRODUCTS"],"deviceToken":"aaaaaaaa > >> aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa 302087"}" > > << > > "{"id":"6b186514-f0d7-461a-b996-b6efee732a04","enabled":true,"deviceToken":"aaaaaaaa > aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa > > 302087","deviceType":null,"operatingSystem":null,"osVersion":null,"alias":"42","categories":[{"name":"PRODUCTS"},{"name":"FOOD"}],"platform":null}[\r][\n]" > > --> works like a charm > > Mischa > > > > > -- > View this message in context: > http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-broken-push-notification-in-UPS-1-1-3-Final-tp12629p12638.html > Sent from the aerogear-dev mailing list archive at Nabble.com. > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Sent from Gmail Mobile -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20160722/06045299/attachment.html From mischa.neumann at init.de Fri Jul 22 04:42:29 2016 From: mischa.neumann at init.de (mischa) Date: Fri, 22 Jul 2016 01:42:29 -0700 (MST) Subject: [aerogear-dev] broken push notification in UPS 1.1.3.Final In-Reply-To: References: <5119322b08c949b68a2c947e67bd6ebd@VEX1A.init.de> <1469171344786-12633.post@n5.nabble.com> <1469172815285-12638.post@n5.nabble.com> Message-ID: <1469176949877-12641.post@n5.nabble.com> Matthias Wessendorf wrote > Ah, I think the delegate is the issue; because it lacks the FCM topic code > from Android SDK we had no problems with aerogear-unifiedpush-server-1.2.0-alpha.1 and not when naming the variants with aerogear-unifiedpush-server-1.1.3.Final but I would give it a try: how would a correct json request look like? couldn't find something matching at https://aerogear.org/docs/specs/aerogear-unifiedpush-rest-1.0.x/registry/device/index.html Mischa -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-broken-push-notification-in-UPS-1-1-3-Final-tp12629p12641.html Sent from the aerogear-dev mailing list archive at Nabble.com. From matzew at apache.org Fri Jul 22 05:02:12 2016 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 22 Jul 2016 11:02:12 +0200 Subject: [aerogear-dev] broken push notification in UPS 1.1.3.Final In-Reply-To: <1469176949877-12641.post@n5.nabble.com> References: <5119322b08c949b68a2c947e67bd6ebd@VEX1A.init.de> <1469171344786-12633.post@n5.nabble.com> <1469172815285-12638.post@n5.nabble.com> <1469176949877-12641.post@n5.nabble.com> Message-ID: On Fri, Jul 22, 2016 at 10:42 AM, mischa wrote: > Matthias Wessendorf wrote > > Ah, I think the delegate is the issue; because it lacks the FCM topic > code > > from Android SDK > > we had no problems with aerogear-unifiedpush-server-1.2.0-alpha.1 > and not when naming the variants with > 1.1.2 and 1.2.0-alpha.1 is not containing FCM > aerogear-unifiedpush-server-1.1.3.Final > but FCM is included in 1.1.3 and master (1.2.0-alpha.2-SNAPSHOT) FCM registration is done here: https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/fcm/AeroGearFCMPushRegistrar.java#L186-L191 But... I wonder... if we can, or should, do something about that on the srver side... hrm... > but I would give it a try: > > how would a correct json request look like? > couldn't find something matching at > > https://aerogear.org/docs/specs/aerogear-unifiedpush-rest-1.0.x/registry/device/index.html > > Mischa > > > > -- > View this message in context: > http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-broken-push-notification-in-UPS-1-1-3-Final-tp12629p12641.html > Sent from the aerogear-dev mailing list archive at Nabble.com. > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20160722/91445ea4/attachment-0001.html From mischa.neumann at init.de Fri Jul 22 05:19:15 2016 From: mischa.neumann at init.de (mischa) Date: Fri, 22 Jul 2016 02:19:15 -0700 (MST) Subject: [aerogear-dev] broken push notification in UPS 1.1.3.Final In-Reply-To: References: <5119322b08c949b68a2c947e67bd6ebd@VEX1A.init.de> <1469171344786-12633.post@n5.nabble.com> <1469172815285-12638.post@n5.nabble.com> <1469176949877-12641.post@n5.nabble.com> Message-ID: <1469179155063-12643.post@n5.nabble.com> Matthias Wessendorf wrote > On Fri, Jul 22, 2016 at 10:42 AM, mischa < > mischa.neumann@ > > wrote: > >> Matthias Wessendorf wrote >> > Ah, I think the delegate is the issue; because it lacks the FCM topic >> code >> > from Android SDK >> >> we had no problems with aerogear-unifiedpush-server-1.2.0-alpha.1 >> and not when naming the variants with >> > > 1.1.2 and 1.2.0-alpha.1 is not containing FCM > > >> aerogear-unifiedpush-server-1.1.3.Final >> > > but FCM is included in 1.1.3 and master (1.2.0-alpha.2-SNAPSHOT) > > > FCM registration is done here: > https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/fcm/AeroGearFCMPushRegistrar.java#L186-L191 > > But... I wonder... if we can, or should, do something about that on the > srver side... hrm... I see: ... Sent push notification to GCM topic: /topics/PRODUCTS ... and as no client didn't register with the help of aerogear-android-push for this topic at Firebase, it wouldn't get any notifications. then the frontend message "X receivers" is misleadingly as one receiver is a FCM topic channel :-) and it's not clear, why the UPS is behaving differently when the android variant is directly targeted in the push request. Mischa -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-broken-push-notification-in-UPS-1-1-3-Final-tp12629p12643.html Sent from the aerogear-dev mailing list archive at Nabble.com. From mischa.neumann at init.de Fri Jul 22 05:56:51 2016 From: mischa.neumann at init.de (mischa) Date: Fri, 22 Jul 2016 02:56:51 -0700 (MST) Subject: [aerogear-dev] broken push notification in UPS 1.1.3.Final In-Reply-To: References: <5119322b08c949b68a2c947e67bd6ebd@VEX1A.init.de> <1469171344786-12633.post@n5.nabble.com> <1469172815285-12638.post@n5.nabble.com> <1469176949877-12641.post@n5.nabble.com> Message-ID: <1469181411296-12644.post@n5.nabble.com> Matthias Wessendorf wrote > On Fri, Jul 22, 2016 at 10:42 AM, mischa < > mischa.neumann@ > > wrote: > > But... I wonder... if we can, or should, do something about that on the > srver side... hrm... I think you can't and you shouldn't. We will keep an eye on that issue and count in that our actual workaround might not work in future versions of UPS. in long-term we will add a firebase topic (un)subscription to the android part that is registering at our backend (we are prepared that a notify-all-message send by the UPS web interface will not reach any android client) Thanks a lot for your great support Mischa -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-broken-push-notification-in-UPS-1-1-3-Final-tp12629p12644.html Sent from the aerogear-dev mailing list archive at Nabble.com. From matzew at apache.org Fri Jul 22 06:18:33 2016 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 22 Jul 2016 12:18:33 +0200 Subject: [aerogear-dev] broken push notification in UPS 1.1.3.Final In-Reply-To: <1469179155063-12643.post@n5.nabble.com> References: <5119322b08c949b68a2c947e67bd6ebd@VEX1A.init.de> <1469171344786-12633.post@n5.nabble.com> <1469172815285-12638.post@n5.nabble.com> <1469176949877-12641.post@n5.nabble.com> <1469179155063-12643.post@n5.nabble.com> Message-ID: On Fri, Jul 22, 2016 at 11:19 AM, mischa wrote: > Matthias Wessendorf wrote > > On Fri, Jul 22, 2016 at 10:42 AM, mischa < > > > mischa.neumann@ > > > > wrote: > > > >> Matthias Wessendorf wrote > >> > Ah, I think the delegate is the issue; because it lacks the FCM topic > >> code > >> > from Android SDK > >> > >> we had no problems with aerogear-unifiedpush-server-1.2.0-alpha.1 > >> and not when naming the variants with > >> > > > > 1.1.2 and 1.2.0-alpha.1 is not containing FCM > > > > > >> aerogear-unifiedpush-server-1.1.3.Final > >> > > > > but FCM is included in 1.1.3 and master (1.2.0-alpha.2-SNAPSHOT) > > > > > > FCM registration is done here: > > > https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/fcm/AeroGearFCMPushRegistrar.java#L186-L191 > > > > But... I wonder... if we can, or should, do something about that on the > > srver side... hrm... > > I see: > ... Sent push notification to GCM topic: /topics/PRODUCTS ... > and as no client didn't register with the help of aerogear-android-push for > this topic at Firebase, it wouldn't get any notifications. > > then the frontend message "X receivers" is misleadingly as one receiver is > a > FCM topic channel :-) > yeah, that's something we need to fix - I am not happy w/ that too > > and it's not clear, why the UPS is behaving differently when the android > variant is directly targeted in the push request. > because, than we don't do the topic :) we do direct device tokens: https://github.com/aerogear/aerogear-unifiedpush-server/blob/1.1.3.Final/push/sender/src/main/java/org/jboss/aerogear/unifiedpush/message/token/TokenLoader.java#L129 https://github.com/aerogear/aerogear-unifiedpush-server/blob/1.1.3.Final/push/sender/src/main/java/org/jboss/aerogear/unifiedpush/message/token/TokenLoaderUtils.java#L82 So... we have some hooks to not go w/ FCM topics..... but I hate to introduce a flag to not use FCM topics..... So, perhaps for you guys, just send a few request w/ variants tagged? instead of one - that would work - and will continue to work :D > Mischa > > > > -- > View this message in context: > http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-broken-push-notification-in-UPS-1-1-3-Final-tp12629p12643.html > Sent from the aerogear-dev mailing list archive at Nabble.com. > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20160722/f92b41f5/attachment.html From mischa.neumann at init.de Fri Jul 22 06:57:06 2016 From: mischa.neumann at init.de (mischa) Date: Fri, 22 Jul 2016 03:57:06 -0700 (MST) Subject: [aerogear-dev] broken push notification in UPS 1.1.3.Final In-Reply-To: References: <5119322b08c949b68a2c947e67bd6ebd@VEX1A.init.de> <1469171344786-12633.post@n5.nabble.com> <1469172815285-12638.post@n5.nabble.com> <1469176949877-12641.post@n5.nabble.com> <1469179155063-12643.post@n5.nabble.com> Message-ID: <1469185026808-12646.post@n5.nabble.com> Matthias Wessendorf wrote > So... we have some hooks to not go w/ FCM topics..... but I hate to > introduce a flag to not use FCM topics..... > So, perhaps for you guys, just send a few request w/ variants tagged? > instead of one - that would work - and will continue to work :D It's no problem for us to always set the targeted variants when pushing from our backend. and when sending from the web frontend we have to select each variant instead of none - just checked: works too. have a nice weekend Mischa -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-broken-push-notification-in-UPS-1-1-3-Final-tp12629p12646.html Sent from the aerogear-dev mailing list archive at Nabble.com. From matzew at apache.org Fri Jul 22 08:47:56 2016 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 22 Jul 2016 14:47:56 +0200 Subject: [aerogear-dev] AeroGear Pipe - staging repo for 3.0.1 release Message-ID: Hello, for releasing the 3.0.1 version of AGDroid Pipe, I have staged the lib here: https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-8667/ Let me know about your tests, and I will click the magic release button early next week! -M -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20160722/9d90a7c8/attachment.html From matzew at apache.org Fri Jul 22 09:02:30 2016 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 22 Jul 2016 15:02:30 +0200 Subject: [aerogear-dev] AeroGear Pipe - staging repo for 3.0.1 release In-Reply-To: References: Message-ID: nope ... it's 3.1.0 :-) https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-8668/ On Fri, Jul 22, 2016 at 2:47 PM, Matthias Wessendorf wrote: > Hello, > > for releasing the 3.0.1 version of AGDroid Pipe, I have staged the lib > here: > > https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-8667/ > > Let me know about your tests, and I will click the magic release button > early next week! > > -M > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > twitter: http://twitter.com/mwessendorf > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20160722/6bd6216e/attachment-0001.html From idel.pivnitskiy at gmail.com Sun Jul 24 21:05:05 2016 From: idel.pivnitskiy at gmail.com (Idel Pivnitskiy) Date: Mon, 25 Jul 2016 04:05:05 +0300 Subject: [aerogear-dev] Firefox Push API with UnifiedPush Server Message-ID: 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 GitHub: @idelpivnitskiy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20160725/1f95c10d/attachment.html From idel.pivnitskiy at gmail.com Sun Jul 24 21:19:03 2016 From: idel.pivnitskiy at gmail.com (Idel Pivnitskiy) Date: Mon, 25 Jul 2016 04:19:03 +0300 Subject: [aerogear-dev] Push message encryption to support PushMessageData of Push API Message-ID: Hi all, As we discussed previously, Firefox already supports sending push message data to browser if it will be encrypted. Since version 50, Google Chrome also support it [1]. But it requires for UPS to store "public key" and "auth secret" for each Installation [2]. See current example of sending push notifications with a payload[3]. Storing of two additional fields is not a big deal. But we also have to refactor PushNotificationSender [4], because it consumes a collection of device tokens as a param instead of a collection of installations. Any thoughts about how we can implement it with minimal changes? [1] https://developer.mozilla.org/en-US/docs/Web/API/PushMessageData [2] https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/model/api/src/main/java/org/jboss/aerogear/unifiedpush/api/Installation.java [3] https://serviceworke.rs/push-payload_index_doc.html [4] https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/push/sender/src/main/java/org/jboss/aerogear/unifiedpush/message/sender/PushNotificationSender.java Best regards, Idel Pivnitskiy -- Twitter: @idelpivnitskiy GitHub: @idelpivnitskiy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20160725/cdb9ce06/attachment.html From Mischa.Neumann at init.de Mon Jul 25 02:09:14 2016 From: Mischa.Neumann at init.de (Neumann, Mischa (init)) Date: Mon, 25 Jul 2016 06:09:14 +0000 Subject: [aerogear-dev] Push message encryption to support PushMessageData of Push API In-Reply-To: References: Message-ID: <87ef1ecdc57c43309d7712e0c5cde2cb@VEX3.init.de> Hi, don't insist on minimal changes :-) you are modelling the message to send as one object and the recipients as two other (variant and tokens) parameters. it would be a natural enhancement to model the receivers in one object or - more similar to other apis like javax.mail - to integrate the receivers specification in the message object. Regards, Mischa Von: aerogear-dev-bounces at lists.jboss.org [mailto:aerogear-dev-bounces at lists.jboss.org] Im Auftrag von Idel Pivnitskiy Gesendet: Montag, 25. Juli 2016 03:19 An: AeroGear Developer Mailing List Betreff: [aerogear-dev] Push message encryption to support PushMessageData of Push API Hi all, As we discussed previously, Firefox already supports sending push message data to browser if it will be encrypted. Since version 50, Google Chrome also support it [1]. But it requires for UPS to store "public key" and "auth secret" for each Installation [2]. See current example of sending push notifications with a payload[3]. Storing of two additional fields is not a big deal. But we also have to refactor PushNotificationSender [4], because it consumes a collection of device tokens as a param instead of a collection of installations. Any thoughts about how we can implement it with minimal changes? [1] https://developer.mozilla.org/en-US/docs/Web/API/PushMessageData [2] https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/model/api/src/main/java/org/jboss/aerogear/unifiedpush/api/Installation.java [3] https://serviceworke.rs/push-payload_index_doc.html [4] https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/push/sender/src/main/java/org/jboss/aerogear/unifiedpush/message/sender/PushNotificationSender.java Best regards, Idel Pivnitskiy -- Twitter: @idelpivnitskiy GitHub: @idelpivnitskiy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20160725/52fd7c04/attachment.html From scm.blanc at gmail.com Mon Jul 25 08:45:17 2016 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Mon, 25 Jul 2016 14:45:17 +0200 Subject: [aerogear-dev] UnifiedPush Go Sender Library Message-ID: Hi folk, A few days ago I started to play with Go and the result of that is a small Sender Library for the UnifiedPush Server : https://github.com/sebastienblanc/upsgosender Usage is pretty simple : criteria := &Criteria{Alias: []string{"seb", "bob"}}message := &Message{Alert: "hello from #golang sender"}unifiedMessage := &UnifiedMessage{Message: *message, Criteria: *criteria}settings := &Settings{ URL: "https://mypushserver.com/ag-push", ApplicationID: "58f87fb7-829c-4c6f-a0eb-326d3017a94c", MasterSecret: "3366736b-d52c-4115-87d3-c08095e87955"}sender := NewSender(*settings) sender.send(*unifiedMessage) Since, I'm a newbie on Go, PRs are mote than welcome to polish the code or remove any anti-Go-patterns I could have used ;) I still need to implement Proxy and Truststore support and add more test but I think it's a good start. Sebi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20160725/67e9eb09/attachment-0001.html From lholmqui at redhat.com Mon Jul 25 09:25:01 2016 From: lholmqui at redhat.com (Luke Holmquist) Date: Mon, 25 Jul 2016 09:25:01 -0400 Subject: [aerogear-dev] Firefox Push API with UnifiedPush Server In-Reply-To: References: Message-ID: 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 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 > GitHub: @idelpivnitskiy > > _______________________________________________ > 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/20160725/1142fb22/attachment.html From idel.pivnitskiy at gmail.com Mon Jul 25 10:21:41 2016 From: idel.pivnitskiy at gmail.com (Idel Pivnitskiy) Date: Mon, 25 Jul 2016 17:21:41 +0300 Subject: [aerogear-dev] Firefox Push API with UnifiedPush Server In-Reply-To: References: Message-ID: 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 GitHub: @idelpivnitskiy On Mon, Jul 25, 2016 at 4:25 PM, Luke Holmquist 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 >> GitHub: @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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20160725/11cf8e04/attachment.html From idel.pivnitskiy at gmail.com Mon Jul 25 18:15:42 2016 From: idel.pivnitskiy at gmail.com (Idel Pivnitskiy) Date: Tue, 26 Jul 2016 01:15:42 +0300 Subject: [aerogear-dev] Firefox Push API with UnifiedPush Server In-Reply-To: References: Message-ID: 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 GitHub: @idelpivnitskiy On Mon, Jul 25, 2016 at 5:21 PM, Idel Pivnitskiy 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 > GitHub: @idelpivnitskiy > > On Mon, Jul 25, 2016 at 4:25 PM, Luke Holmquist > 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 >>> GitHub: @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 >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20160726/1e04ff35/attachment-0001.html From matzew at apache.org Tue Jul 26 06:10:05 2016 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 26 Jul 2016 12:10:05 +0200 Subject: [aerogear-dev] Push message encryption to support PushMessageData of Push API In-Reply-To: References: Message-ID: hrm, not sure I am that happy about these requirements :) I guess we also need to change our data access layer to not just return tokens, but a more complex object, containing token, key and secret - hrm :) On Mon, Jul 25, 2016 at 3:19 AM, Idel Pivnitskiy wrote: > Hi all, > > As we discussed previously, Firefox already supports sending push message > data to browser if it will be encrypted. Since version 50, Google Chrome > also support it [1]. But it requires for UPS to store "public key" and > "auth secret" for each Installation [2]. See current example of sending > push notifications with a payload[3]. > > Storing of two additional fields is not a big deal. But we also have to > refactor PushNotificationSender [4], because it consumes a collection of > device tokens as a param instead of a collection of installations. > > Any thoughts about how we can implement it with minimal changes? > > [1] https://developer.mozilla.org/en-US/docs/Web/API/PushMessageData > [2] > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/model/api/src/main/java/org/jboss/aerogear/unifiedpush/api/Installation.java > [3] https://serviceworke.rs/push-payload_index_doc.html > [4] > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/push/sender/src/main/java/org/jboss/aerogear/unifiedpush/message/sender/PushNotificationSender.java > > Best regards, > Idel Pivnitskiy > -- > Twitter: @idelpivnitskiy > GitHub: @idelpivnitskiy > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20160726/5e367199/attachment.html From matzew at apache.org Tue Jul 26 06:16:20 2016 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 26 Jul 2016 12:16:20 +0200 Subject: [aerogear-dev] Firefox Push API with UnifiedPush Server In-Reply-To: References: Message-ID: 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 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 > GitHub: @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 >> GitHub: @idelpivnitskiy >> >> On Mon, Jul 25, 2016 at 4:25 PM, Luke Holmquist >> 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 >>>> GitHub: @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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20160726/828c7dcd/attachment.html From matzew at apache.org Tue Jul 26 06:17:20 2016 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 26 Jul 2016 12:17:20 +0200 Subject: [aerogear-dev] Push message encryption to support PushMessageData of Push API In-Reply-To: References: Message-ID: perhaps break it down, on the server into two different sending processes ? native send (curernt) wrbpush send ? where we would have a WebPushSender API ? On Tue, Jul 26, 2016 at 12:10 PM, Matthias Wessendorf wrote: > hrm, not sure I am that happy about these requirements :) > > I guess we also need to change our data access layer to not just return > tokens, but a more complex object, containing token, key and secret - hrm > :) > > On Mon, Jul 25, 2016 at 3:19 AM, Idel Pivnitskiy < > idel.pivnitskiy at gmail.com> wrote: > >> Hi all, >> >> As we discussed previously, Firefox already supports sending push message >> data to browser if it will be encrypted. Since version 50, Google Chrome >> also support it [1]. But it requires for UPS to store "public key" and >> "auth secret" for each Installation [2]. See current example of sending >> push notifications with a payload[3]. >> >> Storing of two additional fields is not a big deal. But we also have to >> refactor PushNotificationSender [4], because it consumes a collection of >> device tokens as a param instead of a collection of installations. >> >> Any thoughts about how we can implement it with minimal changes? >> >> [1] https://developer.mozilla.org/en-US/docs/Web/API/PushMessageData >> [2] >> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/model/api/src/main/java/org/jboss/aerogear/unifiedpush/api/Installation.java >> [3] https://serviceworke.rs/push-payload_index_doc.html >> [4] >> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/push/sender/src/main/java/org/jboss/aerogear/unifiedpush/message/sender/PushNotificationSender.java >> >> Best regards, >> Idel Pivnitskiy >> -- >> Twitter: @idelpivnitskiy >> GitHub: @idelpivnitskiy >> >> _______________________________________________ >> 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 > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20160726/d8689dd1/attachment-0001.html From idel.pivnitskiy at gmail.com Tue Jul 26 06:48:40 2016 From: idel.pivnitskiy at gmail.com (Idel Pivnitskiy) Date: Tue, 26 Jul 2016 13:48:40 +0300 Subject: [aerogear-dev] Firefox Push API with UnifiedPush Server In-Reply-To: References: Message-ID: > > 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 GitHub: @idelpivnitskiy On Tue, Jul 26, 2016 at 1:16 PM, Matthias Wessendorf 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 >> GitHub: @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 >>> GitHub: @idelpivnitskiy >>> >>> On Mon, Jul 25, 2016 at 4:25 PM, Luke Holmquist >>> 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 >>>>> GitHub: @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/20160726/1db483f4/attachment.html From idel.pivnitskiy at gmail.com Tue Jul 26 07:01:34 2016 From: idel.pivnitskiy at gmail.com (Idel Pivnitskiy) Date: Tue, 26 Jul 2016 14:01:34 +0300 Subject: [aerogear-dev] Push message encryption to support PushMessageData of Push API In-Reply-To: References: Message-ID: > > perhaps break it down, on the server into two different sending processes > ? > native send (curernt) > wrbpush send ? > > where we would have a WebPushSender API ? > Hard to talk about separate unique API for WebPush right now, when here is just two implementations (FCM and MPS) and both of them have not implemented WebPush protocol yet. Think that temporal experimental solution may be enough now. Let's see what can I do today-tomorrow to allow sending push notifications to both (FCM and MPS) providers for WebPush variant [1]. [1] https://github.com/aerogear/aerogear-unifiedpush-server/pull/745#discussion_r72153644 Best regards, Idel Pivnitskiy -- Twitter: @idelpivnitskiy GitHub: @idelpivnitskiy On Tue, Jul 26, 2016 at 1:17 PM, Matthias Wessendorf wrote: > perhaps break it down, on the server into two different sending processes > ? > native send (curernt) > wrbpush send ? > > where we would have a WebPushSender API ? > > On Tue, Jul 26, 2016 at 12:10 PM, Matthias Wessendorf > wrote: > >> hrm, not sure I am that happy about these requirements :) >> >> I guess we also need to change our data access layer to not just return >> tokens, but a more complex object, containing token, key and secret - hrm >> :) >> >> On Mon, Jul 25, 2016 at 3:19 AM, Idel Pivnitskiy < >> idel.pivnitskiy at gmail.com> wrote: >> >>> Hi all, >>> >>> As we discussed previously, Firefox already supports sending push >>> message data to browser if it will be encrypted. Since version 50, Google >>> Chrome also support it [1]. But it requires for UPS to store "public key" >>> and "auth secret" for each Installation [2]. See current example of sending >>> push notifications with a payload[3]. >>> >>> Storing of two additional fields is not a big deal. But we also have to >>> refactor PushNotificationSender [4], because it consumes a collection of >>> device tokens as a param instead of a collection of installations. >>> >>> Any thoughts about how we can implement it with minimal changes? >>> >>> [1] https://developer.mozilla.org/en-US/docs/Web/API/PushMessageData >>> [2] >>> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/model/api/src/main/java/org/jboss/aerogear/unifiedpush/api/Installation.java >>> [3] https://serviceworke.rs/push-payload_index_doc.html >>> [4] >>> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/push/sender/src/main/java/org/jboss/aerogear/unifiedpush/message/sender/PushNotificationSender.java >>> >>> Best regards, >>> Idel Pivnitskiy >>> -- >>> Twitter: @idelpivnitskiy >>> GitHub: @idelpivnitskiy >>> >>> _______________________________________________ >>> 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 >> > > > > -- > 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/20160726/b3fbcaa8/attachment-0001.html From dpassos at redhat.com Wed Jul 27 10:01:31 2016 From: dpassos at redhat.com (Daniel Passos) Date: Wed, 27 Jul 2016 11:01:31 -0300 Subject: [aerogear-dev] AeroGear Pipe - staging repo for 3.0.1 release In-Reply-To: References: Message-ID: I have tested it. I think we can push the release button ;) On Fri, Jul 22, 2016 at 10:02 AM, Matthias Wessendorf wrote: > nope ... it's 3.1.0 :-) > > > > https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-8668/ > > > > > On Fri, Jul 22, 2016 at 2:47 PM, Matthias Wessendorf > wrote: > >> Hello, >> >> for releasing the 3.0.1 version of AGDroid Pipe, I have staged the lib >> here: >> >> https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-8667/ >> >> Let me know about your tests, and I will click the magic release button >> early next week! >> >> -M >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> twitter: http://twitter.com/mwessendorf >> > > > > -- > 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 > -- -- Passos -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20160727/006b0c9c/attachment.html From matzew at apache.org Wed Jul 27 10:13:34 2016 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 27 Jul 2016 16:13:34 +0200 Subject: [aerogear-dev] AeroGear Pipe - staging repo for 3.0.1 release In-Reply-To: References: Message-ID: done! On Wed, Jul 27, 2016 at 4:01 PM, Daniel Passos wrote: > I have tested it. I think we can push the release button ;) > > On Fri, Jul 22, 2016 at 10:02 AM, Matthias Wessendorf > wrote: > >> nope ... it's 3.1.0 :-) >> >> >> >> https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-8668/ >> >> >> >> >> On Fri, Jul 22, 2016 at 2:47 PM, Matthias Wessendorf >> wrote: >> >>> Hello, >>> >>> for releasing the 3.0.1 version of AGDroid Pipe, I have staged the lib >>> here: >>> >>> https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-8667/ >>> >>> Let me know about your tests, and I will click the magic release button >>> early next week! >>> >>> -M >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> twitter: http://twitter.com/mwessendorf >>> >> >> >> >> -- >> 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 >> > > > > -- > -- Passos > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20160727/95e8a894/attachment.html From idel.pivnitskiy at gmail.com Wed Jul 27 16:06:47 2016 From: idel.pivnitskiy at gmail.com (Idel Pivnitskiy) Date: Wed, 27 Jul 2016 23:06:47 +0300 Subject: [aerogear-dev] Test time out: TestTriggerMetricCollectionRedelivery.testTransactedRedelivery Message-ID: One of my PRs failed to build with test time out error: TestTriggerMetricCollectionRedelivery.testTransactedRedelivery The link to the Travis build: https://travis-ci.org/aerogear/aerogear-unifiedpush-server/builds/147625096 Another build attempt with the same code base finished successfully: https://travis-ci.org/aerogear/aerogear-unifiedpush-server/builds/147625137 Who can take a look at this? Best regards, Idel Pivnitskiy -- Twitter: @idelpivnitskiy GitHub: @idelpivnitskiy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20160727/7996873d/attachment.html From idel.pivnitskiy at gmail.com Wed Jul 27 20:13:22 2016 From: idel.pivnitskiy at gmail.com (Idel Pivnitskiy) Date: Thu, 28 Jul 2016 03:13:22 +0300 Subject: [aerogear-dev] Firefox Push API with UnifiedPush Server In-Reply-To: References: Message-ID: 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 GitHub: @idelpivnitskiy On Tue, Jul 26, 2016 at 1:48 PM, Idel Pivnitskiy 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 > GitHub: @idelpivnitskiy > > On Tue, Jul 26, 2016 at 1:16 PM, Matthias Wessendorf > 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 >>> GitHub: @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 >>>> GitHub: @idelpivnitskiy >>>> >>>> On Mon, Jul 25, 2016 at 4:25 PM, Luke Holmquist >>>> 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 >>>>>> GitHub: @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 From matzew at apache.org Thu Jul 28 00:49:26 2016 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 28 Jul 2016 06:49:26 +0200 Subject: [aerogear-dev] Firefox Push API with UnifiedPush Server In-Reply-To: References: Message-ID: yay! On Thu, Jul 28, 2016 at 2:13 AM, Idel Pivnitskiy wrote: > 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 > GitHub: @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 >> GitHub: @idelpivnitskiy >> >> On Tue, Jul 26, 2016 at 1:16 PM, Matthias Wessendorf >> 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 >>>> GitHub: @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 >>>>> GitHub: @idelpivnitskiy >>>>> >>>>> On Mon, Jul 25, 2016 at 4:25 PM, Luke Holmquist >>>>> 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 >>>>>>> GitHub: @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 >>> >> >> > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20160728/612130ce/attachment.html From jsalvobr at redhat.com Wed Jul 27 18:17:32 2016 From: jsalvobr at redhat.com (jsalvobr) Date: Wed, 27 Jul 2016 15:17:32 -0700 (MST) Subject: [aerogear-dev] Push with AeroGear SimplePush/UnifiedPush in JBoss PROBLEM Message-ID: <1469657852445-12664.post@n5.nabble.com> I followed step by step the following guide https://aerogear.org/docs/unifiedpush/aerogear-push-js/guides/#simplepush-server, Simple Push installing Server https://github.com/aerogear/aerogear-simplepush-server/tree/master/wildfly-module and aerogear-unifiedpush-server-1.1.3.Final con Postgresql. When run the client js quickstart is register successfully. but by submitting a notification, this does not arrive at customer, missing the notification message: Environment: - Local Environment, based EAP 6.4. - UnifiedPush Server: unifiedpush-auth-server.war and unifiedpush-server-as7.war deployed to Jboss. - Local Customer js "simplepush-unifiedpush-example.tar.gz" from https://github.com/aerogear/aerogear-js-cookbook/tree/master/simplepush-unifiedpush-example. Thanks. -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/Push-with-AeroGear-SimplePush-UnifiedPush-in-JBoss-PROBLEM-tp12664.html Sent from the aerogear-dev mailing list archive at Nabble.com. From matzew at apache.org Thu Jul 28 05:23:21 2016 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 28 Jul 2016 11:23:21 +0200 Subject: [aerogear-dev] Push with AeroGear SimplePush/UnifiedPush in JBoss PROBLEM In-Reply-To: <1469657852445-12664.post@n5.nabble.com> References: <1469657852445-12664.post@n5.nabble.com> Message-ID: Hello there, I am not really sure wha't the state on SimplePush, it has not been a topic for over a year - I think we will soon deprecate it (meaning the Server and SimplePush in UPS). Also not sure on that example :-( On Thu, Jul 28, 2016 at 12:17 AM, jsalvobr wrote: > I followed step by step the following guide > > https://aerogear.org/docs/unifiedpush/aerogear-push-js/guides/#simplepush-server > , > Simple Push installing Server > > https://github.com/aerogear/aerogear-simplepush-server/tree/master/wildfly-module > and aerogear-unifiedpush-server-1.1.3.Final con Postgresql. > > When run the client js quickstart is register successfully. but by > submitting a notification, this does not arrive at customer, missing the > notification message: > > > > Environment: > - Local Environment, based EAP 6.4. > - UnifiedPush Server: unifiedpush-auth-server.war and > unifiedpush-server-as7.war deployed to Jboss. > - Local Customer js "simplepush-unifiedpush-example.tar.gz" from > > https://github.com/aerogear/aerogear-js-cookbook/tree/master/simplepush-unifiedpush-example > . > > Thanks. > > > > > > -- > View this message in context: > http://aerogear-dev.1069024.n5.nabble.com/Push-with-AeroGear-SimplePush-UnifiedPush-in-JBoss-PROBLEM-tp12664.html > Sent from the aerogear-dev mailing list archive at Nabble.com. > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20160728/912bd5be/attachment.html