[aerogear-dev] iOS Variant: Support for Production/Distribution SSL Certificates
Bruno Oliveira
bruno at abstractj.org
Wed Jul 10 08:56:46 EDT 2013
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 at apache.org
> <mailto:matzew at 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 at account.com <mailto:user at account.com>",
> "someone at aerogear.org <mailto:someone at 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 at apache.org <mailto:matzew at apache.org>> wrote:
>
>
>
>
> On Tue, Jul 9, 2013 at 2:21 PM, Matthias Wessendorf
> <matzew at apache.org <mailto:matzew at apache.org>> wrote:
>
>
>
>
> On Tue, Jul 9, 2013 at 2:14 PM, Kris Borchers
> <kris at redhat.com <mailto:kris at redhat.com>> wrote:
>
>
> On Jul 9, 2013, at 7:09 AM, Matthias Wessendorf
> <matzew at apache.org <mailto:matzew at apache.org>> wrote:
>
>>
>>
>>
>> On Tue, Jul 9, 2013 at 2:04 PM, Kris Borchers
>> <kris at redhat.com <mailto:kris at redhat.com>> wrote:
>>
>>
>> On Jul 9, 2013, at 6:56 AM, Matthias Wessendorf
>> <matzew at apache.org <mailto:matzew at 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 at redhat.com <mailto:kris at redhat.com>> wrote:
>>>
>>>
>>> On Jul 9, 2013, at 6:47 AM, Lucas Holmquist
>>> <lholmqui at redhat.com
>>> <mailto:lholmqui at 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 at redhat.com <mailto:kris at redhat.com>>
>>>> wrote:
>>>>
>>>>> That all seems sane to me. +1
>>>>>
>>>>> On Jul 9, 2013, at 3:57 AM, Matthias
>>>>> Wessendorf <matzew at apache.org
>>>>> <mailto:matzew at 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/main/java/org/jboss/aerogear/connectivity/model/iOSVariant.java#L38-L41
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Matthias Wessendorf
>>>>>>
>>>>>> blog: http://matthiaswessendorf.wordpress.com/
>>>>>> sessions:
>>>>>> http://www.slideshare.net/mwessendorf
>>>>>> twitter: http://twitter.com/mwessendorf
>>>>>> _______________________________________________
>>>>>> aerogear-dev mailing list
>>>>>> aerogear-dev at lists.jboss.org
>>>>>> <mailto:aerogear-dev at lists.jboss.org>
>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>
>>>>> _______________________________________________
>>>>> aerogear-dev mailing list
>>>>> aerogear-dev at lists.jboss.org
>>>>> <mailto:aerogear-dev at lists.jboss.org>
>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev at lists.jboss.org
>>>> <mailto:aerogear-dev at lists.jboss.org>
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> <mailto: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
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> <mailto:aerogear-dev at lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> <mailto: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
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> <mailto:aerogear-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> <mailto: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
>
>
>
>
> --
> 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
abstractj
More information about the aerogear-dev
mailing list