Bruno merged the security bits to MASTER. A tag (0.1.0) of the previous MASTER (the one without security) has been created. -Matthias On Mon, Jun 17, 2013 at 2:52 PM, Matthias Wessendorf <matzew(a)apache.org&gt;wrote: > Hi, > > I worked a bit on the initial security, after Bruno release the 1.0.1 > versions of AG-Security. > <https://gist.github.com/anonymous/b82b7bb1b2d1ab36f92d#management-of-push... > of PushApplications and MobileVariants > > Adding a (simple) *DEVELOPER* class (just that, no *fancy* roles yet). > This is powered by AG-Security and the very wellknown "login"/"logout" > will be used (and soon "enroll" for new users). > > A *DEVELOPER* is allowed to create/manage PushApplications and > MobileVariants (including the standard CRUD flow). > > Here is a little cURL based flow: > <https://gist.github.com/anonymous/b82b7bb1b2d1ab36f92d#login>Login: > > curl -v -b cookies.txt -c cookies.txt > -H "Accept: application/json" -H "Content-type: application/json" > -X POST > -d '{"loginName": "admin", "password":"123"}'http://localhost:8080/ag-push/rest/auth/login > > > <https://gist.github.com/anonymous/b82b7bb1b2d1ab36f92d#create-new-pushapp... > new PushApp: > > curl -v -b cookies.txt -c cookies.txt -v > -H "Accept: application/json" -H "Content-type: application/json" > -X POST > -d '{"name" : "MyApp", "description" : "awesome app" }'http://localhost:8080/ag-push/rest/applications > > > <https://gist.github.com/anonymous/b82b7bb1b2d1ab36f92d#create-variant-her... > Variant (here SimplePush) for it: > > curl -v -b cookies.txt -c cookies.txt -v > -H "Accept: application/json" -H "Content-type: application/json" > -X POST > -d '{"pushNetworkURL" : "http://localhost:7777/endpoint/"}'http://localhost:8080/ag-push/rest/applications/{PUSH_APP_ID}/simplePush > > <https://gist.github.com/anonymous/b82b7bb1b2d1ab36f92d#sending-push-notif... > Push Notifications > > When a PushApplication is created, it will get a GENERATED *PUSH-APP-ID* (like > before) and it will also have a generated *master secret*. For sending > (NOW) you need HTTP BASIC auth against the SENDER HTTP interface: > > curl -u "{PushApplicationID}:{MasterSecret}" > -v -H "Accept: application/json" -H "Content-type: application/json" > -X POST > -d '{"key":"value", "alert":"HELLO!", "sound":"default", "badge":7, > "simple-push":"version=123"}' > http://localhost:8080/ag-push/rest/sender/broadcast > > The user is a combination of PushApplicationID:MasterSecret, hence no > need to include the PushApplicationID on the URL..... > <https://gist.github.com/anonymous/b82b7bb1b2d1ab36f92d#device-registratio... > Registration > > When a MobileVariant is created, it will get a GENERATED *VARIANT-ID* (like > before) and it will have a generated "variant secret" (valid ONLY!!! for > that variant). Now a device needs to perform HTTP basic against that > server, in order to register itself: > > An Android (cURL) example: > > curl -u "{MobileVariantID}:{secret}" > -v -H "Accept: application/json" -H "Content-type: application/json" > -X POST > -d '{ > "deviceToken" : "someTokenString", > "deviceType" : "ANDROID", > "mobileOperatingSystem" : "android", > "osVersion" : "4.0.1" > }' > http://localhost:8080/ag-push/rest/registry/device > > The user is a combination of MobileVariantID:MasterSecret, hence no need > to include the MobileVariantID (was a http header in the past). > > The work lives on a branch for now: > > https://github.com/aerogear/aerogear-unified-push-server/tree/endpoint-se... > > > FYI, the iOS SDK has been updated to reflect that: > https://github.com/matzew/aerogear-push-ios-registration/commit/ef8001684... > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf

