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

Sebastien Blanc scm.blanc at gmail.com
Tue Nov 25 02:56:07 EST 2014


On Tue, Nov 11, 2014 at 5:08 PM, Lukáš Fryč <lukas.fryc at gmail.com> wrote:

>
>
> On Tue, Nov 11, 2014 at 2:12 PM, Sebastien Blanc <scm.blanc at 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-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 ?
>>
>
> Gzipped json file download sounds as easily accessible for browsers.
>
>> <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
>>
>
> +1 sounds good, we just need to decide whether block the user when
> uploading / downloading
>
> I guess:
>
> a) downloading - do not block UI, downloading is a separate activity
> b) uploading - block the UI, offer progress and error indication and
> ability to cancel the process (transactional? - cancelling means no
> installation is imported?)
>
I want to bring up this point again by exposing the current situation.

 The import process is async on the server side :
https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/installations/InstallationRegistrationEndpoint.java#L246-L248

And as you can see we always return a 200 Ok .

So what do we want to do here :
1. Just inform the Front End that the import process has started (with no
feedback on success or failure)
2. Make it blocking on the server side :/ ?
3. Add some  Push feature to inform the frontend of the import result

In the PR I'm about to submit, option 1 will be there. But based on the
discussion, it will of course be updated if needed.




>
>>
>> <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/20141125/db393ded/attachment-0001.html 


More information about the aerogear-dev mailing list