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

[Sebastien Blanc]

We won't do Variant export/import

On Wed, Nov 12, 2014 at 11:31 AM, Stefan Miklosovic <smikloso at redhat.com>
wrote:

> Two more comments which come to my mind and are quite technical.
>
> 1) When you export Variant into JSON and you want to import it again, you
> fail to do so at this moment because Variant is abstract class and JSON
> unmarshaller do not know to which class it should be cast. Because of that
> we have to change model of Variant to add this on it (1). Maybe there is
> another option how to do that (e.g. according to some field in Variant and
> write custom JSON unmarshaller).
>
> 2) We have similar issue with VariantType, it fails to unmarshall at this
> moment without this modification (2)
>
> (1)
> https://github.com/smiklosovic/aerogear-unifiedpush-server/blob/f7fe2f5f58a8882aa5a3362d07a208c37b0d4403/model/api/src/main/java/org/jboss/aerogear/unifiedpush/api/Variant.java#L28
> (2)
> https://github.com/smiklosovic/aerogear-unifiedpush-server/blob/f7fe2f5f58a8882aa5a3362d07a208c37b0d4403/model/api/src/main/java/org/jboss/aerogear/unifiedpush/api/VariantType.java#L61-L69
>
> Stefan Miklosovic
> Red Hat Brno - JBoss Mobile Platform
>
> e-mail: smikloso at 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-service>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",
>      ...
>    },
>    ...
>  ]
>
>
> <https://gist.github.com/sebastienblanc/b863b80380f8ed16ad7b#export-service>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.
> <https://gist.github.com/sebastienblanc/b863b80380f8ed16ad7b#output-format>Output
> 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/94f19f69e50a217e89363aefe52912c9b33f6355/687474703a2f2f7331352e706f7374696d672e6f72672f6779626b72737a73622f696d706f72746578706f72742e706e67>
>
> 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-issues>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 ?
> <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/importer/index.html
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20141112/f7a90836/attachment.html