Hi, I worked a bit on the initial security, after Bruno release the 1.0.1 versions of AG-Security. Management of PushApplications and MobileVariants Adding a (simple) DEVELOPER class (just that, no fancy roles yet). This is powered by AG-Security and the very wellknown "login"/"logout" will be used (and soon "enroll" for new users). A DEVELOPER is allowed to create/manage PushApplications and MobileVariants (including the standard CRUD flow). Here is a little cURL based flow: Login: curl -v -b cookies.txt -c cookies.txt -H "Accept: application/json" -H "Content-type: application/json" -X POST -d '{"loginName": "admin", "password":"123"}' http://localhost:8080/ag-push/rest/auth/login Create new PushApp: curl -v -b cookies.txt -c cookies.txt -v -H "Accept: application/json" -H "Content-type: application/json" -X POST -d '{"name" : "MyApp", "description" : "awesome app" }' http://localhost:8080/ag-push/rest/applications Create Variant (here SimplePush) for it: curl -v -b cookies.txt -c cookies.txt -v -H "Accept: application/json" -H "Content-type: application/json" -X POST -d '{"pushNetworkURL" : "http://localhost:7777/endpoint/"}' http://localhost:8080/ag-push/rest/applications/{PUSH_APP_ID}/simplePush Sending Push Notifications When a PushApplication is created, it will get a GENERATED PUSH-APP-ID (like before) and it will also have a generated master secret. For sending (NOW) you need HTTP BASIC auth against the SENDER HTTP interface: curl -u "{PushApplicationID}:{MasterSecret}" -v -H "Accept: application/json" -H "Content-type: application/json" -X POST -d '{"key":"value", "alert":"HELLO!", "sound":"default", "badge":7, "simple-push":"version=123"}' http://localhost:8080/ag-push/rest/sender/broadcast The user is a combination of PushApplicationID:MasterSecret, hence no need to include the PushApplicationID on the URL..... Device Registration When a MobileVariant is created, it will get a GENERATED VARIANT-ID (like before) and it will have a generated "variant secret" (valid ONLY!!! for that variant). Now a device needs to perform HTTP basic against that server, in order to register itself: An Android (cURL) example: curl -u "{MobileVariantID}:{secret}" -v -H "Accept: application/json" -H "Content-type: application/json" -X POST -d '{ "deviceToken" : "someTokenString", "deviceType" : "ANDROID", "mobileOperatingSystem" : "android", "osVersion" : "4.0.1" }' http://localhost:8080/ag-push/rest/registry/device The user is a combination of MobileVariantID:MasterSecret, hence no need to include the MobileVariantID (was a http header in the past). The work lives on a branch for now: https://github.com/aerogear/aerogear-unified-push-server/tree/endpoint-se... FYI, the iOS SDK has been updated to reflect that: https://github.com/matzew/aerogear-push-ios-registration/commit/ef8001684... -- 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

FYI, A "security" Java Sender branch has also been pushed : https://github.com/aerogear/aerogear-unified-push-java-client/tree/security It's using preemptive Basic Http Authentification but we will switch to a more "classic" flow when AGPUSH-99 will be resolved. Like Matthias said is "all in progress" work but "Push early, Push often"

