From delkant at gmail.com  Fri May  1 10:04:19 2015
From: delkant at gmail.com (Rodrigo Del Canto)
Date: Fri, 1 May 2015 10:04:19 -0400
Subject: [Aerogear-users] UPS with an external Keycloak server
Message-ID: <CAHedXPbEjzKGJuTHc=_fStQLXJdaa-P-OqEyr2NA5Pr9VT-Kyg@mail.gmail.com>

Hello!

I would like to know... Is it possible to run a UPS war using a custom
Keycloak server in Wildfly ??

I have tried to deploy the *unifiedpush-server-wildfly.war *on a Wildfly
8.2 with Keycloak on it, but I'm getting some dependencies errors saying
that *unifiedpush-auth-server.war *is required and not installed, can I
change this? I would like to make the configurations I need to the Keycloak
instance I'm running already.

Thanks a lot!

Rodrigo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-users/attachments/20150501/227d59c2/attachment-0001.html 

From delkant at gmail.com  Fri May  1 11:27:18 2015
From: delkant at gmail.com (Rodrigo Del Canto)
Date: Fri, 1 May 2015 11:27:18 -0400
Subject: [Aerogear-users] UPS with an external Keycloak server
In-Reply-To: <CAHedXPbEjzKGJuTHc=_fStQLXJdaa-P-OqEyr2NA5Pr9VT-Kyg@mail.gmail.com>
References: <CAHedXPbEjzKGJuTHc=_fStQLXJdaa-P-OqEyr2NA5Pr9VT-Kyg@mail.gmail.com>
Message-ID: <CAHedXPYdJA1soA2BPz2kytaTh46yUpZEw-QVM+4BHSip9Le28g@mail.gmail.com>

I finally solved my problem, these are the steps:

1. Download and install wildfly 8.2
2. Get keycloak war distribution and install it:
http://docs.jboss.org/keycloak/docs/1.2.0.Beta1/userguide/html/server-installation.html#WAR_distribution_installation
3. Install JBoss/Wildfly Adapter for keycloak:
http://docs.jboss.org/keycloak/docs/1.2.0.Beta1/userguide/html/ch08.html#jboss-adapter
4. Get Aerogear UPS 1.0.3
5. Get aerogear the realm for keyclock and when you are creating a new
realm upload it:
https://raw.githubusercontent.com/aerogear/aerogear-unifiedpush-server/1.0.3/servers/auth-server/src/main/webapp/WEB-INF/ups-realm.json
6. Modify the persistence.xml inside the
*unifiedpush-server-wildfly.war/WEB-INF/lib/unifiedpush-model-jpa-1.0.3.jar
*change this line:

<property name="hibernate.hbm2ddl.auto" value="validate"/>

for

<property name="hibernate.hbm2ddl.auto" value="update"/>

7. create a datasource for both Aerogear UPS and Keycloak:

unifiedpush-ds.xml:

<?xml version="1.0" encoding="UTF-8"?>

<datasources xmlns="http://www.jboss.org/ironjacamar/schema">

  <datasource jndi-name="java:jboss/datasources/UnifiedPushDS"
pool-name="UnifiedPushDS" enabled="true" use-java-context="true">


<connection-url>jdbc:mysql://host:3306/unifiedpush?useUnicode=true&amp;characterEncoding=UTF-8</connection-url>

        <driver>com.mysql</driver>

        <security>

            <user-name>your-username</user-name>

            <password>your-secret</password>

        </security>

  </datasource>

  <datasource jndi-name="java:jboss/datasources/KeycloakDS"

                  pool-name="KeycloakDS" enabled="true"
use-java-context="true">


<connection-url>jdbc:mysql://host:3306/keycloak?useUnicode=true&amp;characterEncoding=UTF-8</connection-url>

        <driver>com.mysql</driver>

        <security>

            <user-name>your-username</user-name>

            <password>your-secret</password>

        </security>

  </datasource>

</datasources>

8. start your server

On Fri, May 1, 2015 at 10:04 AM, Rodrigo Del Canto <delkant at gmail.com>
wrote:

> Hello!
>
> I would like to know... Is it possible to run a UPS war using a custom
> Keycloak server in Wildfly ??
>
> I have tried to deploy the *unifiedpush-server-wildfly.war *on a Wildfly
> 8.2 with Keycloak on it, but I'm getting some dependencies errors saying
> that *unifiedpush-auth-server.war *is required and not installed, can I
> change this? I would like to make the configurations I need to the Keycloak
> instance I'm running already.
>
> Thanks a lot!
>
> Rodrigo
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-users/attachments/20150501/2e1ee46a/attachment.html 

From matzew at apache.org  Mon May  4 04:54:49 2015
From: matzew at apache.org (Matthias Wessendorf)
Date: Mon, 4 May 2015 10:54:49 +0200
Subject: [Aerogear-users] How to configure logging on OpenShift?
In-Reply-To: <1429644840902-9.post@n5.nabble.com>
References: <1429644840902-9.post@n5.nabble.com>
Message-ID: <CAAg5f2R2nnrOmR_2Hrrk1ZUGYWryPvo4DPPjBFNNevq4ZeN7+w@mail.gmail.com>

Hi Michi,

here is an info from an older thread:

http://lists.jboss.org/pipermail/aerogear-dev/2014-July/008204.html



On Tue, Apr 21, 2015 at 9:34 PM, mo <michi.oshima at gmail.com> wrote:

> Hi,
>
> I'm trying to get more log messages out of AeroGear Unified Server.  We
> used
> "AeroGear Unified Push Server 1.0.2 on JBoss" cartridge to host the server
> on OpenShift.  How should I go about customizing logging in this
> environment?
>
> I've naively added a "./.openshift/config/standalone.xml" (with custom
> logging) to my template repository.  It did not get deployed.
>
> Thank you,
>
> Michi Oshima
>
> P.S.: I'm currently setting up my development environment by following the
> instructions provided in another thread.  Summers, thank you very much for
> the info.
>
>
>
> --
> View this message in context:
> http://aerogear-users.1116366.n5.nabble.com/How-to-configure-logging-on-OpenShift-tp9.html
> Sent from the aerogear-users mailing list archive at Nabble.com.
> _______________________________________________
> 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/20150504/1581ab83/attachment.html 

From kpiwko at redhat.com  Mon May  4 04:57:41 2015
From: kpiwko at redhat.com (Karel Piwko)
Date: Mon, 4 May 2015 10:57:41 +0200
Subject: [Aerogear-users] How to configure logging on OpenShift?
In-Reply-To: <1429644840902-9.post@n5.nabble.com>
References: <1429644840902-9.post@n5.nabble.com>
Message-ID: <CAPXQee6Ba5oh4W8TnyxiRGG2VnpFJyQQ2EzZtZ8ox6HHctjyxg@mail.gmail.com>

Hello Michi,

are you talking about AG AS7 cartridge [1]? I'm afraid this is not possible
without manually editing content from provisioned cartridge (see
instructions from Matthias), looking into original AS7 cartridge, the hook
responsible for loading custom configuration was removed [2] [3].

I have NOT filled a feature request to make it possible as this feature is
available for WildFly one (you just need to put file there and enable via
ENV variable) [4] as AS7 cartridge have been officially deprecated.

Cheers,

Karel

[1]
https://github.com/aerogear/openshift-origin-cartridge-aerogear-push-jboss7
[2]
https://github.com/aerogear/openshift-origin-cartridge-aerogear-push-jboss7/blob/master/versions/1.0.2/bin/standalone.conf
[3]
https://github.com/openshift/origin-community-cartridges/blob/master/openshift-origin-cartridge-jbossas-7/openshift-origin-cartridge-jbossas-7.tar.gz
[4]
https://github.com/aerogear/openshift-origin-cartridge-aerogear-push/blob/master/versions/shared/bin/standalone.conf



On Tue, Apr 21, 2015 at 9:34 PM, mo <michi.oshima at gmail.com> wrote:

> Hi,
>
> I'm trying to get more log messages out of AeroGear Unified Server.  We
> used
> "AeroGear Unified Push Server 1.0.2 on JBoss" cartridge to host the server
> on OpenShift.  How should I go about customizing logging in this
> environment?
>
> I've naively added a "./.openshift/config/standalone.xml" (with custom
> logging) to my template repository.  It did not get deployed.
>
> Thank you,
>
> Michi Oshima
>
> P.S.: I'm currently setting up my development environment by following the
> instructions provided in another thread.  Summers, thank you very much for
> the info.
>
>
>
> --
> View this message in context:
> http://aerogear-users.1116366.n5.nabble.com/How-to-configure-logging-on-OpenShift-tp9.html
> Sent from the aerogear-users mailing list archive at Nabble.com.
> _______________________________________________
> Aerogear-users mailing list
> Aerogear-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-users/attachments/20150504/eaa10cb2/attachment.html 

From matzew at apache.org  Mon May  4 05:33:20 2015
From: matzew at apache.org (Matthias Wessendorf)
Date: Mon, 4 May 2015 11:33:20 +0200
Subject: [Aerogear-users] UPS with an external Keycloak server
In-Reply-To: <CAHedXPYdJA1soA2BPz2kytaTh46yUpZEw-QVM+4BHSip9Le28g@mail.gmail.com>
References: <CAHedXPbEjzKGJuTHc=_fStQLXJdaa-P-OqEyr2NA5Pr9VT-Kyg@mail.gmail.com>
	<CAHedXPYdJA1soA2BPz2kytaTh46yUpZEw-QVM+4BHSip9Le28g@mail.gmail.com>
Message-ID: <CAAg5f2SW3tJFx0WMFqREsYnTVFO6MAFbx55GJMF+Nvw2ouXAUQ@mail.gmail.com>

Hi Rodrigo, thanks for sharing these

On Fri, May 1, 2015 at 5:27 PM, Rodrigo Del Canto <delkant at gmail.com> wrote:

> I finally solved my problem, these are the steps:
>
> 1. Download and install wildfly 8.2
> 2. Get keycloak war distribution and install it:
> http://docs.jboss.org/keycloak/docs/1.2.0.Beta1/userguide/html/server-installation.html#WAR_distribution_installation
> 3. Install JBoss/Wildfly Adapter for keycloak:
> http://docs.jboss.org/keycloak/docs/1.2.0.Beta1/userguide/html/ch08.html#jboss-adapter
> 4. Get Aerogear UPS 1.0.3
> 5. Get aerogear the realm for keyclock and when you are creating a new
> realm upload it:
> https://raw.githubusercontent.com/aerogear/aerogear-unifiedpush-server/1.0.3/servers/auth-server/src/main/webapp/WEB-INF/ups-realm.json
> 6. Modify the persistence.xml inside the  *unifiedpush-server-wildfly.war/WEB-INF/lib/unifiedpush-model-jpa-1.0.3.jar
> *change this line:
>
> <property name="hibernate.hbm2ddl.auto" value="validate"/>
>
> for
>
> <property name="hibernate.hbm2ddl.auto" value="update"/>
>
> 7. create a datasource for both Aerogear UPS and Keycloak:
>
> unifiedpush-ds.xml:
>
> <?xml version="1.0" encoding="UTF-8"?>
>
> <datasources xmlns="http://www.jboss.org/ironjacamar/schema">
>
>   <datasource jndi-name="java:jboss/datasources/UnifiedPushDS"
> pool-name="UnifiedPushDS" enabled="true" use-java-context="true">
>
>
> <connection-url>jdbc:mysql://host:3306/unifiedpush?useUnicode=true&amp;characterEncoding=UTF-8</connection-url>
>
>         <driver>com.mysql</driver>
>
>         <security>
>
>             <user-name>your-username</user-name>
>
>             <password>your-secret</password>
>
>         </security>
>
>   </datasource>
>
>   <datasource jndi-name="java:jboss/datasources/KeycloakDS"
>
>                   pool-name="KeycloakDS" enabled="true"
> use-java-context="true">
>
>
> <connection-url>jdbc:mysql://host:3306/keycloak?useUnicode=true&amp;characterEncoding=UTF-8</connection-url>
>
>         <driver>com.mysql</driver>
>
>         <security>
>
>             <user-name>your-username</user-name>
>
>             <password>your-secret</password>
>
>         </security>
>
>   </datasource>
>
> </datasources>
>
> 8. start your server
>
> On Fri, May 1, 2015 at 10:04 AM, Rodrigo Del Canto <delkant at gmail.com>
> wrote:
>
>> Hello!
>>
>> I would like to know... Is it possible to run a UPS war using a custom
>> Keycloak server in Wildfly ??
>>
>> I have tried to deploy the *unifiedpush-server-wildfly.war *on a Wildfly
>> 8.2 with Keycloak on it, but I'm getting some dependencies errors saying
>> that *unifiedpush-auth-server.war *is required and not installed, can I
>> change this? I would like to make the configurations I need to the Keycloak
>> instance I'm running already.
>>
>> Thanks a lot!
>>
>> Rodrigo
>>
>
>
> _______________________________________________
> 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/20150504/f6403d98/attachment-0001.html 

From edewit at redhat.com  Wed May  6 01:44:34 2015
From: edewit at redhat.com (Erik Jan de Wit)
Date: Wed, 6 May 2015 07:44:34 +0200
Subject: [Aerogear-users] IllegalArgumentException: argument cannot be
	null
In-Reply-To: <1430410542548-22.post@n5.nabble.com>
References: <1430410542548-22.post@n5.nabble.com>
Message-ID: <CAO2B-fb33T3STvgm98O8yJ1XddPyhBYNUfLYHPysHojO_rmdbA@mail.gmail.com>

Hi,

This error is because there is no connection to gcm[1] could you
verify that there is no proxy or firewall blocking you?

[1] https://github.com/theganyo/gcm-server/blob/master/src/main/java/com/google/android/gcm/server/Sender.java#L535

On Thu, Apr 30, 2015 at 6:15 PM, eduyayo <eduyayo at gmail.com> wrote:
> Hi,
> theese last days I?ve found I cannot send push notificactions to GCM they
> always fail and I don?t have a clue about the null argument that is
> failing...
>
> Any idea on this? Stacktrace follows:
>
> 2015-04-30 12:00:37,504 SEVERE
> [org.jboss.aerogear.unifiedpush.message.sender.GCMPushNotificationSender]
> (EJB default - 1) Error sending payload to GCM server:
> java.lang.IllegalArgumentException: argument cannot be null
>         at com.google.android.gcm.server.Sender.nonNull(Sender.java:553)
> [gcm-server-1.0.2.jar:]
>         at com.google.android.gcm.server.Sender.getString(Sender.java:534)
> [gcm-server-1.0.2.jar:]
>         at com.google.android.gcm.server.Sender.sendNoRetry(Sender.java:365)
> [gcm-server-1.0.2.jar:]
>         at com.google.android.gcm.server.Sender.send(Sender.java:261)
> [gcm-server-1.0.2.jar:]
>
>
>
>
> --
> View this message in context: http://aerogear-users.1116366.n5.nabble.com/IllegalArgumentException-argument-cannot-be-null-tp22.html
> Sent from the aerogear-users mailing list archive at Nabble.com.
>
> _______________________________________________
> Aerogear-users mailing list
> Aerogear-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-users



-- 
Cheers,
       Erik Jan


From edewit at redhat.com  Thu May  7 05:15:15 2015
From: edewit at redhat.com (Erik Jan de Wit)
Date: Thu, 7 May 2015 11:15:15 +0200
Subject: [Aerogear-users] PushPlugin release 1.0.3
Message-ID: <CAO2B-fbhsdS6DDGg-UgTJX-E+s09W-ospPWeA-GCB-Ba3Ldspw@mail.gmail.com>

Hi,

This is a bug fix release of the push plugin for your testing pleasure I've
updated the 1.0.x branch to test you can run:

cordova plugin add https://github.com/aerogear/aerogear-cordova-push.git\#1.0.x

Release notes:
Bug

   - [AGCORDOVA-38 <https://issues.jboss.org/browse/AGCORDOVA-38>] -
   Authorisation error iOS is to big

Feature Request

   - [AGCORDOVA-76 <https://issues.jboss.org/browse/AGCORDOVA-76>] - Update
   Push SDK to Android 1.0.1


-- 
Cheers,
       Erik Jan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-users/attachments/20150507/545d39a3/attachment.html 

From matzew at apache.org  Thu May  7 08:17:32 2015
From: matzew at apache.org (Matthias Wessendorf)
Date: Thu, 7 May 2015 14:17:32 +0200
Subject: [Aerogear-users] PushPlugin release 1.0.3
In-Reply-To: <CAO2B-fbhsdS6DDGg-UgTJX-E+s09W-ospPWeA-GCB-Ba3Ldspw@mail.gmail.com>
References: <CAO2B-fbhsdS6DDGg-UgTJX-E+s09W-ospPWeA-GCB-Ba3Ldspw@mail.gmail.com>
Message-ID: <CAAg5f2RvEJUuBHzz++Vy-25f65rzpU2_0A1bnLyMEsfeM2HgPg@mail.gmail.com>

+1

On Thu, May 7, 2015 at 11:15 AM, Erik Jan de Wit <edewit at redhat.com> wrote:

> Hi,
>
> This is a bug fix release of the push plugin for your testing pleasure
> I've updated the 1.0.x branch to test you can run:
>
> cordova plugin add https://github.com/aerogear/aerogear-cordova-push.git\#1.0.x
>
> Release notes:
> Bug
>
>    - [AGCORDOVA-38 <https://issues.jboss.org/browse/AGCORDOVA-38>] -
>    Authorisation error iOS is to big
>
> Feature Request
>
>    - [AGCORDOVA-76 <https://issues.jboss.org/browse/AGCORDOVA-76>] -
>    Update Push SDK to Android 1.0.1
>
>
> --
> Cheers,
>        Erik Jan
>
> _______________________________________________
> 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/20150507/a66d7980/attachment.html 

From edewit at redhat.com  Wed May 13 04:26:11 2015
From: edewit at redhat.com (Erik Jan de Wit)
Date: Wed, 13 May 2015 10:26:11 +0200
Subject: [Aerogear-users] Fwd: PushPlugin release 1.0.3
In-Reply-To: <CAO2B-fbhsdS6DDGg-UgTJX-E+s09W-ospPWeA-GCB-Ba3Ldspw@mail.gmail.com>
References: <CAO2B-fbhsdS6DDGg-UgTJX-E+s09W-ospPWeA-GCB-Ba3Ldspw@mail.gmail.com>
Message-ID: <CAO2B-fauiCuWypZFKRM_NWU9fzg3i4y3oCQGb1C3Fu2AZjTUAQ@mail.gmail.com>

Hi,

Where pleased to announce that the plugin version 1.0.3 has been released.

Release notes:

Bug

[AGCORDOVA-38] - Authorisation error iOS is to big

Feature Request

[AGCORDOVA-76] - Update Push SDK to Android 1.0.1


--
Cheers,
       Erik Jan

From matzew at apache.org  Wed May 13 04:47:39 2015
From: matzew at apache.org (Matthias Wessendorf)
Date: Wed, 13 May 2015 10:47:39 +0200
Subject: [Aerogear-users] Fwd: PushPlugin release 1.0.3
In-Reply-To: <CAO2B-fauiCuWypZFKRM_NWU9fzg3i4y3oCQGb1C3Fu2AZjTUAQ@mail.gmail.com>
References: <CAO2B-fbhsdS6DDGg-UgTJX-E+s09W-ospPWeA-GCB-Ba3Ldspw@mail.gmail.com>
	<CAO2B-fauiCuWypZFKRM_NWU9fzg3i4y3oCQGb1C3Fu2AZjTUAQ@mail.gmail.com>
Message-ID: <CAAg5f2SqwNVC2Ld9hMd2JaQiepxcXxJuhAcyOPfz2KnQZYu0WQ@mail.gmail.com>

yay!!

On Wed, May 13, 2015 at 10:26 AM, Erik Jan de Wit <edewit at redhat.com> wrote:

> Hi,
>
> Where pleased to announce that the plugin version 1.0.3 has been released.
>
> Release notes:
>
> Bug
>
> [AGCORDOVA-38] - Authorisation error iOS is to big
>
> Feature Request
>
> [AGCORDOVA-76] - Update Push SDK to Android 1.0.1
>
>
> --
> Cheers,
>        Erik Jan
> _______________________________________________
> 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/20150513/80a92c5b/attachment.html 

From alexandre.balleste at udl.cat  Mon May 18 08:12:22 2015
From: alexandre.balleste at udl.cat (=?UTF-8?B?QWxleCBCYWxsZXN0w6k=?=)
Date: Mon, 18 May 2015 14:12:22 +0200
Subject: [Aerogear-users] Aerogear Unified Push registration through a
	server backend
Message-ID: <5559D726.4030209@udl.cat>

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 
<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/20150518/05c8d54a/attachment-0001.html 

From edewit at redhat.com  Mon May 18 08:47:11 2015
From: edewit at redhat.com (Erik Jan de Wit)
Date: Mon, 18 May 2015 14:47:11 +0200
Subject: [Aerogear-users] Aerogear Unified Push registration through a
 server backend
In-Reply-To: <5559D726.4030209@udl.cat>
References: <5559D726.4030209@udl.cat>
Message-ID: <CAO2B-fbL7j_gsj7oXhZpsqv74hKd9024M4o8W8gH6pMufZ5-UQ@mail.gmail.com>

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> 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 list
> Aerogear-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-users
>



-- 
Cheers,
       Erik Jan


From alexandre.balleste at udl.cat  Tue May 19 03:40:14 2015
From: alexandre.balleste at udl.cat (=?UTF-8?B?QWxleCBCYWxsZXN0w6k=?=)
Date: Tue, 19 May 2015 09:40:14 +0200
Subject: [Aerogear-users] Aerogear Unified Push registration through a
 server backend
In-Reply-To: <CAO2B-fbL7j_gsj7oXhZpsqv74hKd9024M4o8W8gH6pMufZ5-UQ@mail.gmail.com>
References: <5559D726.4030209@udl.cat>
	<CAO2B-fbL7j_gsj7oXhZpsqv74hKd9024M4o8W8gH6pMufZ5-UQ@mail.gmail.com>
Message-ID: <555AE8DE.6020300@udl.cat>

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 ...

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).

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?)

I'm not familiarized yet with iOS, we started with android but I still 
see those security problems (I guess that is produced by my 
inexperience). We are developing the APP using Ionic framework, so we 
use cordova client to do operations. The way we are setting up with a 
JSON where in the "android"
config: {
...
...
     pushServerURL: "..."
     andorid: {
         senderID: "project id",
         variantID: "...",
         varaintSecret: "..."
     }
}

The way the hybrid technology stack is built makes very easy for a user 
to connect the phone to a computer and see all the JS stuff just using 
chrome utilities. So those values are exposed and can be used to fake 
registration process.

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.

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> 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 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/6aa60bad/attachment.html 

From matzew at apache.org  Tue May 19 06:03:21 2015
From: matzew at apache.org (Matthias Wessendorf)
Date: Tue, 19 May 2015 12:03:21 +0200
Subject: [Aerogear-users] Aerogear Unified Push registration through a
 server backend
In-Reply-To: <555AE8DE.6020300@udl.cat>
References: <5559D726.4030209@udl.cat>
	<CAO2B-fbL7j_gsj7oXhZpsqv74hKd9024M4o8W8gH6pMufZ5-UQ@mail.gmail.com>
	<555AE8DE.6020300@udl.cat>
Message-ID: <CAAg5f2S8=p+yGZuKG0rsStwfoAWmJhjK_1cCaTxO9Bp1FVQtBw@mail.gmail.com>

On Tue, May 19, 2015 at 9:40 AM, Alex Ballest? <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
> <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/20150519/43419a66/attachment-0001.html 

From alexandre.balleste at udl.cat  Tue May 19 08:36:35 2015
From: alexandre.balleste at udl.cat (=?windows-1252?Q?Alex_Ballest=E9?=)
Date: Tue, 19 May 2015 14:36:35 +0200
Subject: [Aerogear-users] Aerogear Unified Push registration through a
 server backend
In-Reply-To: <CAAg5f2S8=p+yGZuKG0rsStwfoAWmJhjK_1cCaTxO9Bp1FVQtBw@mail.gmail.com>
References: <5559D726.4030209@udl.cat>	<CAO2B-fbL7j_gsj7oXhZpsqv74hKd9024M4o8W8gH6pMufZ5-UQ@mail.gmail.com>	<555AE8DE.6020300@udl.cat>
	<CAAg5f2S8=p+yGZuKG0rsStwfoAWmJhjK_1cCaTxO9Bp1FVQtBw@mail.gmail.com>
Message-ID: <555B2E53.2060908@udl.cat>

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 

From edewit at redhat.com  Wed May 20 03:33:58 2015
From: edewit at redhat.com (Erik Jan de Wit)
Date: Wed, 20 May 2015 09:33:58 +0200
Subject: [Aerogear-users] Aerogear Unified Push registration through a
 server backend
In-Reply-To: <555B2E53.2060908@udl.cat>
References: <5559D726.4030209@udl.cat>
	<CAO2B-fbL7j_gsj7oXhZpsqv74hKd9024M4o8W8gH6pMufZ5-UQ@mail.gmail.com>
	<555AE8DE.6020300@udl.cat>
	<CAAg5f2S8=p+yGZuKG0rsStwfoAWmJhjK_1cCaTxO9Bp1FVQtBw@mail.gmail.com>
	<555B2E53.2060908@udl.cat>
Message-ID: <CAO2B-fZ31yE+7FOLXc60VdmnWD56974KiGkz1prGTWGidRHE5Q@mail.gmail.com>

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> 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>
> 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> 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 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
>>
>>
>> _______________________________________________
>> 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 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
>
>
> _______________________________________________
> Aerogear-users mailing list
> Aerogear-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-users
>



-- 
Cheers,
       Erik Jan


From alexandre.balleste at udl.cat  Wed May 20 04:01:56 2015
From: alexandre.balleste at udl.cat (=?UTF-8?B?QWxleCBCYWxsZXN0w6k=?=)
Date: Wed, 20 May 2015 10:01:56 +0200
Subject: [Aerogear-users] Aerogear Unified Push registration through a
 server backend
In-Reply-To: <CAO2B-fZ31yE+7FOLXc60VdmnWD56974KiGkz1prGTWGidRHE5Q@mail.gmail.com>
References: <5559D726.4030209@udl.cat>	<CAO2B-fbL7j_gsj7oXhZpsqv74hKd9024M4o8W8gH6pMufZ5-UQ@mail.gmail.com>	<555AE8DE.6020300@udl.cat>	<CAAg5f2S8=p+yGZuKG0rsStwfoAWmJhjK_1cCaTxO9Bp1FVQtBw@mail.gmail.com>	<555B2E53.2060908@udl.cat>
	<CAO2B-fZ31yE+7FOLXc60VdmnWD56974KiGkz1prGTWGidRHE5Q@mail.gmail.com>
Message-ID: <555C3F74.5090706@udl.cat>

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> 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>
>> 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> 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 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
>>>
>>>
>>> _______________________________________________
>>> 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 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
>>
>>
>> _______________________________________________
>> 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/20150520/80192887/attachment.html 

From matzew at apache.org  Wed May 20 05:10:33 2015
From: matzew at apache.org (Matthias Wessendorf)
Date: Wed, 20 May 2015 11:10:33 +0200
Subject: [Aerogear-users] Aerogear Unified Push registration through a
 server backend
In-Reply-To: <555C3F74.5090706@udl.cat>
References: <5559D726.4030209@udl.cat>
	<CAO2B-fbL7j_gsj7oXhZpsqv74hKd9024M4o8W8gH6pMufZ5-UQ@mail.gmail.com>
	<555AE8DE.6020300@udl.cat>
	<CAAg5f2S8=p+yGZuKG0rsStwfoAWmJhjK_1cCaTxO9Bp1FVQtBw@mail.gmail.com>
	<555B2E53.2060908@udl.cat>
	<CAO2B-fZ31yE+7FOLXc60VdmnWD56974KiGkz1prGTWGidRHE5Q@mail.gmail.com>
	<555C3F74.5090706@udl.cat>
Message-ID: <CAAg5f2TZNbEYp+UJE2Rx0UU2090kbDBHkPgwC0LqLyPGW+9vmg@mail.gmail.com>

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
>
> 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/8793e163/attachment-0001.html 

From alexandre.balleste at udl.cat  Wed May 20 06:03:15 2015
From: alexandre.balleste at udl.cat (=?windows-1252?Q?Alex_Ballest=E9?=)
Date: Wed, 20 May 2015 12:03:15 +0200
Subject: [Aerogear-users] Aerogear Unified Push registration through a
 server backend
In-Reply-To: <CAAg5f2TZNbEYp+UJE2Rx0UU2090kbDBHkPgwC0LqLyPGW+9vmg@mail.gmail.com>
References: <5559D726.4030209@udl.cat>	<CAO2B-fbL7j_gsj7oXhZpsqv74hKd9024M4o8W8gH6pMufZ5-UQ@mail.gmail.com>	<555AE8DE.6020300@udl.cat>	<CAAg5f2S8=p+yGZuKG0rsStwfoAWmJhjK_1cCaTxO9Bp1FVQtBw@mail.gmail.com>	<555B2E53.2060908@udl.cat>	<CAO2B-fZ31yE+7FOLXc60VdmnWD56974KiGkz1prGTWGidRHE5Q@mail.gmail.com>	<555C3F74.5090706@udl.cat>
	<CAAg5f2TZNbEYp+UJE2Rx0UU2090kbDBHkPgwC0LqLyPGW+9vmg@mail.gmail.com>
Message-ID: <555C5BE3.5090106@udl.cat>

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 <mailto: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>  <mailto: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>  <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 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
>>>>
>>>     --
>>>     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  <mailto:Aerogear-users at lists.jboss.org>
>>>     https://lists.jboss.org/mailman/listinfo/aerogear-users
>>>
>>>
>>>
>>>     --
>>>
>>>     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/20150520/7f170572/attachment-0001.html 

From matzew at apache.org  Wed May 20 06:05:49 2015
From: matzew at apache.org (Matthias Wessendorf)
Date: Wed, 20 May 2015 12:05:49 +0200
Subject: [Aerogear-users] Aerogear Unified Push registration through a
 server backend
In-Reply-To: <555C5BE3.5090106@udl.cat>
References: <5559D726.4030209@udl.cat>
	<CAO2B-fbL7j_gsj7oXhZpsqv74hKd9024M4o8W8gH6pMufZ5-UQ@mail.gmail.com>
	<555AE8DE.6020300@udl.cat>
	<CAAg5f2S8=p+yGZuKG0rsStwfoAWmJhjK_1cCaTxO9Bp1FVQtBw@mail.gmail.com>
	<555B2E53.2060908@udl.cat>
	<CAO2B-fZ31yE+7FOLXc60VdmnWD56974KiGkz1prGTWGidRHE5Q@mail.gmail.com>
	<555C3F74.5090706@udl.cat>
	<CAAg5f2TZNbEYp+UJE2Rx0UU2090kbDBHkPgwC0LqLyPGW+9vmg@mail.gmail.com>
	<555C5BE3.5090106@udl.cat>
Message-ID: <CAAg5f2SeMJbeWxDkfdNFHyW=M2f7z1TFUfABTvBcpeKgpeLg5g@mail.gmail.com>

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