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

Looks good. Should the export button be different colour than red perhaps? Perhaps we can just put the focus on the cancel button instead or something like that.

On 17 November 2014 14:55, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: > Hi, > I started to implement the "export" feature : > > - https://github.com/aerogear/aerogear-unifiedpush-server/pull/435 > > Also a really short screencast showing how it works : > https://www.youtube.com/watch?v=HFXesTHh4PM&feature=youtu.be > > > > On Thu, Nov 13, 2014 at 2:52 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; > wrote: > >> >> >> On Wed, Nov 12, 2014 at 12:36 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; >> wrote: >> >>> >>> >>> On Wed, Nov 12, 2014 at 11:15 AM, Stefan Miklosovic < >>> smikloso(a)redhat.com&gt; wrote: >>> >>>> Hi, >>>> >>>> >>>> I have two comments. The first one is about JSON export of an >>>> Installation. You declare it is like this when it comes to categories: >>>> >>>> >>>> "categories" : ["football", "sport"] >>>> >>>> >>>> However, with the current UPS of version 1.0.2, when you register some >>>> installation, it returns you this >>>> https://issues.jboss.org/browse/AGPUSH-1093 >>>> >>>> >>>> This issue should be addressed and since exporting of installations >>>> more or less means to marshall them into JSON, you hit this issue for sure >>>> so model should be updated to return only array of category names instead >>>> of its JSON representation. >>>> >>> Ok good catch, I will keep this ticket in mind >>> >>>> >>>> The second comment is about security. I am begging you here from QA >>>> team to make it doable via REST and not (only) via UPS console because it >>>> simplifies tons of hacking around the code. Right now we are doing whole >>>> import by adding custom JAX-RS endpoints on top of UPS, we generate >>>> applications, variants and installations randomly as JSONs and send them to >>>> UPS to these batch endpoints and we are calling services to persist them. >>>> >>> I know, for now you can access it through rest, but tbh I want to have >>> the security expert feedback on this and if we decide it's too insecure we >>> will have to change it >>> >> >> So I have been thinking more on this and sorry Stefan, I think we will >> not allow export using basic auth , it;s to insecure, just with >> variantId/variantSecret someone would be able to retrieve all the device >> tokens. >> >> >> >>>> You can find it here (1) >>>> >>>> >>>> In case this would be done via REST, it would be no-brainer and huge >>>> time saver for QA guys. >>>> >>>> >>>> (1) >>>> https://github.com/smiklosovic/aerogear-unifiedpush-server/commit/f7fe2f5... >>>> >>>> Thanks >>>> >>>> Stefan Miklosovic >>>> Red Hat Brno - JBoss Mobile Platform >>>> >>>> e-mail: smikloso(a)redhat.com >>>> irc: smikloso >>>> >>>> ------------------------------ >>>> >>>> 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. >>>> >>>> <https://gist.github.com/sebastienblanc/b863b80380f8ed16ad7b#output-format... >>>> format >>>> >>>> How should provide the exported data ? I need your input here 1. Raw >>>> Json ? 2. Json file ? 3. Zip / tarball ? >>>> <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. For export, the user just have to press an >>>> export button >>>> >>>> <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. >>>> >>>> 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* >>>> >>>> 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 >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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