On Wed, Jun 19, 2013 at 8:38 AM, Christos Vasilakis <cvasilak(a)gmail.com&gt;wrote: > looks great! > > On Jun 17, 2013, at 3:52 PM, Matthias Wessendorf <matzew(a)apache.org&gt; > wrote: > > Hi, > > I worked a bit on the initial security, after Bruno release the 1.0.1 > versions of AG-Security. > <https://gist.github.com/anonymous/b82b7bb1b2d1ab36f92d#management-of-push... > of PushApplications and MobileVariants > > Adding a (simple) *DEVELOPER* class (just that, no *fancy* roles yet). > This is powered by AG-Security and the very wellknown "login"/"logout" > will be used (and soon "enroll" for new users). > > A *DEVELOPER* is allowed to create/manage PushApplications and > MobileVariants (including the standard CRUD flow). > > Here is a little cURL based flow: > <https://gist.github.com/anonymous/b82b7bb1b2d1ab36f92d#login>Login: > > curl -v -b cookies.txt -c cookies.txt > -H "Accept: application/json" -H "Content-type: application/json" > -X POST > -d '{"loginName": "admin", "password":"123"}'http://localhost:8080/ag-push/rest/auth/login > > > <https://gist.github.com/anonymous/b82b7bb1b2d1ab36f92d#create-new-pushapp... > new PushApp: > > curl -v -b cookies.txt -c cookies.txt -v > -H "Accept: application/json" -H "Content-type: application/json" > -X POST > -d '{"name" : "MyApp", "description" : "awesome app" }'http://localhost:8080/ag-push/rest/applications > > > <https://gist.github.com/anonymous/b82b7bb1b2d1ab36f92d#create-variant-her... > Variant (here SimplePush) for it: > > curl -v -b cookies.txt -c cookies.txt -v > -H "Accept: application/json" -H "Content-type: application/json" > -X POST > -d '{"pushNetworkURL" : "http://localhost:7777/endpoint/"}'http://localhost:8080/ag-push/rest/applications/{PUSH_APP_ID}/simplePush > > <https://gist.github.com/anonymous/b82b7bb1b2d1ab36f92d#sending-push-notif... > Push Notifications > > When a PushApplication is created, it will get a GENERATED *PUSH-APP-ID* (like > before) and it will also have a generated *master secret*. For sending > (NOW) you need HTTP BASIC auth against the SENDER HTTP interface: > > curl -u "{PushApplicationID}:{MasterSecret}" > -v -H "Accept: application/json" -H "Content-type: application/json" > -X POST > -d '{"key":"value", "alert":"HELLO!", "sound":"default", "badge":7, > "simple-push":"version=123"}' > http://localhost:8080/ag-push/rest/sender/broadcast > > The user is a combination of PushApplicationID:MasterSecret, hence no > need to include the PushApplicationID on the URL..... > <https://gist.github.com/anonymous/b82b7bb1b2d1ab36f92d#device-registratio... > Registration > > When a MobileVariant is created, it will get a GENERATED *VARIANT-ID* (like > before) and it will have a generated "variant secret" (valid ONLY!!! for > that variant). Now a device needs to perform HTTP basic against that > server, in order to register itself: > > An Android (cURL) example: > > curl -u "{MobileVariantID}:{secret}" > -v -H "Accept: application/json" -H "Content-type: application/json" > -X POST > -d '{ > "deviceToken" : "someTokenString", > "deviceType" : "ANDROID", > "mobileOperatingSystem" : "android", > "osVersion" : "4.0.1" > }' > http://localhost:8080/ag-push/rest/registry/device > > The user is a combination of MobileVariantID:MasterSecret, hence no need > to include the MobileVariantID (was a http header in the past). > > The work lives on a branch for now: > > https://github.com/aerogear/aerogear-unified-push-server/tree/endpoint-se... > > > FYI, the iOS SDK has been updated to reflect that: > https://github.com/matzew/aerogear-push-ios-registration/commit/ef8001684... > > -- > 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 > _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

