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

FYI a quick screencast and preview of the Import feature ! import UPS installations <https://www.youtube.com/watch?v=Kw7JOkVHVCY&feature=youtu.be> Have a nice weekend ! Sebi On Thu, Nov 20, 2014 at 10:35 AM, Sebastien Blanc <scm.blanc(a)gmail.com <javascript:_e(%7B%7D,'cvml','scm.blanc@gmail.com');>> wrote: > > > On Wed, Nov 19, 2014 at 3:57 PM, Matthias Wessendorf <matzew(a)apache.org > <javascript:_e(%7B%7D,'cvml','matzew@apache.org');>> wrote: > >> Late, but better than never. >> >> comments inline >> >> On Tue, Nov 11, 2014 at 2:12 PM, Sebastien Blanc <scm.blanc(a)gmail.com >> <javascript:_e(%7B%7D,'cvml','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. >>> <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 >>> <javascript:_e(%7B%7D,'cvml','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(a)lists.jboss.org >> <javascript:_e(%7B%7D,'cvml','aerogear-dev@lists.jboss.org');> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > >