Late, but better than never.
comments inline
On Tue, Nov 11, 2014 at 2:12 PM, Sebastien Blanc <scm.blanc(a)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-servic...
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-servic...
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}}}}
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/94f19f69e50a217e89363aefe52912c9b33f63...
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-iss...
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.
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/...
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)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