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

Matthias Wessendorf matzew at apache.org
Wed Nov 19 09:52:37 EST 2014 

On Mon, Nov 17, 2014 at 3:15 PM, Daniel Bevenius <daniel.bevenius at gmail.com>
wrote:

> Looks good. Should the export button be different colour than red perhaps?
> Perhaps we can just put the focus on the cancel button instead or
> something like that.
>

+1 blue is the color to go with



>
> On 17 November 2014 14:55, Sebastien Blanc <scm.blanc at gmail.com> wrote:
>
>> 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
>>>>>
>>>>
>>>>
>>>
>>
>> _______________________________________________
>> 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
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20141119/a38cfc1d/attachment-0001.html

More information about the aerogear-dev mailing list