[aerogear-dev] [UPS] Import/Export of installations

Sebastien Blanc scm.blanc at gmail.com
Wed Nov 12 05:48:37 EST 2014


On Wed, Nov 12, 2014 at 8:01 AM, Bruno Oliveira <bruno at abstractj.org> wrote:

> Not against JSON, but maybe worth to take a look at http://msgpack.org/

hum interesting as well, indeed worth a look

>
>
> On 2014-11-11, Lukáš Fryč wrote:
> > On Tue, Nov 11, 2014 at 2:12 PM, Sebastien Blanc <scm.blanc at gmail.com>
> > wrote:
> >
> > > Hi,
> > >
> > > I would like to start a discussion around the import/export of
> > > installations in UPS. To track all the tasks, we have a ticket[1] also
> > > containing some sub-tasks.
> > > <https://gist.github.com/sebastienblanc/b863b80380f8ed16ad7b#scope
> >Scope
> > >
> > > For now we stick to installations, meanning we can import or export
> > > installations from a particular Variant. Import/Export for Variants
> will
> > > maybe come later but due to some security issues (mainly for iOS
> > > cert/passphrase) it's on hold.
> > >
> > > <
> https://gist.github.com/sebastienblanc/b863b80380f8ed16ad7b#import-service
> >Import
> > > Service
> > >
> > > That's an easy one ;) since the service already exist [2]. It's a REST
> > > service and it uses the VariantId/Secret combination to authenticate.
> > >
> > > Data format looks like :
> > >
> > > [
> > >    {
> > >      "deviceToken" : "someTokenString",
> > >      "deviceType" : "iPad",
> > >      "operatingSystem" : "iOS",
> > >      "osVersion" : "6.1.2",
> > >      "alias" : "someUsername or email adress...",
> > >      "categories" : ["football", "sport"]
> > >    },
> > >    {
> > >      "deviceToken" : "someOtherTokenString",
> > >      ...
> > >    },
> > >    ...
> > >  ]
> > >
> > >
> > > <
> https://gist.github.com/sebastienblanc/b863b80380f8ed16ad7b#export-service
> >Export
> > > Service
> > >
> > > Like import, it will use the variantId/secret combo to authenticate and
> > > retrieve the right variant to export the installations. The data
> structure
> > > format would of course looks like the one used for import.
> > > <
> https://gist.github.com/sebastienblanc/b863b80380f8ed16ad7b#output-format
> >Output
> > > format
> > >
> > > How should provide the exported data ? I need your input here 1. Raw
> Json
> > > ? 2. Json file ? 3. Zip / tarball ?
> > >
> >
> > Gzipped json file download sounds as easily accessible for browsers.
> >
> > > <https://gist.github.com/sebastienblanc/b863b80380f8ed16ad7b#ui>UI
> > >
> > > UI should be a *nice to have*
> > >
> > > I would suggest to add 2 items (import and export) in the contextual
> menu
> > > that you can see in this screenshot :
> > >
> > >
> > > <
> https://camo.githubusercontent.com/94f19f69e50a217e89363aefe52912c9b33f6355/687474703a2f2f7331352e706f7374696d672e6f72672f6779626b72737a73622f696d706f72746578706f72742e706e67
> >
> > >
> > > For import, the user will have a file input and feedback on how many
> > > installations were imported. For export, the user just have to press an
> > > export button
> > >
> >
> > +1 sounds good, we just need to decide whether block the user when
> > uploading / downloading
> >
> > I guess:
> >
> > a) downloading - do not block UI, downloading is a separate activity
> > b) uploading - block the UI, offer progress and error indication and
> > ability to cancel the process (transactional? - cancelling means no
> > installation is imported?)
> >
> >
> > >
> > > <
> https://gist.github.com/sebastienblanc/b863b80380f8ed16ad7b#migration-issues
> >Migration
> > > issues
> > >
> > > So, that is a very important point that I would like to discuss. Even
> if
> > > we are able to import installations, the *variantID_ and the
> > > __variantSecret* will not match with those that are in the Clients.
> > >
> > > Imagine the following scenario : I export 15000 installations, my
> > > datacenter burns, I create a new UPS instance, with a new Push App and
> a
> > > new Variant (so new VariantID and VariantSecret), then I inport the
> > > installations. Well, my 15000 clients will point to the wrong variant.
> For
> > > sure, they can be updated but that might not always be an option.
> > >
> > > That is why I would like suggest the following change : Make
> *VariantId*
> > >  and *VariantSecret* editable, so after someone has done an import he
> can
> > > change the values of the variants so it matches the clients.
> > >
> > > I know we had this discussion before, but in the future we might want
> to
> > > change the naming around VariantId and VariantSecret, to me it sounds
> more
> > > like *variantAPIKey* / *variantAPISecret*
> > >
> > > wdyt ?
> > > <https://gist.github.com/sebastienblanc/b863b80380f8ed16ad7b#security>
> > > Security
> > >
> > > As said before, import/export uses variantId/variantSecret to
> > > authenticate. So if someone has access to these keys he could make a
> > > malicious import of 500k installations. What should we do for that ? We
> > > could give this access only to authenticated "console" users but then
> it
> > > would be hard to expose import/export as rest service (because of KC
> > > implication)
> > >
> > > Please comment, ask questions , be crazy ...
> > >
> > > Sebi
> > >
> > > [1] https://issues.jboss.org/browse/AGPUSH-978
> > >
> > > [2]
> > >
> http://aerogear.org/docs/specs/aerogear-unifiedpush-rest/registry/device/importer/index.html
> > >
> > > _______________________________________________
> > > 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
>
>
> --
>
> abstractj
> PGP: 0x84DC9914
> _______________________________________________
> 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/20141112/1e01090d/attachment.html 


More information about the aerogear-dev mailing list