On Mon, Oct 21, 2013 at 11:23 AM, Matthias Wessendorf <matzew(a)apache.org&gt;wrote: > Hello, > > For [1 <https://issues.jboss.org/browse/AGPUSH-209>] I want to discuss a > RESTful API for resetting the (Master)Secret of a PushApp and/or a Variant. > Good idea ! > Initially I'd like to propose an empty PUT request against an 'reset' > endpoint, specific to the ID of the PushApp/Variant (see [2<http://staging.aerogear.org/docs/specs/aerogear-push-rest/PushApplic...] > and [3<http://staging.aerogear.org/docs/specs/aerogear-push-rest/Variants/A... > ]). > > To give a congrete example: Resetting the Secret of an Android Variant > would result in a PUT against this URL: > > https://SERVER:PORT/CONTEXT/rest/applications/{pushApplicationID}/android... > > The CURL command would look like: > > curl -3 -v -H "Accept: application/json" -H "Content-type: application/json" > -X PUT > https://SERVER:PORT/CONTEXT/rest/applications/{pushApplicationID}/android... > > And resetting a PushApp will be of this form ? https://SERVER:PORT/CONTEXT/rest/applications/{pushApplicationID}/reset

Does resetting a pushApp, implicitly reset the Variant Secret ?

> The response body to that *PUT* request contain (JSON) details about the > specific Android Variant (using Android as an example here): > Not sure if we have to return all the details ... Is returning the secret not enough ?

{ > "id":"402880e43fa95bb3013faf3c41b40005", > "name":"Android App", > "description":"The Android Variant", > "variantID":"04e9f747-d256-4a24-a0ac-29b9a15e37b1", > "secret":"70135d26-696d-426a-8183-e1fd0fcb86fe", > "developer":"admin", > "instances":[], > "googleKey":"My Google API Key", > "projectNumber":"My Project Number / Sender ID" > } > > <https://gist.github.com/matzew/7d78eb091f6ca0fa01bb#admin-ui>Admin UI > > On the Admin UI the *HTTP PUT* request could be triggered through a > button, the actual execution would happen after giving "approval" on a > 'confirmation' button... > > On the long run, we could make it more 'complex', e.g. sending an email, > containing an URL to give approval to the reset etc - but for now, I'd like > to keep the reset simple.. > > Any thoughts ? > > [1] https://issues.jboss.org/browse/AGPUSH-209 > [2] > http://staging.aerogear.org/docs/specs/aerogear-push-rest/PushApplication/ > [3] > http://staging.aerogear.org/docs/specs/aerogear-push-rest/Variants/Android/ > > > -- > 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 > _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

Just to clarify. Need login[1] first. Right? [1] https://github.com/aerogear/aerogear-unifiedpush-server/#login On Mon, Oct 21, 2013 at 7:23 AM, Matthias Wessendorf <matzew(a)apache.org&gt;wrote: > Hello, > > For [1 <https://issues.jboss.org/browse/AGPUSH-209>] I want to discuss a > RESTful API for resetting the (Master)Secret of a PushApp and/or a Variant. > > Initially I'd like to propose an empty PUT request against an 'reset' > endpoint, specific to the ID of the PushApp/Variant (see [2<http://staging.aerogear.org/docs/specs/aerogear-push-rest/PushApplic...] > and [3<http://staging.aerogear.org/docs/specs/aerogear-push-rest/Variants/A... > ]). > > To give a congrete example: Resetting the Secret of an Android Variant > would result in a PUT against this URL: > > https://SERVER:PORT/CONTEXT/rest/applications/{pushApplicationID}/android... > > The CURL command would look like: > > curl -3 -v -H "Accept: application/json" -H "Content-type: application/json" > -X PUT > https://SERVER:PORT/CONTEXT/rest/applications/{pushApplicationID}/android... > > The response body to that *PUT* request contain (JSON) details about the > specific Android Variant (using Android as an example here): > > { > "id":"402880e43fa95bb3013faf3c41b40005", > "name":"Android App", > "description":"The Android Variant", > "variantID":"04e9f747-d256-4a24-a0ac-29b9a15e37b1", > "secret":"70135d26-696d-426a-8183-e1fd0fcb86fe", > "developer":"admin", > "instances":[], > "googleKey":"My Google API Key", > "projectNumber":"My Project Number / Sender ID" > } > > <https://gist.github.com/matzew/7d78eb091f6ca0fa01bb#admin-ui>Admin UI > > On the Admin UI the *HTTP PUT* request could be triggered through a > button, the actual execution would happen after giving "approval" on a > 'confirmation' button... > > On the long run, we could make it more 'complex', e.g. sending an email, > containing an URL to give approval to the reset etc - but for now, I'd like > to keep the reset simple.. > > Any thoughts ? > > [1] https://issues.jboss.org/browse/AGPUSH-209 > [2] > http://staging.aerogear.org/docs/specs/aerogear-push-rest/PushApplication/ > [3] > http://staging.aerogear.org/docs/specs/aerogear-push-rest/Variants/Android/ > > > -- > 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 > _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

To get back to this PR : I'm +1 On Tue, Oct 22, 2013 at 3:32 PM, Matthias Wessendorf <matzew(a)apache.org&gt;wrote: > yup > > > On Tue, Oct 22, 2013 at 3:06 PM, Daniel Passos <daniel(a)passos.me&gt; wrote: > >> Just to clarify. Need login[1] first. Right? >> >> [1] https://github.com/aerogear/aerogear-unifiedpush-server/#login >> >> >> On Mon, Oct 21, 2013 at 7:23 AM, Matthias Wessendorf <matzew(a)apache.org&gt;wrote: >> >>> Hello, >>> >>> For [1 <https://issues.jboss.org/browse/AGPUSH-209>] I want to discuss >>> a RESTful API for resetting the (Master)Secret of a PushApp and/or a >>> Variant. >>> >>> Initially I'd like to propose an empty PUT request against an 'reset' >>> endpoint, specific to the ID of the PushApp/Variant (see [2<http://staging.aerogear.org/docs/specs/aerogear-push-rest/PushApplic...] >>> and [3<http://staging.aerogear.org/docs/specs/aerogear-push-rest/Variants/A... >>> ]). >>> >>> To give a congrete example: Resetting the Secret of an Android Variant >>> would result in a PUT against this URL: >>> >>> https://SERVER:PORT/CONTEXT/rest/applications/{pushApplicationID}/android... >>> >>> The CURL command would look like: >>> >>> curl -3 -v -H "Accept: application/json" -H "Content-type: application/json" >>> -X PUT >>> https://SERVER:PORT/CONTEXT/rest/applications/{pushApplicationID}/android... >>> >>> The response body to that *PUT* request contain (JSON) details about >>> the specific Android Variant (using Android as an example here): >>> >>> { >>> "id":"402880e43fa95bb3013faf3c41b40005", >>> "name":"Android App", >>> "description":"The Android Variant", >>> "variantID":"04e9f747-d256-4a24-a0ac-29b9a15e37b1", >>> "secret":"70135d26-696d-426a-8183-e1fd0fcb86fe", >>> "developer":"admin", >>> "instances":[], >>> "googleKey":"My Google API Key", >>> "projectNumber":"My Project Number / Sender ID" >>> } >>> >>> <https://gist.github.com/matzew/7d78eb091f6ca0fa01bb#admin-ui>Admin UI >>> >>> On the Admin UI the *HTTP PUT* request could be triggered through a >>> button, the actual execution would happen after giving "approval" on a >>> 'confirmation' button... >>> >>> On the long run, we could make it more 'complex', e.g. sending an >>> email, containing an URL to give approval to the reset etc - but for now, >>> I'd like to keep the reset simple.. >>> >>> Any thoughts ? >>> >>> [1] https://issues.jboss.org/browse/AGPUSH-209 >>> [2] >>> http://staging.aerogear.org/docs/specs/aerogear-push-rest/PushApplication/ >>> [3] >>> http://staging.aerogear.org/docs/specs/aerogear-push-rest/Variants/Android/ >>> >>> >>> -- >>> 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 >>> >> >> >> _______________________________________________ >> 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 > _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev