On Tue, Nov 11, 2014 at 2:12 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; 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. > <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 ? > Gzipped json file download sounds as easily accessible for browsers. > <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 > +1 sounds good, we just need to decide whether block the user when uploading / downloading I guess: a) downloading - do not block UI, downloading is a separate activity b) uploading - block the UI, offer progress and error indication and ability to cancel the process (transactional? - cancelling means no installation is imported?) > > <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

On Tue, Nov 11, 2014 at 2:12 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; 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. > > <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 ? > Gzipped json file download sounds as easily accessible for browsers.

<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 > +1 sounds good, we just need to decide whether block the user when uploading / downloading I guess: a) downloading - do not block UI, downloading is a separate activity b) uploading - block the UI, offer progress and error indication and ability to cancel the process (transactional? - cancelling means no installation is imported?)

> > <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

On Tue, Nov 11, 2014 at 5:08 PM, Lukáš Fryč <lukas.fryc(a)gmail.com&gt; wrote: > > > On Tue, Nov 11, 2014 at 2:12 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; > 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. >> >> <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 ? >> > > Gzipped json file download sounds as easily accessible for browsers. > >> <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 >> > > +1 sounds good, we just need to decide whether block the user when > uploading / downloading > > I guess: > > a) downloading - do not block UI, downloading is a separate activity > b) uploading - block the UI, offer progress and error indication and > ability to cancel the process (transactional? - cancelling means no > installation is imported?) > I want to bring up this point again by exposing the current situation. The import process is async on the server side : https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/jaxrs... And as you can see we always return a 200 Ok . So what do we want to do here : 1. Just inform the Front End that the import process has started (with no feedback on success or failure) 2. Make it blocking on the server side :/ ? 3. Add some Push feature to inform the frontend of the import result In the PR I'm about to submit, option 1 will be there. But based on the discussion, it will of course be updated if needed. > >> >> <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 > _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

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 ------------------------------ 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

On Wed, Nov 12, 2014 at 12:36 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: > > > On Wed, Nov 12, 2014 at 11:15 AM, Stefan Miklosovic <smikloso(a)redhat.com&gt; > wrote: > >> 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. >> > Ok good catch, I will keep this ticket in mind > >> >> 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. >> > I know, for now you can access it through rest, but tbh I want to have > the security expert feedback on this and if we decide it's too insecure we > will have to change it > So I have been thinking more on this and sorry Stefan, I think we will not allow export using basic auth , it;s to insecure, just with variantId/variantSecret someone would be able to retrieve all the device tokens. >> 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 >> >> ------------------------------ >> >> 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 >> > >

Looks good. Should the export button be different colour than red perhaps? Perhaps we can just put the focus on the cancel button instead or something like that.

On 17 November 2014 14:55, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: > Hi, > I started to implement the "export" feature : > > - https://github.com/aerogear/aerogear-unifiedpush-server/pull/435 > > Also a really short screencast showing how it works : > https://www.youtube.com/watch?v=HFXesTHh4PM&feature=youtu.be > > > > On Thu, Nov 13, 2014 at 2:52 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; > wrote: > >> >> >> On Wed, Nov 12, 2014 at 12:36 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; >> wrote: >> >>> >>> >>> On Wed, Nov 12, 2014 at 11:15 AM, Stefan Miklosovic < >>> smikloso(a)redhat.com&gt; wrote: >>> >>>> 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. >>>> >>> Ok good catch, I will keep this ticket in mind >>> >>>> >>>> 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. >>>> >>> I know, for now you can access it through rest, but tbh I want to have >>> the security expert feedback on this and if we decide it's too insecure we >>> will have to change it >>> >> >> So I have been thinking more on this and sorry Stefan, I think we will >> not allow export using basic auth , it;s to insecure, just with >> variantId/variantSecret someone would be able to retrieve all the device >> tokens. >> >> >> >>>> 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 >>>> >>>> ------------------------------ >>>> >>>> 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 >>>> >>> >>> >> > > _______________________________________________ > 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

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 ------------------------------ 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

On 2014-11-12, Stefan Miklosovic wrote: > 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. > I think it has nothing to do with security, it pretty much stands for ther requirements on UPS. Also, like you mentioned is no-brainer to enable it on KC admin see: http://docs.jboss.org/keycloak/docs/1.0-beta-3/userguide/html/direct-acce...

