[aerogear-dev] [UPS] Import/Export of installations
Sebastien Blanc
scm.blanc at gmail.com
Mon Nov 17 08:55:35 EST 2014
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 at gmail.com>
wrote:
>
>
> On Wed, Nov 12, 2014 at 12:36 PM, Sebastien Blanc <scm.blanc at gmail.com>
> wrote:
>
>>
>>
>> On Wed, Nov 12, 2014 at 11:15 AM, Stefan Miklosovic <smikloso at redhat.com>
>> 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/f7fe2f5f58a8882aa5a3362d07a208c37b0d4403
>>>
>>> Thanks
>>>
>>> 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/20141117/aa504fde/attachment-0001.html
More information about the aerogear-dev
mailing list