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

On 2014-11-12, Stefan Miklosovic 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. > > 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 think it has nothing to do with security, it pretty much stands for ther requirements on UPS. Also, like you mentioned is no-brainer to enable it on KC admin see: http://docs.jboss.org/keycloak/docs/1.0-beta-3/userguide/html/direct-acce...

We're just enabling something that we don't want to see enabled in production and people can do it by themselves. > 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 > > ----- Original Message ----- > > > 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. 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. Import 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", > > ... > > }, > > ... > > ] > > Export 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. Output format > > > How should provide the exported data ? I need your input here 1. Raw Json > > ? > > 2. Json file ? 3. Zip / tarball ? 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 : > > > 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 Migration 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 ? 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 -- abstractj PGP: 0x84DC9914 _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev