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

Alex Ballesté alexandre.balleste at udl.cat
Tue May 19 08:36:35 EDT 2015


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 <mailto: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 <http://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>  <mailto: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 atudl.cat  <http://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  <tel:%2B34%20973%20702148>
>>>
>>>     Fax:+34 973 702130  <tel:%2B34%20973%20702130>
>>>
>>>     =====================
>>>
>>>     Avís legal/Aviso legal/Avertiment legal/Legal notice
>>>
>>>
>>>     _______________________________________________
>>>     Aerogear-users mailing list
>>>     Aerogear-users at lists.jboss.org  <mailto:Aerogear-users at lists.jboss.org>
>>>     https://lists.jboss.org/mailman/listinfo/aerogear-users
>>>
>
>
>     -- 
>
>     Alexandre Ballesté Crevillén alexandre.balleste at udl.cat
>     <http://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 <tel:%2B34%20973%20702148>
>
>     Fax: +34 973 702130 <tel:%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 <mailto: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 list
> Aerogear-users at lists.jboss.org
> https://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>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-users/attachments/20150519/e13e7854/attachment.html 


More information about the Aerogear-users mailing list