I'd say make STAGING default and enforce developers to upload the
certificate again if she wants to use the same certificate.
Or maybe an option which says cert-prod.blah - staging/prod. From my
understanding if it defaults to production, we can motivate people to
mistakes in production with a valid certificate. Developers should be
aware of test it before push anything to production.
Is just my perspective.
Matthias Wessendorf wrote:
BTW.... when creating the iOS varian....
developmentCertificate/Passphrase and productionCertificate/Passphrase
are the new Formular Values....... (needs to be updated)
-M
On Tue, Jul 9, 2013 at 6:41 PM, Matthias Wessendorf <matzew(a)apache.org
<mailto:matzew@apache.org>> wrote:
Hi,
I pushed an early version of it to [1]. It's a branch, not (yet) a PR.
Basically here is a how the payloads MIGHT look like:
Broadcast Payload:
{
"alert":"HELLO!",
"sound":"default",
"staging":"development",
"badge":7,
"simple-push":"version=123",
"someKey":"some value",
"anotherCustomKey":"some other value"
}
Selective Send Payload:
{
"alias" : ["user(a)account.com <mailto:user@account.com>",
"someone(a)aerogear.org <mailto:someone@aerogear.org>", ....],
"deviceType" : ["iPad", "AndroidTablet"],
"staging":"development",
"message": {
"alert":"HELLO!",
"sound":"default",
"badge":7,
"someKey":"some value",
"anotherCustomKey":"some other value"
},
"simple-push": {
"SomeCategory":"version=123",
"anotherCategory":"version=456"
}
}
Note: if the "staging" is NOT present, the PRODUCTION cert. (if
present) will be used. If no cert is present ..... a WARNING is
logged...
Also,..... only on iOS....
-Matthias
[1]
https://github.com/aerogear/aerogear-unified-push-server/tree/ProdCerts
On Tue, Jul 9, 2013 at 2:40 PM, Matthias Wessendorf
<matzew(a)apache.org <mailto:matzew@apache.org>> wrote:
On Tue, Jul 9, 2013 at 2:21 PM, Matthias Wessendorf
<matzew(a)apache.org <mailto:matzew@apache.org>> wrote:
On Tue, Jul 9, 2013 at 2:14 PM, Kris Borchers
<kris(a)redhat.com <mailto:kris@redhat.com>> wrote:
On Jul 9, 2013, at 7:09 AM, Matthias Wessendorf
<matzew(a)apache.org <mailto:matzew@apache.org>> wrote:
>
>
>
> On Tue, Jul 9, 2013 at 2:04 PM, Kris Borchers
> <kris(a)redhat.com <mailto:kris@redhat.com>> wrote:
>
>
> On Jul 9, 2013, at 6:56 AM, Matthias Wessendorf
> <matzew(a)apache.org <mailto:matzew@apache.org>>
wrote:
>
>> They could have a "test" variant :) I'd hate
to
>> expose something like "prod/dev" to the sender,
>> especially since that is ONLY iOS :)
>
> I guess a test variant would do the job. I'm good
> either way on that. Probably another thing that
> would need clear documentation.
>
>
> I guess having a "staging" : "production" (or
> "development") is also not a bad thing (helps,
> perhaps, already for AGPUSH-113.
>
>
> What would the default be ? My current feeling is that
> "production" is always used, unless "staging" :
> "development" is included on the Sender API ?
+1 for production default
In that case, no "isProd()" is needed :-)
I mean generally, if both can be "active" (we would just check
if cert/passphrase is present)
>
>
> -Matthias
>
>
>
>>
>> However, on the long run... you can have a TEST
>> PushEE server + a "production" one (AGPUSH-113)
>>
>>
>> On Tue, Jul 9, 2013 at 1:50 PM, Kris Borchers
>> <kris(a)redhat.com <mailto:kris@redhat.com>>
wrote:
>>
>>
>> On Jul 9, 2013, at 6:47 AM, Lucas Holmquist
>> <lholmqui(a)redhat.com
>> <mailto:lholmqui@redhat.com>> wrote:
>>
>>> Sounds good.
>>>
>>> but i wonder if there would be a case where
>>> both could be active at the same time.
>>>
>>> for example, some company has an app that
>>> is in production, now they need to make
>>> some modifications to it and want to make
>>> sure that they didn't break their push
>>> notifications, so they want to send some
>>> push notifications to the development
>>> version since they have separate development
>>> devices.
>>>
>>> probably an edge case
>>
>> Hmmm. I'm not sure how edge that is. Seems
>> like the appropriate development model to be
>> able to test a change while keeping the
>> production version running. I think this is a
>> good case for being able to have both active
>> and would require the ability to distinguish
>> between the two in the Sender API.
>>
>>>
>>>
>>> On Jul 9, 2013, at 7:25 AM, Kris Borchers
>>> <kris(a)redhat.com
<mailto:kris@redhat.com>>
>>> wrote:
>>>
>>>> That all seems sane to me. +1
>>>>
>>>> On Jul 9, 2013, at 3:57 AM, Matthias
>>>> Wessendorf <matzew(a)apache.org
>>>> <mailto:matzew@apache.org>> wrote:
>>>>
>>>>> Hello!
>>>>>
>>>>> right now the iOS variant does _only_
>>>>> support upload of an "Development SSL
>>>>> Certificate" (see [1]). I'd like to
add
>>>>> support for an "Production SSL
>>>>> Certificate" to the iOS Variant model
class.
>>>>>
>>>>> Besides the second certificate, the model
>>>>> class _should_ have a field to reflect the
>>>>> status (is production or not ->
>>>>> isProduction()), so that only one
>>>>> certificate is ACTIVE. Internally the
>>>>> "Sender API" would connect against
the
>>>>> differen Apple servers (prod. verus dev),
>>>>> based on the value of the isProduction()
>>>>> method.
>>>>>
>>>>> Exposing "production" (or
"development")
>>>>> on the Sender API would be really ugly.
>>>>> With the above said, the Sender-API
>>>>> remains stable.
>>>>>
>>>>> The value of "isProduction" would
be
>>>>> updateable on the AdminUI (and the
>>>>> underlying RESTful endpoints).
>>>>>
>>>>> -Matthias
>>>>>
>>>>> [1]
>>>>>
https://github.com/aerogear/aerogear-unified-push-server/blob/master/src/...
>>>>>
>>>>>
>>>>> --
>>>>> Matthias Wessendorf
>>>>>
>>>>> blog:
http://matthiaswessendorf.wordpress.com/
>>>>> sessions:
>>>>>
http://www.slideshare.net/mwessendorf
>>>>> twitter:
http://twitter.com/mwessendorf
>>>>>
_______________________________________________
>>>>> aerogear-dev mailing list
>>>>> aerogear-dev(a)lists.jboss.org
>>>>> <mailto:aerogear-dev@lists.jboss.org>
>>>>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev(a)lists.jboss.org
>>>> <mailto:aerogear-dev@lists.jboss.org>
>>>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev(a)lists.jboss.org
>>> <mailto:aerogear-dev@lists.jboss.org>
>>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> <mailto:aerogear-dev@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
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> <mailto:aerogear-dev@lists.jboss.org>
>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> <mailto:aerogear-dev@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
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>
>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
<mailto:aerogear-dev@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
--
Matthias Wessendorf
blog:
http://matthiaswessendorf.wordpress.com/
sessions:
http://www.slideshare.net/mwessendorf
twitter:
http://twitter.com/mwessendorf
--
Matthias Wessendorf
blog:
http://matthiaswessendorf.wordpress.com/
sessions:
http://www.slideshare.net/mwessendorf
twitter:
http://twitter.com/mwessendorf
--
Matthias Wessendorf
blog:
http://matthiaswessendorf.wordpress.com/
sessions:
http://www.slideshare.net/mwessendorf
twitter:
http://twitter.com/mwessendorf
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev