On Wed, Nov 19, 2014 at 3:57 PM, Matthias Wessendorf <matzew@apache.org> wrote:

Late, but better than never.

comments inline

On Tue, Nov 11, 2014 at 2:12 PM, Sebastien Blanc <scm.blanc@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.

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.

+1

not sure it needs to be pretty :) I am fine with having this {{{{.....a gazillion clients}}}} 

Yeah it's unformatted now (and will stay so) 

Output format

How should provide the exported data ? I need your input here 1. Raw Json ? 2. Json file ? 3. Zip / tarball ?

I saw we do gzip and JSON. +1 on that

 

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.

a dialog simliar to variant creation. should have some validation checks 

 

For export, the user just have to press an export button

+1

 

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.

-1 on making the variantID and secret editable for everyone.

Let's have that only being done by the push admin. Also, we need to make sure the ID/Secret is a valid UUID. Otherwise, lazy folks will go with foo:bar ... but... well :) if one really does that... it's not our fault. but yeah, let's make sure the admin can edit, and use UUID.

Fair enough, let's discuss that in a different PR once inport/export has been delivered 

 

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

YES! But, let's please do that on a different PR !

 

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@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev