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

Nice! But your previous screencasts had better sound! ;) Question: why does it say 2 installations before the import?

On Saturday, November 22, 2014, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: > 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&gt; > wrote: > >> >> >> 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 >>> >> >> > -- Sent from Gmail Mobile _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev