Hi,
I have two comments. The first one is about JSON export of an Installation. You declare it
is like this when it comes to categories:
"categories" : ["football", "sport"]
However, with the current UPS of version 1.0.2, when you register some installation, it
returns you this
https://issues.jboss.org/browse/AGPUSH-1093
This issue should be addressed and since exporting of installations more or less means to
marshall them into JSON, you hit this issue for sure so model should be updated to return
only array of category names instead of its JSON representation.
The second comment is about security. I am begging you here from QA team to make it doable
via REST and not (only) via UPS console because it simplifies tons of hacking around the
code. Right now we are doing whole import by adding custom JAX-RS endpoints on top of UPS,
we generate applications, variants and installations randomly as JSONs and send them to
UPS to these batch endpoints and we are calling services to persist them.
You can find it here (1)
In case this would be done via REST, it would be no-brainer and huge time saver for QA
guys.
(1)
https://github.com/smiklosovic/aerogear-unifiedpush-server/commit/f7fe2f5...
Thanks
Stefan Miklosovic
Red Hat Brno - JBoss Mobile Platform
e-mail: smikloso(a)redhat.com
irc: smikloso
----- Original Message -----
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. Output format
How should provide the exported data ? I need your input here 1. Raw
Json ?
2. Json file ? 3. Zip / tarball ? 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. For export, the user just have to press an
export button 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.
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 ? 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
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev