[aerogear-dev] iOS Variant: Support for Production/Distribution SSL Certificates

Matthias Wessendorf matzew at apache.org
Wed Jul 10 09:13:28 EDT 2013


On Wed, Jul 10, 2013 at 2:56 PM, Bruno Oliveira <bruno at abstractj.org> wrote:

> I'd say make STAGING default and enforce developers to upload the
> certificate again if she wants to use the same certificate.
>

they can't.  Apple generates different CERTs for the production/sandbox
systems. That's why we have upload for both:
devCert/devPassPhrase and prodCert/prodPassphrase



> 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.
>

So, if both certificates are active, the suggested default would be use the
"development" environment, right ?

I understand that :-) And it's what Rails does as well :)

However, with two active CERTs (prod and dev) I am not sure if it is nice
to "require" the inclusion of "staging":"production" inside of the payload,
when sending to production.

-Matthias




>
> 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
>
> _______________________________________________
> 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/20130710/aa6f72ec/attachment-0001.html 


More information about the aerogear-dev mailing list