Thanks Sebi, I'll look at this. Sebastien Blanc wrote: > FYI, > > A "security" Java Sender branch has also been pushed : > https://github.com/aerogear/aerogear-unified-push-java-client/tree/security > It's using preemptive Basic Http Authentification but we will switch to > a more "classic" flow when AGPUSH-99 will be resolved. > > Like Matthias said is "all in progress" work but "Push early, Push often" > > > > > On Wed, Jun 19, 2013 at 8:38 AM, Christos Vasilakis <cvasilak(a)gmail.com > <mailto:cvasilak@gmail.com>> wrote: > > looks great! > > On Jun 17, 2013, at 3:52 PM, Matthias Wessendorf <matzew(a)apache.org > <mailto:matzew@apache.org>> wrote: > >> Hi, >> >> I worked a bit on the initial security, after Bruno release the >> 1.0.1 versions of AG-Security. >> >> >> < https://gist.github.com/anonymous/b82b7bb1b2d1ab36f92d#management-of-push... >Management >> of PushApplications and MobileVariants >> >> Adding a (simple) /DEVELOPER/ class (just that, no /fancy/ roles yet). >> This is powered by AG-Security and the very wellknown >> "login"/"logout" will be used (and soon "enroll" for new users). >> >> A /DEVELOPER/ is allowed to create/manage PushApplications and >> MobileVariants (including the standard CRUD flow). >> >> Here is a little cURL based flow: >> >> >> < https://gist.github.com/anonymous/b82b7bb1b2d1ab36f92d#login>Login: >> >> |curl -v -b cookies.txt -c cookies.txt >> -H"Accept: application/json" -H"Content-type: application/json" >> -X POST >> -d'{"loginName":"admin","password":"123"}' >> http://localhost:8080/ag-push/rest/auth/login >> | >> >> >> < https://gist.github.com/anonymous/b82b7bb1b2d1ab36f92d#create-new-pushapp >Create >> new PushApp: >> >> |curl -v -b cookies.txt -c cookies.txt -v >> -H"Accept: application/json" -H"Content-type: application/json" >> -X POST >> -d'{"name" :"MyApp","description" :"awesome app" }' >> http://localhost:8080/ag-push/rest/applications >> | >> >> >> < https://gist.github.com/anonymous/b82b7bb1b2d1ab36f92d#create-variant-her... >Create >> Variant (here SimplePush) for it: >> >> |curl -v -b cookies.txt -c cookies.txt -v >> -H"Accept: application/json" -H"Content-type: application/json" >> -X POST >> -d'{"pushNetworkURL" :"http://localhost:7777/endpoint/"}' >> http://localhost:8080/ag-push/rest/applications/{PUSH_APP_ID}/simplePush < http://localhost:8080/ag-push/rest/applications/%7BPUSH_APP_ID%7D/simplePush > >> | >> >> >> < https://gist.github.com/anonymous/b82b7bb1b2d1ab36f92d#sending-push-notif... >Sending >> Push Notifications >> >> When a PushApplication is created, it will get a GENERATED >> /PUSH-APP-ID/ (like before) and it will also have a generated >> /master secret/. For sending (NOW) you need HTTP BASIC auth >> against the SENDER HTTP interface: >> >> |curl -u"{PushApplicationID}:{MasterSecret}" >> -v -H"Accept: application/json" -H"Content-type: application/json" >> -X POST >> -d'{"key":"value","alert":"HELLO!","sound":"default","badge":7, >> "simple-push":"version=123"}' >> >> http://localhost:8080/ag-push/rest/sender/broadcast >> | >> >> The user is a combination of PushApplicationID:MasterSecret, hence >> no need to include the PushApplicationID on the URL..... >> >> >> < https://gist.github.com/anonymous/b82b7bb1b2d1ab36f92d#device-registration >Device >> Registration >> >> When a MobileVariant is created, it will get a GENERATED >> /VARIANT-ID/ (like before) and it will have a generated "variant >> secret" (valid ONLY!!! for that variant). Now a device needs to >> perform HTTP basic against that server, in order to register itself: >> >> An Android (cURL) example: >> >> |curl -u"{MobileVariantID}:{secret}" >> -v -H"Accept: application/json" -H"Content-type: application/json" >> -X POST >> -d'{ >> "deviceToken" :"someTokenString", >> "deviceType" :"ANDROID", >> "mobileOperatingSystem" :"android", >> "osVersion" :"4.0.1" >> }' >> >> http://localhost:8080/ag-push/rest/registry/device >> | >> >> The user is a combination of MobileVariantID:MasterSecret, hence >> no need to include the MobileVariantID (was a http header in the >> past). >> >> The work lives on a branch for now: >> https://github.com/aerogear/aerogear-unified-push-server/tree/endpoint-se... >> >> >> FYI, the iOS SDK has been updated to reflect that: >> https://github.com/matzew/aerogear-push-ios-registration/commit/ef8001684... >> >> >> -- >> 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 <mailto:aerogear-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@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 _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

Hi Matthias I have some questions. Matthias Wessendorf wrote: > FYI > > JIRAs for the "initial" security work: > > > All the endpoints are now secured: > https://issues.jboss.org/browse/AGPUSH-59 > > Details on the actual enpoints, on the AGSEC JIRA: > For the endpoints below. > Enpoint for Push Apps is secure (using AG-Security): > https://issues.jboss.org/browse/AGSEC-51 Why? - https://github.com/aerogear/aerogear-unified-push-server/blob/master/src/... - https://github.com/aerogear/aerogear-unified-push-server/blob/master/src/... - https://github.com/aerogear/aerogear-unified-push-server/blob/master/src/... - https://github.com/aerogear/aerogear-unified-push-server/blob/master/src/... - https://github.com/aerogear/aerogear-unified-push-server/blob/master/src/... > > Enpoint for {Android|iOS|SimplePush} Variants is secure (using AG-Security): > https://issues.jboss.org/browse/AGSEC-52 https://github.com/aerogear/aerogear-unified-push-server/blob/master/src/... Well the same to the rest of the code and endpoints. Why are we doing it? As far as I know we just introduced an interceptor for it: https://github.com/aerogear/aerogear-unified-push-server/blob/master/src/... Which could be used with: @Secure({admin, developer}) public void myPrettyEndpoint(){} If I'm reading it correctly, you're not checking for which roles the current logged in user has https://github.com/aerogear/aerogear-unified-push-server/blob/master/src/...

We have 2 alternatives: - If the interceptors are not a good fit, just delete it

- Refactor the whole group of endpoints to make use of interceptors Let me know what do you want to do. > > Enpoint for Device Registration is secure (Using HTTP Basic): > https://issues.jboss.org/browse/AGSEC-50 > > Enpoint for SENDING is secure (Using HTTP Basic): > https://issues.jboss.org/browse/AGSEC-54 > > > > > On Wed, Jun 19, 2013 at 11:56 AM, Bruno Oliveira <bruno(a)abstractj.org > <mailto:bruno@abstractj.org>> wrote: > > Thanks Sebi, I'll look at this. > > Sebastien Blanc wrote: > > FYI, > > > > A "security" Java Sender branch has also been pushed : > > > https://github.com/aerogear/aerogear-unified-push-java-client/tree/security > > It's using preemptive Basic Http Authentification but we will > switch to > > a more "classic" flow when AGPUSH-99 will be resolved. > > > > Like Matthias said is "all in progress" work but "Push early, > Push often" > > > > > > > > > > On Wed, Jun 19, 2013 at 8:38 AM, Christos Vasilakis > <cvasilak(a)gmail.com <mailto:cvasilak@gmail.com> > > <mailto:cvasilak@gmail.com <mailto:cvasilak@gmail.com>>> wrote: > > > > looks great! > > > > On Jun 17, 2013, at 3:52 PM, Matthias Wessendorf > <matzew(a)apache.org <mailto:matzew@apache.org> > > <mailto:matzew@apache.org <mailto:matzew@apache.org>>> wrote: > > > >> Hi, > >> > >> I worked a bit on the initial security, after Bruno release the > >> 1.0.1 versions of AG-Security. > >> > >> > >> > < https://gist.github.com/anonymous/b82b7bb1b2d1ab36f92d#management-of-push... >Management > >> of PushApplications and MobileVariants > >> > >> Adding a (simple) /DEVELOPER/ class (just that, no /fancy/ > roles yet). > >> This is powered by AG-Security and the very wellknown > >> "login"/"logout" will be used (and soon "enroll" for new users). > >> > >> A /DEVELOPER/ is allowed to create/manage PushApplications and > >> MobileVariants (including the standard CRUD flow). > >> > >> Here is a little cURL based flow: > >> > >> > >> <https://gist.github.com/anonymous/b82b7bb1b2d1ab36f92d#login >Login: > >> > >> |curl -v -b cookies.txt -c cookies.txt > >> -H"Accept: application/json" -H"Content-type: > application/json" > >> -X POST > >> -d'{"loginName":"admin","password":"123"}' > >> http://localhost:8080/ag-push/rest/auth/login > >> | > >> > >> > >> > < https://gist.github.com/anonymous/b82b7bb1b2d1ab36f92d#create-new-pushapp >Create > >> new PushApp: > >> > >> |curl -v -b cookies.txt -c cookies.txt -v > >> -H"Accept: application/json" -H"Content-type: > application/json" > >> -X POST > >> -d'{"name" :"MyApp","description" :"awesome app" }' > >> http://localhost:8080/ag-push/rest/applications > >> | > >> > >> > >> > < https://gist.github.com/anonymous/b82b7bb1b2d1ab36f92d#create-variant-her... >Create > >> Variant (here SimplePush) for it: > >> > >> |curl -v -b cookies.txt -c cookies.txt -v > >> -H"Accept: application/json" -H"Content-type: > application/json" > >> -X POST > >> -d'{"pushNetworkURL" :"http://localhost:7777/endpoint/ "}' > >> > http://localhost:8080/ag-push/rest/applications/{PUSH_APP_ID}/simplePush > < http://localhost:8080/ag-push/rest/applications/%7BPUSH_APP_ID%7D/simplePush > > >> | > >> > >> > >> > < https://gist.github.com/anonymous/b82b7bb1b2d1ab36f92d#sending-push-notif... >Sending > >> Push Notifications > >> > >> When a PushApplication is created, it will get a GENERATED > >> /PUSH-APP-ID/ (like before) and it will also have a generated > >> /master secret/. For sending (NOW) you need HTTP BASIC auth > >> against the SENDER HTTP interface: > >> > >> |curl -u"{PushApplicationID}:{MasterSecret}" > >> -v -H"Accept: application/json" -H"Content-type: > application/json" > >> -X POST > >> > -d'{"key":"value","alert":"HELLO!","sound":"default","badge":7, > >> "simple-push":"version=123"}' > >> > >> http://localhost:8080/ag-push/rest/sender/broadcast > >> | > >> > >> The user is a combination of PushApplicationID:MasterSecret, > hence > >> no need to include the PushApplicationID on the URL..... > >> > >> > >> > < https://gist.github.com/anonymous/b82b7bb1b2d1ab36f92d#device-registration >Device > >> Registration > >> > >> When a MobileVariant is created, it will get a GENERATED > >> /VARIANT-ID/ (like before) and it will have a generated "variant > >> secret" (valid ONLY!!! for that variant). Now a device needs to > >> perform HTTP basic against that server, in order to register > itself: > >> > >> An Android (cURL) example: > >> > >> |curl -u"{MobileVariantID}:{secret}" > >> -v -H"Accept: application/json" -H"Content-type: > application/json" > >> -X POST > >> -d'{ > >> "deviceToken" :"someTokenString", > >> "deviceType" :"ANDROID", > >> "mobileOperatingSystem" :"android", > >> "osVersion" :"4.0.1" > >> }' > >> > >> http://localhost:8080/ag-push/rest/registry/device > >> | > >> > >> The user is a combination of MobileVariantID:MasterSecret, hence > >> no need to include the MobileVariantID (was a http header in the > >> past). > >> > >> The work lives on a branch for now: > >> > https://github.com/aerogear/aerogear-unified-push-server/tree/endpoint-se... > >> > >> > >> FYI, the iOS SDK has been updated to reflect that: > >> > https://github.com/matzew/aerogear-push-ios-registration/commit/ef8001684... > >> > >> > >> -- > >> 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 > <mailto:aerogear-dev@lists.jboss.org> > <mailto:aerogear-dev@lists.jboss.org > <mailto:aerogear-dev@lists.jboss.org>> > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev(a)lists.jboss.org > <mailto:aerogear-dev@lists.jboss.org> > <mailto:aerogear-dev@lists.jboss.org > <mailto:aerogear-dev@lists.jboss.org>> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > -- > abstractj > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@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 -- abstractj _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

I do it, if we're not using the interceptor we're just hiding a issue and duplicating code.

- Issue: The endpoint should return 401 instead of bad request on requests.

Matthias Wessendorf wrote: > I think I didn't use it, because it throws an RT exception (no problem > with that), which I could catch on the RestEasy layer. > Instead of (for unauthorized invokes) returning 401 (to cURL, for > instance), it was just "bad request". > > So, I went for the "check by code" solution first. Not saying that I am > AGAINST the interceptor. > > I think on the long run that would be better and cleaner. -- abstractj _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

Just to let you know, I opened the following jira https://issues.jboss.org/browse/AGSEC-68 and already attached a PR. The whole idea is as soon as we on the authorization model, extract it to AGSEC. I'll also start some unit testing to the endpoints. Matthias Wessendorf wrote: > > > > On Wed, Jun 19, 2013 at 6:15 PM, Bruno Oliveira <bruno(a)abstractj.org > <mailto:bruno@abstractj.org>> wrote: > > I do it, if we're not using the interceptor we're just hiding a issue > and duplicating code. > > > I agree on that :) > > > - Issue: The endpoint should return 401 instead of bad request on > requests. > > > correct. > > So, how about: > I give it another try tomorrow and will report back ? > > -Matthias > > > Matthias Wessendorf wrote: > > I think I didn't use it, because it throws an RT exception (no > problem > > with that), which I could catch on the RestEasy layer. > > Instead of (for unauthorized invokes) returning 401 (to cURL, for > > instance), it was just "bad request". > > > > So, I went for the "check by code" solution first. Not saying > that I am > > AGAINST the interceptor. > > > > I think on the long run that would be better and cleaner. > > -- > abstractj > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@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 -- abstractj _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev