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

Sat Nov 22 13:06:45 EST 2014

Nice! But your previous screencasts had better sound! ;)

Question: why does it say 2 installations before the import?

On Saturday, November 22, 2014, Sebastien Blanc <scm.blanc at gmail.com> wrote:

> FYI a quick screencast and preview of the Import feature !
> import UPS installations
> <https://www.youtube.com/watch?v=Kw7JOkVHVCY&feature=youtu.be>
>
> Have a nice weekend !
> Sebi
>
> On Thu, Nov 20, 2014 at 10:35 AM, Sebastien Blanc <scm.blanc at gmail.com
> <javascript:_e(%7B%7D,'cvml','scm.blanc at gmail.com');>> wrote:
>
>>
>>
>> On Wed, Nov 19, 2014 at 3:57 PM, Matthias Wessendorf <matzew at apache.org
>> <javascript:_e(%7B%7D,'cvml','matzew at apache.org');>> wrote:
>>
>>> Late, but better than never.
>>>
>>> comments inline
>>>
>>> On Tue, Nov 11, 2014 at 2:12 PM, Sebastien Blanc <scm.blanc at gmail.com
>>> <javascript:_e(%7B%7D,'cvml','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.
>>>>
>>>
>>> +1
>>>
>>> not sure it needs to be pretty :) I am fine with having this {{{{.....a
>>> gazillion clients}}}}
>>>
>> Yeah it's unformatted now (and will stay so)
>>
>>>
>>> Output format
>>>>
>>>> How should provide the exported data ? I need your input here 1. Raw
>>>> Json ? 2. Json file ? 3. Zip / tarball ?
>>>>
>>>
>>> I saw we do gzip and JSON. +1 on that
>>>
>>>
>>>
>>>> <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.
>>>>
>>> a dialog simliar to variant creation. should have some validation checks
>>>
>>>
>>>
>>>> For export, the user just have to press an export button
>>>>
>>>
>>> +1
>>>
>>>
>>>>
>>>> <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.
>>>>
>>>
>>> -1 on making the variantID and secret editable for everyone.
>>> Let's have that only being done by the push admin. Also, we need to make
>>> sure the ID/Secret is a valid UUID. Otherwise, lazy folks will go with
>>> foo:bar ... but... well :) if one really does that... it's not our fault.
>>> but yeah, let's make sure the admin can edit, and use UUID.
>>>
>> Fair enough, let's discuss that in a different PR once inport/export has
>> been delivered
>>
>>>
>>>
>>>
>>>> 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*
>>>>
>>>
>>> YES! But, let's please do that on a different PR !
>>>
>>>
>>>> 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
>>>> <javascript:_e(%7B%7D,'cvml','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
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> <javascript:_e(%7B%7D,'cvml','aerogear-dev at lists.jboss.org');>
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>
>>
>

-- 
Sent from Gmail Mobile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20141122/b7c199b4/attachment.html 