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

Lukáš Fryč lukas.fryc at gmail.com
Sun Nov 23 04:56:11 EST 2014


Hey Sebi,

That is likely caused by counter that is not updated when variant is
removed,

I've noticed that and fixed before in
https://github.com/sebastienblanc/aerogear-unified-push-server/pull/3

On Sat, Nov 22, 2014 at 7:57 PM, Sebastien Blanc <scm.blanc at gmail.com>
wrote:

>
>
> On Sat, Nov 22, 2014 at 7:06 PM, Matthias Wessendorf <matzew at apache.org>
> wrote:
>
>> Nice! But your previous screencasts had better sound! ;)
>>
>> Question: why does it say 2 installations before the import?
>>
> Ouch ! I was so much focused on the number of installations just below
> that I did not noticed that one. I have to check if this has been
> introduced with this or if it was already there before.  (I think something
> is hanging in the scope)
>
>>
>> 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>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Wed, Nov 19, 2014 at 3:57 PM, Matthias Wessendorf <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>
>>>>> 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
>>>>>> 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
>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>
>>>>
>>>>
>>>
>>
>> --
>> Sent from Gmail Mobile
>>
>> _______________________________________________
>> 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/20141123/12b0495a/attachment-0001.html 


More information about the aerogear-dev mailing list