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@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@gmail.com> wrote:


On Sat, Nov 22, 2014 at 7:06 PM, Matthias Wessendorf <matzew@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@gmail.com> wrote:
FYI a quick screencast and preview of the Import feature ! 

Have a nice weekend ! 
Sebi

On Thu, Nov 20, 2014 at 10:35 AM, Sebastien Blanc <scm.blanc@gmail.com> wrote:


On Wed, Nov 19, 2014 at 3:57 PM, Matthias Wessendorf <matzew@apache.org> wrote:
Late, but better than never.

comments inline

On Tue, Nov 11, 2014 at 2:12 PM, Sebastien Blanc <scm.blanc@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.

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.

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",
     ...
   },
   ...
 ]

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

 

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 :

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
 

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 ?

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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev




--
Sent from Gmail Mobile

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev