Re: [Aerogear-users] Aerogear Unified Push registration through a server backend

Thanks a lot. I'll try to reformulate the logout with categories as you mentioned before. I don't know if creating a category for each username would be a valid solution. That would let me to unassigning that category on logout. Then I would filter messages by category instead alias. Do you thing it could work for 10000 username -> 10000 categories? Thanks Alex. El 20/05/15 a les 11:10, Matthias Wessendorf ha escrit: yes, that is an issue, right. However, usually you never sent sent sensitive data, you will use push as a trigger. Once the app is opened due to a push, the user has to do a login (e.g. username:password), than the app receives the real payload. I understand your concerns, and we have to take a look there, but I'd always use the above flow. -M On Wed, May 20, 2015 at 10:01 AM, Alex Ballesté < alexandre.balleste(a)udl.cat&gt; wrote: > Hi, > Yes, I was talking about getting the notifications with another > deviceToken. > > Normal flow: > > User Good Guy -> download app -> Auths -> register to UPS sending > > { > deviceToken: good_guy_device_token > variantID: VID, > variantSecret: VS > alias: user_good_guy > categories: [empty in my case] > } > > Ok - success > > Malicious flow: > > User Hacker Guy -> download app -> explores the code/debug with Chrome-> > Manipulates the authorization result and goes to the registration line and > sends: > { > deviceToken: hack_guy_device_token > variantID: VID, > variantSecret: VS, > alias: user_good_guy <--- or other valid username > categories: [empty in my case] > } > > Ok- success > > Then teacher sends a message and produces a notification to UPS in which > 'user_good_guy' is in the list of alias. Then Good guy and Hacker guy will > receive the notification, each in their devices. Isn't it? > > Thanks for the patience with my doubts. You are bringing me a great > support > > Alex. > > > El 20/05/15 a les 09:33, Erik Jan de Wit ha escrit: > > Hi Alex, > > I think you didn't get what I was saying before, so you want to > protect UPS so that these hacker students don't get all the > notifications. Say I'm such a student so I unpack the cordova app and > I have the variantId and secret. So I can create a POST on UPS to > change the alias or category but what I need is also the device token > that is used by the native push network. If I don't use the same one > that the app uses then I'll end up registering an second device > instead of modifying. So in order to modify I'll need to intercept the > initial POST to UPS see what device token is used then modify that. > Even if I get that to work the device token changes from time to time > so I'll only able to get all the notifications for a short period of > time. > > On android I could create my own app that uses the same variantId and > secret as your app and then register itself as a second device with > different alias or category. This would not work on iOS as it would > also have to use the same bundleId, but this is unique and linked to a > certificate. > > So protecting UPS to prevent students from tinkering might not be > worth the effort as it's not a simple POST to update the alias or > category. > > On Tue, May 19, 2015 at 2:36 PM, Alex Ballesté&lt;alexandre.balleste(a)udl.cat&gt; <alexandre.balleste(a)udl.cat&gt; wrote: > > Thanks for your advise Matthias, > > I understand that categories are the strong feature of UPS letting you to > send a push notification to one or more categories and then notification > will arrive to all devices subscribed to those categories. > In my case the categories don't help a lot because members of our course > sites change frequently and maintain this relationship device-categories > would be very difficult to maintain. For this reason I thought to use alias > instead of categories. > > By the other hand I understand that in the authentication methods you pasted > me relays security on the APP code execution. If code is native like those > you put, the risk to be hacked is less than using a framework like cordova. > I'm using aerogear cordova push plug-in and if I want to authenticate first > I must do it on JS and it's very vulnerable. > > I know that I always have the options of change my development framework > stack or build my "vitamined" cordova plugin, but I want to look for other > options first :-D > > In the last paragraph I wrote in my last email I mean that in order to use > cordova plugin you must provide JSON object with parameter senderID, > variantID, variantSecret. In hybrid apps those parameter are exposed to be > read them easily and it's also easy to manipulate REST calls to the UPS to > associate the device to other categories or assign other alias ... just it. > I was looking to proxy-ing to be sure that alias was the same that the > username that logged in the Backend. > > Sorry for bothering you guys. > > Alex. > > > > > El 19/05/15 a les 12:03, Matthias Wessendorf ha escrit: > > > > On Tue, May 19, 2015 at 9:40 AM, Alex Ballesté <alexandre.balleste(a)udl.cat&gt; <alexandre.balleste(a)udl.cat&gt; > wrote: > > Hi Erik, thanks for answering so quickly. I still have some gaps in my > mind; I'm sure that is because my inexperience in that area. Maybe I was > wrong choosing UPS for covering use case that was not designed for but I > still think (correct me if I'm wrong) that this scenario is possible: > > Our Learning Management System (LMS) Sakai distributes users into "sites" > corresponding to courses. Each student belong to many sites. An instructor > from a course can send announcements, messages, upload resources, etc to a > particular course site and those are only visible to the members of the > site. > > We would like to reproduce that behaviour with UPS. When a user sends an > announcement to site (and a checkbox is marked) it sends the notification to > the Messaging backend who automatically sends the notification with an array > of alias filled with the "username" of members of that site. It helps to us > to limit who receives a notification from which site ... > > we have a category > > the users device just subscribes to a category or more. > > > > > Now, on the backend, so something like: > > final UnifiedMessage unifiedMessage = UnifiedMessage > .withMessage() > .alert("Some Text") > .sound("default") > .criteria() > .categories("Class A") // or pass in more... if desired > .build(); > > sender.send(unifiedMessage, () -> > logger.info("successful delivery to UPS returned") > ); > > > > > > > > Our intention with our APP is to authenticate first, to be sure that is an > student of our university, so registration to the UPS must be done when auth > succeed (don't let anybody who downloaded the app register to the UPS if > don't belong to our institution). > > yes, we do that too: > iOS:https://github.com/aerogear/aerogear-ios-cookbook/blob/1.6.x/AeroDoc/... > Andrid:https://github.com/aerogear/aerogear-android-cookbook/blob/27b9791... > > Any time, user can choose to disconnect his account from the APP, so we > developed that when user disconnects their account from the APP it calls to > unregister, because we don't want that the APP receives more notifications. > (Maybe that is our first mistake?) > > remove the cateory > > I don't know how the UPS protects from another app to use the same > projectID to register to the service (I'll dive deeper to be sure I'm doing > things well), but I can't imagine another way to prevent that a user with > our APP manipulate the calls to UPS with other alias or categories, exposing > the notifications created from other LMS sites. I know that it's not a > critical situation because notifications should be not used to send > sensitive data, but we would like to prevent it in some way. > > not sure what you mean here > > > Thanks, > > Alex. > > > > El 18/05/15 a les 14:47, Erik Jan de Wit ha escrit: > > The problem is that you don't want/need to call unregister in a normal > flow. Unregister is used for instance when a new version of you app > drops support for push notifications. > > I don't get why you are proxy-ing the requests to UPS, because you > cannot have 2 applications receiving the same push notifications. On > iOS the bundle id makes sure of that, and on android there is the > unique project id. So even if a second app would register with UPS it > will not get the push notifications. > > On Mon, May 18, 2015 at 2:12 PM, Alex Ballesté&lt;alexandre.balleste(a)udl.cat&gt; <alexandre.balleste(a)udl.cat&gt; wrote: > > Hi, I'm developing a mobile app for android and ios for our University. It > will use AeroGear Unified Push Server to send notifications to students > when > a new announcement is sent in our LMS. > > We are developing the app with ionic framework and we are using the > register > and unregister process through a custom backend service instead of direct > from device. > > We use the cordova plugin and we call registers and unregister JS methods, > but we don't point to the push server endpoint, but backend server > instead. > Once the Backend server gets the requests it creates a new request to Push > server providing variantSecret and variantID; the response received is > sent > back to the app. > > We would like to use this flow for security reasons. We want to avoid that > the users do their own apps and use those values to register and supply > alias to get users notifications. So backend handles the security (tokens, > deviceids, usernames, ... ) and if everything is ok then proxies then > backend generates a new request fullfilling alias and real authentication > parameters and the received parameters from app. We achieved the > registation > and unregistration, but when unregistration process is done if we do a new > re-registration then we got a success response, but then notification > didn't > arrive. > > Has anybody did something similar to this approximation? Do you have any > advise or trick that would be useful for us? > > Thanks in advance > > Alex > > > > -- > > Alexandre Ballesté Crevillén alexandre.balleste at udl.cat > ==================== > Universitat de Lleida > > Àrea de sistemes d'Informació i Comunicacions > > Analista/Programador > > > University of Lleida > > Information and Communication Systems Service > > > Tlf: +34 973 702148 > > Fax: +34 973 702130 > > ===================== > > Avís legal/Aviso legal/Avertiment legal/Legal notice > > > _______________________________________________ > Aerogear-users mailing listAerogear-users@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/aerogear-users > > > > -- > > Alexandre Ballesté Crevillén alexandre.balleste at udl.cat > ==================== > Universitat de Lleida > > Àrea de sistemes d'Informació i Comunicacions > > Analista/Programador > > > University of Lleida > > Information and Communication Systems Service > > > Tlf: +34 973 702148 > > Fax: +34 973 702130 > > ===================== > > Avís legal/Aviso legal/Avertiment legal/Legal notice > > > _______________________________________________ > Aerogear-users mailing listAerogear-users@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/aerogear-users > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > > _______________________________________________ > Aerogear-users mailing listAerogear-users@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/aerogear-users > > > > -- > > Alexandre Ballesté Crevillén alexandre.balleste at udl.cat > ==================== > Universitat de Lleida > > Àrea de sistemes d'Informació i Comunicacions > > Analista/Programador > > > University of Lleida > > Information and Communication Systems Service > > > Tlf: +34 973 702148 > > Fax: +34 973 702130 > > ===================== > > Avís legal/Aviso legal/Avertiment legal/Legal notice > > > _______________________________________________ > Aerogear-users mailing listAerogear-users@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/aerogear-users > > > > -- > > Alexandre Ballesté Crevillén alexandre.balleste at udl.cat > ==================== > Universitat de Lleida > > Àrea de sistemes d'Informació i Comunicacions > > Analista/Programador > > University of Lleida > > Information and Communication Systems Service > > Tlf: +34 973 702148 <%2B34%20973%20702148> > > Fax: +34 973 702130 <%2B34%20973%20702130> > > ===================== > > Avís legal/Aviso legal/Avertiment legal/Legal notice > <http://www.imatge.udl.cat/avis_legal_lopd.html> > > _______________________________________________ > Aerogear-users mailing list > Aerogear-users(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-users > > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf _______________________________________________ Aerogear-users mailing listAerogear-users@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/aerogear-users -- Alexandre Ballesté Crevillén alexandre.balleste at udl.cat ==================== Universitat de Lleida Àrea de sistemes d'Informació i Comunicacions Analista/Programador University of Lleida Information and Communication Systems Service Tlf: +34 973 702148 Fax: +34 973 702130 ===================== Avís legal/Aviso legal/Avertiment legal/Legal notice <http://www.imatge.udl.cat/avis_legal_lopd.html> _______________________________________________ Aerogear-users mailing list Aerogear-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-users