We won't do Variant export/import
On Wed, Nov 12, 2014 at 11:31 AM, Stefan Miklosovic <smikloso(a)redhat.com>
wrote:
Two more comments which come to my mind and are quite technical.
1) When you export Variant into JSON and you want to import it again, you
fail to do so at this moment because Variant is abstract class and JSON
unmarshaller do not know to which class it should be cast. Because of that
we have to change model of Variant to add this on it (1). Maybe there is
another option how to do that (e.g. according to some field in Variant and
write custom JSON unmarshaller).
2) We have similar issue with VariantType, it fails to unmarshall at this
moment without this modification (2)
(1)
https://github.com/smiklosovic/aerogear-unifiedpush-server/blob/f7fe2f5f5...
(2)
https://github.com/smiklosovic/aerogear-unifiedpush-server/blob/f7fe2f5f5...
Stefan Miklosovic
Red Hat Brno - JBoss Mobile Platform
e-mail: smikloso(a)redhat.com
irc: smikloso
------------------------------
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.
<
https://gist.github.com/sebastienblanc/b863b80380f8ed16ad7b#output-format...
format
How should provide the exported data ? I need your input here 1. Raw Json
? 2. Json file ? 3. Zip / tarball ?
<
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. For export, the user just have to press an
export button
<
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.
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*
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
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev