6:05 a.m.
Sure, the first round can be only about installations, I wrote that in context of your
initial e-mail:
" Import/Export for Variants will maybe come later but due to some security issues
(mainly for iOS cert/passphrase) it's on hold. "
"we wont't do Variant export/import" does not seem the same thing as
"it's on hold and maybe come later" to me :)
Stefan Miklosovic
Red Hat Brno - JBoss Mobile Platform
e-mail: smikloso(a)redhat.com
irc: smikloso
----- Original Message -----
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. 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
>
> _______________________________________________
> 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