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

Wed May 20 06:05:49 EDT 2015

I would use the category as a group (E.g. classes: Math, Programming, Art)

On Wed, May 20, 2015 at 12:03 PM, Alex Ballesté <alexandre.balleste at udl.cat>
wrote:

>  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 at udl.cat> 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é<alexandre.balleste at udl.cat> <alexandre.balleste at udl.cat> 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 at udl.cat> <alexandre.balleste at udl.cat>
>> 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/AeroDoc/Classes/Controllers/AGLoginViewController.m#L153-L174
>> Andrid:https://github.com/aerogear/aerogear-android-cookbook/blob/27b9791713b9c77a2f01600ab487e8467cc62431/AeroDoc/app/src/main/java/org/jboss/aerogear/android/cookbook/aerodoc/activities/AeroDocActivity.java#L158-L167
>>
>>  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é<alexandre.balleste at udl.cat> <alexandre.balleste at udl.cat> 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-users/attachments/20150520/2ae6d5df/attachment-0001.html 