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

On Sat, Nov 22, 2014 at 7:06 PM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > Nice! But your previous screencasts had better sound! ;) > > Question: why does it say 2 installations before the import? > Ouch ! I was so much focused on the number of installations just below that I did not noticed that one. I have to check if this has been introduced with this or if it was already there before. (I think something is hanging in the scope) > > 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 >>> > 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 > _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev