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

Hey Sebi, That is likely caused by counter that is not updated when variant is removed, I've noticed that and fixed before in https://github.com/sebastienblanc/aerogear-unified-push-server/pull/3 On Sat, Nov 22, 2014 at 7:57 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: > > > 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&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 >>>>> > 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 > _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev