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

[Stefan Miklosovic]

Sure, the first round can be only about installations, I wrote that in context of your initial e-mail: 

" Import/Export for Variants will maybe come later but due to some security issues (mainly for iOS cert/passphrase) it's on hold. " 

"we wont't do Variant export/import" does not seem the same thing as "it's on hold and maybe come later" to me :) 

Stefan Miklosovic 
Red Hat Brno - JBoss Mobile Platform 

e-mail: smikloso at redhat.com 
irc: smikloso 

----- Original Message -----

> We won't do Variant export/import

> On Wed, Nov 12, 2014 at 11:31 AM, Stefan Miklosovic < smikloso at redhat.com >
> wrote:

> > Two more comments which come to my mind and are quite technical.
> 

> > 1) When you export Variant into JSON and you want to import it again, you
> > fail to do so at this moment because Variant is abstract class and JSON
> > unmarshaller do not know to which class it should be cast. Because of that
> > we have to change model of Variant to add this on it (1). Maybe there is
> > another option how to do that (e.g. according to some field in Variant and
> > write custom JSON unmarshaller).
> 

> > 2) We have similar issue with VariantType, it fails to unmarshall at this
> > moment without this modification (2)
> 

> > (1)
> > https://github.com/smiklosovic/aerogear-unifiedpush-server/blob/f7fe2f5f58a8882aa5a3362d07a208c37b0d4403/model/api/src/main/java/org/jboss/aerogear/unifiedpush/api/Variant.java#L28
> 
> > (2)
> > https://github.com/smiklosovic/aerogear-unifiedpush-server/blob/f7fe2f5f58a8882aa5a3362d07a208c37b0d4403/model/api/src/main/java/org/jboss/aerogear/unifiedpush/api/VariantType.java#L61-L69
> 

> > Stefan Miklosovic
> 
> > Red Hat Brno - JBoss Mobile Platform
> 

> > e-mail: smikloso at redhat.com
> 
> > irc: smikloso
> 

> > > 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. 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. 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",
> > 
> 
> > > ...
> > 
> 
> > > },
> > 
> 
> > > ...
> > 
> 
> > > ]
> > 
> 
> > > 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. Output format
> > 
> 

> > > How should provide the exported data ? I need your input here 1. Raw Json
> > > ?
> > > 2. Json file ? 3. Zip / tarball ? 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 :
> > 
> 

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

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