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

Tue Nov 25 03:54:59 EST 2014

The solution of blocking request is simpler to implement, for sure.

If the REST call need to be async (will respond at the time the request
entity is parsed, but not processed),
then we should expose an API that would allow to retrieve the state of
import by the identifier of operation (that's how OData does that).

We don't have anything like that in UPS at the moment, but that principle
could be definitely reused later if implemented now.

http://docs.oasis-open.org/odata/odata/v4.0/errata01/os/complete/part1-protocol/odata-v4.0-errata01-os-part1-protocol-complete.html#_Toc399426854

On Tue, Nov 25, 2014 at 8:56 AM, Sebastien Blanc <scm.blanc at gmail.com>
wrote:

>
>
> 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
>>
>
>
> _______________________________________________
> 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/b8e8e3d7/attachment.html 