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

On Wed, Nov 19, 2014 at 3:57 PM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > Late, but better than never. > > comments inline > > On Tue, Nov 11, 2014 at 2:12 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; > 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-servic... >> 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-servic... >> 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 > > > >> <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/94f19f69e50a217e89363aefe52912c9b33f63... >> >> 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 > > >> >> <https://gist.github.com/sebastienblanc/b863b80380f8ed16ad7b#migration-iss... >> 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 ? >> <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/... >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev >