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

Sebastien Blanc scm.blanc at gmail.com
Sun Nov 23 05:02:06 EST 2014 

Yeah realized that just after, I made the screencast with my (half) fix and
not your PR , I will redo a new screencast tomorrow with your PR :)


On Sun, Nov 23, 2014 at 10:56 AM, Lukáš Fryč <lukas.fryc at gmail.com> wrote:

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

More information about the aerogear-dev mailing list