We're just enabling something that we don't want to see enabled in production and people can do it by themselves. > 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 > > > [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 -- abstractj PGP: 0x84DC9914 _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

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

[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

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 >

> > [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

_______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

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.

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

On Wed, Nov 19, 2014 at 3:57 PM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > Late, but better than never. > > comments inline > > On Tue, Nov 11, 2014 at 2:12 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; > 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}}}} > 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 > > > >> <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. > 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 ? >> <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 > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev >

Nice! But your previous screencasts had better sound! ;) Question: why does it say 2 installations before the import?

On Saturday, November 22, 2014, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: > FYI a quick screencast and preview of the Import feature ! > import UPS installations > <https://www.youtube.com/watch?v=Kw7JOkVHVCY&feature=youtu.be> > > Have a nice weekend ! > Sebi > > On Thu, Nov 20, 2014 at 10:35 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; > wrote: > >> >> >> On Wed, Nov 19, 2014 at 3:57 PM, Matthias Wessendorf <matzew(a)apache.org&gt; >> wrote: >> >>> Late, but better than never. >>> >>> comments inline >>> >>> On Tue, Nov 11, 2014 at 2:12 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; >>> 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}}}} >>> >> 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 >>> >>> >>> >>>> <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. >>> >> 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 ? >>>> <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 >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> > -- Sent from Gmail Mobile _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Sat, Nov 22, 2014 at 7:06 PM, Matthias Wessendorf <matzew(a)apache.org&gt; 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(a)gmail.com&gt; > wrote: > >> FYI a quick screencast and preview of the Import feature ! >> import UPS installations >> <https://www.youtube.com/watch?v=Kw7JOkVHVCY&feature=youtu.be> >> >> Have a nice weekend ! >> Sebi >> >> On Thu, Nov 20, 2014 at 10:35 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; >> wrote: >> >>> >>> >>> On Wed, Nov 19, 2014 at 3:57 PM, Matthias Wessendorf <matzew(a)apache.org >>> > wrote: >>> >>>> Late, but better than never. >>>> >>>> comments inline >>>> >>>> On Tue, Nov 11, 2014 at 2:12 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; >>>> 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}}}} >>>> >>> 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 >>>> >>>> >>>> >>>>> <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. >>>> >>> 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 ? >>>>> <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 >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >> > > -- > Sent from Gmail Mobile > > _______________________________________________ > 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

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(a)gmail.com <javascript:_e(%7B%7D,'cvml','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(a)gmail.com > <javascript:_e(%7B%7D,'cvml','scm.blanc@gmail.com');>> wrote: > >> >> >> On Sat, Nov 22, 2014 at 7:06 PM, Matthias Wessendorf <matzew(a)apache.org >> <javascript:_e(%7B%7D,'cvml','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(a)gmail.com >>> <javascript:_e(%7B%7D,'cvml','scm.blanc@gmail.com');>> wrote: >>> >>>> FYI a quick screencast and preview of the Import feature ! >>>> import UPS installations >>>> <https://www.youtube.com/watch?v=Kw7JOkVHVCY&feature=youtu.be> >>>> >>>> Have a nice weekend ! >>>> Sebi >>>> >>>> On Thu, Nov 20, 2014 at 10:35 AM, Sebastien Blanc <scm.blanc(a)gmail.com >>>> > wrote: >>>> >>>>> >>>>> >>>>> On Wed, Nov 19, 2014 at 3:57 PM, Matthias Wessendorf < >>>>> matzew(a)apache.org&gt; wrote: >>>>> >>>>>> Late, but better than never. >>>>>> >>>>>> comments inline >>>>>> >>>>>> On Tue, Nov 11, 2014 at 2:12 PM, Sebastien Blanc < >>>>>> scm.blanc(a)gmail.com&gt; 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}}}} >>>>>> >>>>> 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 >>>>>> >>>>>> >>>>>> >>>>>>> <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. >>>>>> >>>>> 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 ? >>>>>>> >>>>>>> <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 >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>> >>>>> >>>> >>> >>> -- >>> Sent from Gmail Mobile >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)lists.jboss.org >>> <javascript:_e(%7B%7D,'cvml','aerogear-dev@lists.jboss.org');> >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> <javascript:_e(%7B%7D,'cvml','aerogear-dev@lists.jboss.org');> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > <javascript:_e(%7B%7D,'cvml','aerogear-dev@lists.jboss.org');> > https://lists.jboss.org/mailman/listinfo/aerogear-dev >