[aerogear-dev] cordova push plugin simplification

[Matthias Wessendorf]

On Thu, Feb 27, 2014 at 9:40 AM, Erik Jan de Wit <edewit at redhat.com> wrote:

> Hi,
>
> I was still thinking about those 2 last points (last night while baking
> pancakes) it seems that we can't make it optimal. So I would propose to do
> something like this:
>
> push.register(function(event) {
>   alert(event.alert);
> },
> function(error) {
>   throw error;
> }, {
>     pushServerURL: "<pushServerURL e.g http(s)//host:port/context >",
>     alias: "<alias e.g. a username or an email address optional>",
>     android: {
>       senderID: "<senderID e.g Google Project ID only for android>",
>       variantID: "<variantID e.g. 1234456-234320>",
>       variantSecret: "<variantSecret e.g. 1234456-234320>",
>     },
>     ios: {
>       variantID: "<variantID e.g. 1234456-234320>",
>       variantSecret: "<variantSecret e.g. 1234456-234320>",
>     }
> });
>
> Instead of leaving it to the user to find some sort of way to deal with
> the 2 variants we supply him with a way to configure both. On iOS the
> plugin will use the iOS part of the config and on android the android part
> plus a generic part.
>


I like that android/iOS config object!




>
> And if you cordova app is only for one device maybe we could support this
> as well:
>
> push.register(function(event) {
>   alert(event.alert);
> },
> function(error) {
>   throw error;
> }, {
>     pushServerURL: "<pushServerURL e.g http(s)//host:port/context >",
>     alias: "<alias e.g. a username or an email address optional>",
>     senderID: "<senderID e.g Google Project ID only for android>",
>     variantID: "<variantID e.g. 1234456-234320>",
>     variantSecret: "<variantSecret e.g. 1234456-234320>"
> });
>
> This will just take the variantID and secret that are on the 'root' level
> regardless of the device type, so it would only work on one. But maybe this
> will confuse people again.
>

perhaps :)


>
> WDYT,
> Erik Jan
>
>
>
>> Till now all these changes can be made on the plugin, but we could take
>> it even further. Two things that are still platform dependent the senderId
>> and the variantID/secret. Now senderId is 'known' by UPS so why do we need
>> to specify it here? We could make senderId part of the response when
>> registering a device on UPS then the client doesn't need to specify it and
>> all configuration is in one place.
>>
>
> It's optional on UPS, as only really Android clients need it. And I think
> originally Luke just added the 'senderID' to UPS for having something handy
> (copy/paste usage).
>
> So, I am not sure on that one, as that means we now have to enforce
> Android Variants always get the senderID attribute. Could be done, yes, but
> I am not sure.
>
>
>
> Hmm, right it's optional then this maybe not the greatest idea
>
>
>> That leaves variantID/secret and that is the boldest proposal. How about
>> we make it possible to register for an application instead for a specific
>> variant? Then based on the meta information (deviceType, operatingSystem
>> and osVersion) we choose the right variant.
>>
>
> -1
>
> we should never 'deploy' the masterSecret and the applicationID on
> clients. If that information is stolen (easy on devices), you can start
> sending dirty assaults to ALL the devices for that application. Same w/ all
> the different providers like Parse, Stackmob etc: they all use a
> MasterKey/Password for the actual send. And they _highly_ recommend NOT
> applying that to the clients (it's easy to leak that information)
>
>
> Right didn't think about that, this together with the objections that
> Sebastien has makes this a definite no go.
>
>
> _______________________________________________
> 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/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140228/09270461/attachment.html