From daniel.bevenius at gmail.com  Mon Jun  2 02:52:49 2014
From: daniel.bevenius at gmail.com (Daniel Bevenius)
Date: Mon, 2 Jun 2014 08:52:49 +0200
Subject: [aerogear-dev] Team meeting
Message-ID: <CAFJm-3Ec9TWGR_6W2uONYd5gy+Q+0hUoWrJBvUGbtC2_y8eRWg@mail.gmail.com>

Agenda:
http://oksoclap.com/p/aerogear-team-mgt-20140602
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140602/e7a3fc1d/attachment.html 

From matzew at apache.org  Mon Jun  2 03:11:32 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Mon, 2 Jun 2014 09:11:32 +0200
Subject: [aerogear-dev] Instructions to build admin-ui
In-Reply-To: <CAEroY36Yg+jrx1OwSZ6T=HYXEok8b9QEdtOz6tes8EFCC6gCxw@mail.gmail.com>
References: <20140530160333.GA20669@abstractj.org>
	<CAEroY36Yg+jrx1OwSZ6T=HYXEok8b9QEdtOz6tes8EFCC6gCxw@mail.gmail.com>
Message-ID: <CAAg5f2R_ESP-=P0YYhcNCW4v+Co1aNc1g4zxTm=cgEfE+bm-ug@mail.gmail.com>

On Fri, May 30, 2014 at 6:44 PM, Luk?? Fry? <lukas.fryc at gmail.com> wrote:

> Hey man,
>
> I can't find the instructions myself atm.
> (they could have been lost during merge (?))
>

hrm, yeah - surprised to see the README is no longer around



>
> I found this copy, which is almost up to date:
>
> https://github.com/lfryc/aerogear-unifiedpush-server/tree/master/admin-ui#using-with-jboss-eapwildfly
>
> Basically, run
>
> upload exploded ag-push.war/ to JBoss AS 7.1.
> $ cd admin-ui/
> $ grunt server
> modify generated local-config.json to point to that exploded war
> $ grunt server
>
> Hope it helps.
>
> Meanwhile, I will update the instructions in the master.
>
> Cheers,
>
> ~ Lukas
>
>
> On Fri, May 30, 2014 at 6:03 PM, Bruno Oliveira <bruno at abstractj.org>
> wrote:
>
>> Good morning,
>>
>> I'm looking for instructions of how to build admin-ui correctly. Where
>> could I find it?
>>
>> Currently I tried
>>
>> https://github.com/aerogear/aerogear-unifiedpush-server-admin-ui/blob/master/README.md
>> and also
>> https://github.com/aerogear/collateral/wiki/UPS-Admin-Console-Process.
>> The reason why I want this is because Sebastien managed to get it
>> working
>> https://github.com/abstractj/aerogear-unifiedpush-server/tree/angular-auth
>> and something very dirty might be happening with my environment.
>>
>> What I want to do is very simple. Trigger the following event:
>>
>> https://github.com/abstractj/aerogear-unifiedpush-server/commit/aeed989288ae0c42a8f163b303fb1d89a029b635#diff-bd44ccad477ae267b4939a7797ddc9eeR90
>> .
>>
>> I also tried to copy these files to server/src/main/webapp/ but it
>> didnt'work.
>>
>> Thanks in advance.
>>
>> --
>>
>> abstractj
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140602/6f672593/attachment.html 

From matzew at apache.org  Mon Jun  2 03:22:48 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Mon, 2 Jun 2014 09:22:48 +0200
Subject: [aerogear-dev] UPS admin-ui distribution compiled by
	frontend-maven-plugin
In-Reply-To: <CAEroY35YqT=B6G4a4YAHS5t0hgdA=gtjXjvbfUrHVHJuAF+g9Q@mail.gmail.com>
References: <CAEroY35YqT=B6G4a4YAHS5t0hgdA=gtjXjvbfUrHVHJuAF+g9Q@mail.gmail.com>
Message-ID: <CAAg5f2Qo+1JRknqU3Rotgwe9yh3NX0MBEu1VX7Vu9GxB+JFGmA@mail.gmail.com>

On Thu, May 29, 2014 at 1:43 PM, Luk?? Fry? <lukas.fryc at gmail.com> wrote:

> Hey guys,
>
> we would like to evaluate "frontend-maven-plugin" [1] that could be used
> as a mean to compile admin-ui distribution files into ag-push.war webapp
> during Maven build time
>

+1 that would be nice, as that reduces the nasty manual 'copy and check-in'
process that we have atm;

BTW. I think the Keycloak folks do similar, to include JS/HTML files that
are bundled in a JAR


>
> This way we would enable people not familiar with node/npm/bower/grunt
> tooling to compile latest and greatest,
>
> and additionally avoid a need to compile and save into git repository.
>
> https://issues.jboss.org/browse/AGPUSH-672
>
> Note1: web developer will still leverage Node tooling
>
> Note2: this is post UPS 0.11.0 thing! ;-)
>
>
> As pointed out in the JIRA, this may have its downsides,
>
> so if anyone has some concerns please speak up now. :-)
>
>
> Cheers,
>
> ~ Lukas
>
> [1] https://github.com/eirslett/frontend-maven-plugin
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140602/8fed41b4/attachment.html 

From matzew at apache.org  Mon Jun  2 03:24:53 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Mon, 2 Jun 2014 09:24:53 +0200
Subject: [aerogear-dev] UPS admin-ui distribution compiled by
	frontend-maven-plugin
In-Reply-To: <20140529130009.GA33519@abstractj.org>
References: <CAEroY35YqT=B6G4a4YAHS5t0hgdA=gtjXjvbfUrHVHJuAF+g9Q@mail.gmail.com>
	<20140529130009.GA33519@abstractj.org>
Message-ID: <CAAg5f2TjULHmm=zu2syL4wQjyX=42BZdyRxnen66CMv7odj54A@mail.gmail.com>

On Thu, May 29, 2014 at 3:00 PM, Bruno Oliveira <bruno at abstractj.org> wrote:

> Good morning, I have some n00b questions. What happens with web
> developer or node developers who don't care about Maven?


Generally that's a huge problem: requiring maven for 'web folks'; For
'pure' JS/Web projects I'd be -1 on something like this

However this case here is different, IMO;
To build the entire UPS, maven is the tool and the admin-ui itself
(standalone) is pretty useless;


-Matthias



> Is still
> possible to make use of pure node to build admin-ui?
>
> Speaking about the downsides:
>
> I think this might be a concern, if is necessary to fix something at each
> Node
> upgrade.
>
> > * he had some issues himself to get it work, especially during Node
> upgrades
> > * stability of the build can be questionable
>
> I'm not sure about the negative influence if is possible to choose. Could
> you
> please elaborate?
>
> > * it can negatively influence developers that are not aware of Node
> tooling
>
> My latest question is: do we really need this? why?
>
> On 2014-05-29, Luk?? Fry? wrote:
> > Hey guys,
> >
> > we would like to evaluate "frontend-maven-plugin" [1] that could be used
> as
> > a mean to compile admin-ui distribution files into ag-push.war webapp
> > during Maven build time
> >
> > This way we would enable people not familiar with node/npm/bower/grunt
> > tooling to compile latest and greatest,
> >
> > and additionally avoid a need to compile and save into git repository.
> >
> > https://issues.jboss.org/browse/AGPUSH-672
> >
> > Note1: web developer will still leverage Node tooling
> >
> > Note2: this is post UPS 0.11.0 thing! ;-)
> >
> >
> > As pointed out in the JIRA, this may have its downsides,
> >
> > so if anyone has some concerns please speak up now. :-)
> >
> >
> > Cheers,
> >
> > ~ Lukas
> >
> > [1] https://github.com/eirslett/frontend-maven-plugin
>
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> --
>
> abstractj
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev




-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140602/2e9ad029/attachment-0001.html 

From scm.blanc at gmail.com  Mon Jun  2 03:31:22 2014
From: scm.blanc at gmail.com (Sebastien Blanc)
Date: Mon, 2 Jun 2014 09:31:22 +0200
Subject: [aerogear-dev] Instructions to build admin-ui
In-Reply-To: <CAAg5f2R_ESP-=P0YYhcNCW4v+Co1aNc1g4zxTm=cgEfE+bm-ug@mail.gmail.com>
References: <20140530160333.GA20669@abstractj.org>
	<CAEroY36Yg+jrx1OwSZ6T=HYXEok8b9QEdtOz6tes8EFCC6gCxw@mail.gmail.com>
	<CAAg5f2R_ESP-=P0YYhcNCW4v+Co1aNc1g4zxTm=cgEfE+bm-ug@mail.gmail.com>
Message-ID: <CAD_dpu0n+-9YPDW=+3GN8V9d3PzAMiY5pHQcSMaGkm6KfUjZ9Q@mail.gmail.com>

Yes,

We are a bit in a transition phase with the complete overhaul of the
console. The old readme is not enterily up to date and could be confusing.
This JIRA has been created to track this :
https://issues.jboss.org/browse/AGPUSH-679

@abstractj: in the mean time, you can follow the instructions that Lukas
pointed out.

Sebi





On Mon, Jun 2, 2014 at 9:11 AM, Matthias Wessendorf <matzew at apache.org>
wrote:

>
>
>
> On Fri, May 30, 2014 at 6:44 PM, Luk?? Fry? <lukas.fryc at gmail.com> wrote:
>
>> Hey man,
>>
>> I can't find the instructions myself atm.
>> (they could have been lost during merge (?))
>>
>
> hrm, yeah - surprised to see the README is no longer around
>
>
>
>>
>> I found this copy, which is almost up to date:
>>
>> https://github.com/lfryc/aerogear-unifiedpush-server/tree/master/admin-ui#using-with-jboss-eapwildfly
>>
>> Basically, run
>>
>> upload exploded ag-push.war/ to JBoss AS 7.1.
>> $ cd admin-ui/
>> $ grunt server
>> modify generated local-config.json to point to that exploded war
>> $ grunt server
>>
>> Hope it helps.
>>
>> Meanwhile, I will update the instructions in the master.
>>
>> Cheers,
>>
>> ~ Lukas
>>
>>
>> On Fri, May 30, 2014 at 6:03 PM, Bruno Oliveira <bruno at abstractj.org>
>> wrote:
>>
>>> Good morning,
>>>
>>> I'm looking for instructions of how to build admin-ui correctly. Where
>>> could I find it?
>>>
>>> Currently I tried
>>>
>>> https://github.com/aerogear/aerogear-unifiedpush-server-admin-ui/blob/master/README.md
>>> and also
>>> https://github.com/aerogear/collateral/wiki/UPS-Admin-Console-Process.
>>> The reason why I want this is because Sebastien managed to get it
>>> working
>>>
>>> https://github.com/abstractj/aerogear-unifiedpush-server/tree/angular-auth
>>> and something very dirty might be happening with my environment.
>>>
>>> What I want to do is very simple. Trigger the following event:
>>>
>>> https://github.com/abstractj/aerogear-unifiedpush-server/commit/aeed989288ae0c42a8f163b303fb1d89a029b635#diff-bd44ccad477ae267b4939a7797ddc9eeR90
>>> .
>>>
>>> I also tried to copy these files to server/src/main/webapp/ but it
>>> didnt'work.
>>>
>>> Thanks in advance.
>>>
>>> --
>>>
>>> abstractj
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140602/f048b521/attachment.html 

From scm.blanc at gmail.com  Mon Jun  2 03:39:26 2014
From: scm.blanc at gmail.com (Sebastien Blanc)
Date: Mon, 2 Jun 2014 09:39:26 +0200
Subject: [aerogear-dev] [QUICKSTART] Information for the mobile clients
In-Reply-To: <CAKjsGbtZfJ1vSJfSz5pH4_UpwgJskyf+tdg2VQ8UctQduT3zGg@mail.gmail.com>
References: <CAD_dpu0q0X76hZj61FgDsqLB5D3MShknP7UXQDF0FJV+bJ7c=A@mail.gmail.com>
	<53502FF3.8010809@abstractj.org>
	<CAD_dpu0uKAwHh2vcXf3mr00O-2Za1dPG3wMdvZd4NbjfGiZQVw@mail.gmail.com>
	<CAKjsGbs1vusKkMBKFmjuqe3tC_H_ERtyaNhRxFP_9Qq1sdVaMg@mail.gmail.com>
	<CAD_dpu3v5yutnmAzwaHs5r3fRfBhHd4oY-CvqP-C5yhnD13ReA@mail.gmail.com>
	<CAKjsGbtZfJ1vSJfSz5pH4_UpwgJskyf+tdg2VQ8UctQduT3zGg@mail.gmail.com>
Message-ID: <CAD_dpu0eZ7uaHHZzQq8pTLHKi3Y0_eyB82H8qwKrC3Db_wGh2A@mail.gmail.com>

What is the issue you are having and what are you trying to do (issue just
with the update?) ?



On Fri, May 30, 2014 at 8:48 PM, Daniel Passos <daniel at passos.me> wrote:

> Someone know that I am doing wrong?
> Login
>
> curl -v -b cookies.txt -c cookies.txt \
>      -H "Accept: application/json" \
>      -H "Content-type: application/json" \
>      -u "myuser:mypass" \
>      -X GET http://quickstarts-edewit.rhcloud.com/rest/security/user/info
>
> Update Contact
>
> curl -v -b cookies.txt -c cookies.txt \
>      -H "Accept: application/json" \
>      -H "Content-type: application/json" \
>      -X PUT \
>      -d '{"firstName":"fname","lastName":"lname","phoneNumber":"1234567","email":"example at example.com", "birthDate":"2001-03-24"}' \
>       http://quickstarts-edewit.rhcloud.com/rest/contacts/7
>
> ? Passos
> ?
>
>
> On Tue, May 20, 2014 at 3:13 PM, Sebastien Blanc <scm.blanc at gmail.com>
> wrote:
>
>> Since we changed the use case for the Push part (now we broadcast) ,
>> passing a alias to UPS is not relevant anymore. For the login it's indeed
>> "loginName" to be passed in the auth header along with the password.
>>
>>
>>
>> On Tue, May 20, 2014 at 7:34 PM, Daniel Passos <daniel at passos.me> wrote:
>>
>>> To register I send "userName" and the login response "loginName"?
>>>
>>> -- Passos
>>>
>>>
>>>
>>> On Thu, Apr 17, 2014 at 6:07 PM, Sebastien Blanc <scm.blanc at gmail.com>
>>> wrote:
>>>
>>>> Sure !
>>>> This is just a version to ease the client development.
>>>> I will ask PL team and Joshua their plans around HSTS and HTTPS.
>>>> In the mean time we can track all of this with
>>>> https://issues.jboss.org/browse/AGPUSH-596
>>>>
>>>> Thx for the comment !
>>>> Sebi
>>>>
>>>>
>>>> On Thu, Apr 17, 2014 at 9:48 PM, Bruno Oliveira <bruno at abstractj.org>
>>>> wrote:
>>>>
>>>>> If your idea is to be secure, please make sure to use HTTPS and enforce
>>>>> users to be redirected. We did it in the past with HSTS on AG Security,
>>>>> might not be hard to copy & paste.
>>>>>
>>>>> Sebastien Blanc wrote:
>>>>> > And because I love you, I deployed on OpenShift a version of this
>>>>> secured
>>>>> > backend to ease the development of the clients !
>>>>> >
>>>>> > If you browse to http://contacts-sblanc.rhcloud.com/ you will even
>>>>> see the
>>>>> > mobile web client. This deployed version contains also the Push
>>>>> Message
>>>>> > endpoint.
>>>>>
>>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140602/7178e63f/attachment.html 

From kpiwko at redhat.com  Mon Jun  2 04:27:18 2014
From: kpiwko at redhat.com (Karel Piwko)
Date: Mon, 2 Jun 2014 10:27:18 +0200
Subject: [aerogear-dev] Cordova
In-Reply-To: <569E19FA-0DC8-4F26-A643-A4FF6C3C5B69@redhat.com>
References: <8DDF522B-5D78-4A05-8538-1E50425FCABE@redhat.com>
	<CAAg5f2RvF-pdNV0zTWm5e3Jt-_9MsBc7YnXAWFebj7HukFW4-w@mail.gmail.com>
	<BB9F46A1-47D9-4BBF-9971-1A6D95CFEA24@redhat.com>
	<CA+X37ck=BTNU5i8R4DOpYkRh_cOvbkrk7mxnVi07K1WVs4xQcw@mail.gmail.com>
	<569E19FA-0DC8-4F26-A643-A4FF6C3C5B69@redhat.com>
Message-ID: <20140602102718.2f5c9584@kapy-ntb-x220>

What about Arquillian approach in JIRA? geo_0.5.0, push_0.5.1, etc. Component
prefix for version. It is working quite well for a few years [1].

Karel

[1]
https://issues.jboss.org/browse/ARQ/?selectedTab=com.atlassian.jira.jira-projects-plugin:versions-panel



On Tue, 27 May 2014 16:51:23 +0200
Erik Jan de Wit <edewit at redhat.com> wrote:

> That is a very good point? so if we keep them as separate repos how do we
> manage multiple versions / releases in jira
> 
> On 27 May,2014, at 16:28 , Gorkem Ercan <gorkem.ercan at gmail.com> wrote:
> 
> > On the practical side, it makes it a bit harder to install a Cordova plugin
> > from a git repo (because you need to point to a subdir)  via Eclipse Thym
> > and Cordova CLI. -- Gorkem
> > 
> > 
> > On Tue, May 27, 2014 at 10:21 AM, Erik Jan de Wit <edewit at redhat.com> wrote:
> > We get a release of AeroGear Cordova and all it?s components. I know if you
> > want to find out what changed for each plugin and version, that will be
> > less ideal. If you have a suggestion to have it tracked better I?m all ears
> > 
> > On 27 May,2014, at 16:16 , Matthias Wessendorf <matzew at apache.org> wrote:
> > 
> >> 
> >> 
> >> 
> >> On Tue, May 27, 2014 at 4:13 PM, Erik Jan de Wit <edewit at redhat.com> wrote:
> >> Hi,
> >> 
> >> Now Cordova has it?s own jira project and therefore it?s own version
> >> number, but in github the plugins have their own repository. Would it make
> >> sense to move all the plugins into one central github repository and when
> >> making a release to release all of them?
> >> 
> >> 
> >> That means we get a few new release of the geo-plugin, while we really
> >> have just changed things on the push-plugin (as an example) ? 
> >> 
> >> -Matthias
> >>  
> >> 
> >> Wdyt?
> >>         Erik Jan
> >> ______________________________________https://github.com/arquillian/arquillian-selenium-bom/pull/9_________
> >> aerogear-dev mailing list
> >> aerogear-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >> 
> >> 
> >> 
> >> -- 
> >> Matthias Wessendorf 
> >> 
> >> blog: http://matthiaswessendorf.wordpress.com/
> >> sessions: http://www.slideshare.net/mwessendorf
> >> twitter: http://twitter.com/mwessendorf
> >> _______________________________________________
> >> aerogear-dev mailing list
> >> aerogear-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > 
> > 
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > 
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> 


From edewit at redhat.com  Mon Jun  2 04:44:01 2014
From: edewit at redhat.com (Erik Jan de Wit)
Date: Mon, 2 Jun 2014 10:44:01 +0200
Subject: [aerogear-dev] Cordova
In-Reply-To: <20140602102718.2f5c9584@kapy-ntb-x220>
References: <8DDF522B-5D78-4A05-8538-1E50425FCABE@redhat.com>
	<CAAg5f2RvF-pdNV0zTWm5e3Jt-_9MsBc7YnXAWFebj7HukFW4-w@mail.gmail.com>
	<BB9F46A1-47D9-4BBF-9971-1A6D95CFEA24@redhat.com>
	<CA+X37ck=BTNU5i8R4DOpYkRh_cOvbkrk7mxnVi07K1WVs4xQcw@mail.gmail.com>
	<569E19FA-0DC8-4F26-A643-A4FF6C3C5B69@redhat.com>
	<20140602102718.2f5c9584@kapy-ntb-x220>
Message-ID: <B2D52722-CCCF-4633-B4F5-2507AB730608@redhat.com>


On 2 Jun,2014, at 10:27 , Karel Piwko <kpiwko at redhat.com> wrote:

> What about Arquillian approach in JIRA? geo_0.5.0, push_0.5.1, etc. Component
> prefix for version. It is working quite well for a few years [1].
> 

Yeah, that sound good, I?ll use this approach, Matthias also proposed this and Gorkem had a good point not not merge the git repos. That leaves this as the best option.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140602/d77566ab/attachment.html 

From lukas.fryc at gmail.com  Mon Jun  2 04:51:13 2014
From: lukas.fryc at gmail.com (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=)
Date: Mon, 2 Jun 2014 10:51:13 +0200
Subject: [aerogear-dev] IRC meeting for Offline spec
In-Reply-To: <20140530130332.GA9911@abstractj.org>
References: <20140530130332.GA9911@abstractj.org>
Message-ID: <CAEroY374v5_ySkGYhCFhohqd=wP-EPE9dai1hzpj4KbvDbJP2A@mail.gmail.com>

+1 count me in

Just to be clear, it is related to all the client implementations, right?
iOS, Android and JS?

~ Lukas




On Fri, May 30, 2014 at 3:03 PM, Bruno Oliveira <bruno at abstractj.org> wrote:

> Good morning, after talking with Corinne and Christos we are planning a
> IRC meeting on Monday (Jun 2) 12 p.m BRT, just after our team meeting.
>
> The goal is to discuss the offline spec, what we've been planning and
> how it could help OAuth2 implementation on the client side.
>
> If you want to join, let us know.
>
> --
>
> abstractj
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140602/badb74e7/attachment.html 

From matzew at apache.org  Mon Jun  2 05:44:26 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Mon, 2 Jun 2014 11:44:26 +0200
Subject: [aerogear-dev] UnifiedPush: Identify sender client
Message-ID: <CAAg5f2RXTEsC3c7hzjXpG7dEG=KLhtW6D=gCT3bnir4aigt8kg@mail.gmail.com>

Good afternoon!

for [1] I'd like to propose we introduce a custom http-header
('aerogear-sender') to be submitted by our "clients" that perform a send in
order to show the user on the 'stats' page what client was used to submit a
'push job' to the server.

I have identified the following clients to be updated (see sub-tasks of
[1]):
* Java-Sender
* Node-Sender
* AdminUI (compose a push UI part)

On our clients we can simply apply the new custom header, however that does
not work for pure invocation of our REST APIs (e.g. via cURL or if someone
did build their own sender (E.g. some company builds an internal Ruby
sender)).  For that case I suggest to simply read the "user-agent" header.

Basic rule: If there is no "aerogear-sender" header present, we read the
value of the "user-agent" header.

Any thoughts ?

-Matthias

[1] https://issues.jboss.org/browse/AGPUSH-653



-- 
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-dev/attachments/20140602/905c16c9/attachment.html 

From scm.blanc at gmail.com  Mon Jun  2 07:30:44 2014
From: scm.blanc at gmail.com (Sebastien Blanc)
Date: Mon, 2 Jun 2014 13:30:44 +0200
Subject: [aerogear-dev] UnifiedPush: Identify sender client
In-Reply-To: <CAAg5f2RXTEsC3c7hzjXpG7dEG=KLhtW6D=gCT3bnir4aigt8kg@mail.gmail.com>
References: <CAAg5f2RXTEsC3c7hzjXpG7dEG=KLhtW6D=gCT3bnir4aigt8kg@mail.gmail.com>
Message-ID: <CAD_dpu0YT3GTvaeim0zhhmE7XQ4WyfTxF6nWAHTy0yyNp0s5EA@mail.gmail.com>

Sounds good.
Do we want to document that as well ? Because you mention the example of a
company building a Ruby Sender, maybe they would like to use that custom
header as well for their stats.



On Mon, Jun 2, 2014 at 11:44 AM, Matthias Wessendorf <matzew at apache.org>
wrote:

> Good afternoon!
>
> for [1] I'd like to propose we introduce a custom http-header
> ('aerogear-sender') to be submitted by our "clients" that perform a send in
> order to show the user on the 'stats' page what client was used to submit a
> 'push job' to the server.
>
> I have identified the following clients to be updated (see sub-tasks of
> [1]):
> * Java-Sender
> * Node-Sender
> * AdminUI (compose a push UI part)
>
> On our clients we can simply apply the new custom header, however that
> does not work for pure invocation of our REST APIs (e.g. via cURL or if
> someone did build their own sender (E.g. some company builds an internal
> Ruby sender)).  For that case I suggest to simply read the "user-agent"
> header.
>
> Basic rule: If there is no "aerogear-sender" header present, we read the
> value of the "user-agent" header.
>
> Any thoughts ?
>
> -Matthias
>
> [1] https://issues.jboss.org/browse/AGPUSH-653
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140602/15b12ec0/attachment.html 

From matzew at apache.org  Mon Jun  2 07:34:17 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Mon, 2 Jun 2014 13:34:17 +0200
Subject: [aerogear-dev] UnifiedPush: Identify sender client
In-Reply-To: <CAD_dpu0YT3GTvaeim0zhhmE7XQ4WyfTxF6nWAHTy0yyNp0s5EA@mail.gmail.com>
References: <CAAg5f2RXTEsC3c7hzjXpG7dEG=KLhtW6D=gCT3bnir4aigt8kg@mail.gmail.com>
	<CAD_dpu0YT3GTvaeim0zhhmE7XQ4WyfTxF6nWAHTy0yyNp0s5EA@mail.gmail.com>
Message-ID: <CAAg5f2SoR2LHLW3-oMmLGxdrZe4nw5LEQ+1UP1CvdqCjUo1Ehg@mail.gmail.com>

On Mon, Jun 2, 2014 at 1:30 PM, Sebastien Blanc <scm.blanc at gmail.com> wrote:

> Sounds good.
>

I've sent a PR, using the 'aerogear-sender' header:
https://github.com/aerogear/aerogear-unifiedpush-server/pull/182/files#diff-230cf59cf98db2327d2c29dad7234173R54

Let me know if someone has feelings for a different (better?) name of the
custom header;



> Do we want to document that as well ?
>


yes, eventually (e.g. on the REST API doc)



> Because you mention the example of a company building a Ruby Sender, maybe
> they would like to use that custom header as well for their stats.
>

yes, that's fine


>
>
>
> On Mon, Jun 2, 2014 at 11:44 AM, Matthias Wessendorf <matzew at apache.org>
> wrote:
>
>> Good afternoon!
>>
>> for [1] I'd like to propose we introduce a custom http-header
>> ('aerogear-sender') to be submitted by our "clients" that perform a send in
>> order to show the user on the 'stats' page what client was used to submit a
>> 'push job' to the server.
>>
>> I have identified the following clients to be updated (see sub-tasks of
>> [1]):
>> * Java-Sender
>> * Node-Sender
>> * AdminUI (compose a push UI part)
>>
>> On our clients we can simply apply the new custom header, however that
>> does not work for pure invocation of our REST APIs (e.g. via cURL or if
>> someone did build their own sender (E.g. some company builds an internal
>> Ruby sender)).  For that case I suggest to simply read the "user-agent"
>> header.
>>
>> Basic rule: If there is no "aerogear-sender" header present, we read the
>> value of the "user-agent" header.
>>
>> Any thoughts ?
>>
>> -Matthias
>>
>> [1] https://issues.jboss.org/browse/AGPUSH-653
>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> sessions: http://www.slideshare.net/mwessendorf
>> twitter: http://twitter.com/mwessendorf
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140602/d3b19208/attachment.html 

From daniel at passos.me  Mon Jun  2 08:07:04 2014
From: daniel at passos.me (Daniel Passos)
Date: Mon, 2 Jun 2014 09:07:04 -0300
Subject: [aerogear-dev] [QUICKSTART] Information for the mobile clients
In-Reply-To: <CAD_dpu0eZ7uaHHZzQq8pTLHKi3Y0_eyB82H8qwKrC3Db_wGh2A@mail.gmail.com>
References: <CAD_dpu0q0X76hZj61FgDsqLB5D3MShknP7UXQDF0FJV+bJ7c=A@mail.gmail.com>
	<53502FF3.8010809@abstractj.org>
	<CAD_dpu0uKAwHh2vcXf3mr00O-2Za1dPG3wMdvZd4NbjfGiZQVw@mail.gmail.com>
	<CAKjsGbs1vusKkMBKFmjuqe3tC_H_ERtyaNhRxFP_9Qq1sdVaMg@mail.gmail.com>
	<CAD_dpu3v5yutnmAzwaHs5r3fRfBhHd4oY-CvqP-C5yhnD13ReA@mail.gmail.com>
	<CAKjsGbtZfJ1vSJfSz5pH4_UpwgJskyf+tdg2VQ8UctQduT3zGg@mail.gmail.com>
	<CAD_dpu0eZ7uaHHZzQq8pTLHKi3Y0_eyB82H8qwKrC3Db_wGh2A@mail.gmail.com>
Message-ID: <CAKjsGbtCzXkk7tNjrKot=5zUDoH+ECtfhLEyj-56pwp8ph-oxw@mail.gmail.com>

Sorry,

Yes, I am try updating a contact and the server responded w/ status code 500


* Adding handle: conn: 0x7ff159003000
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x7ff159003000) send_pipe: 1, recv_pipe: 0
* About to connect() to quickstarts-edewit.rhcloud.com port 80 (#0)
*   Trying 50.16.176.239...
* Connected to quickstarts-edewit.rhcloud.com (50.16.176.239) port 80 (#0)
> PUT /rest/contacts/7 HTTP/1.1
> User-Agent: curl/7.30.0
> Host: quickstarts-edewit.rhcloud.com
> Cookie: JSESSIONID=zugucP2LNHLbCNNOwBrD3mx6.quickstarts-edewit.rhcloud.com
> Accept: application/json
> Content-type: application/json
> Content-Length: 120
>
* upload completely sent off: 120 out of 120 bytes
< HTTP/1.1 500 Internal Server Error
< Date: Mon, 02 Jun 2014 12:04:59 GMT
< Content-Type: text/html;charset=ISO-8859-1
< Content-Length: 80
< Connection: close
<
* Closing connection 0
<html><head><title>Error</title></head><body>Internal Server Error</body></html>

?


On Mon, Jun 2, 2014 at 4:39 AM, Sebastien Blanc <scm.blanc at gmail.com> wrote:

> What is the issue you are having and what are you trying to do (issue just
> with the update?) ?
>
>
>
> On Fri, May 30, 2014 at 8:48 PM, Daniel Passos <daniel at passos.me> wrote:
>
>> Someone know that I am doing wrong?
>> Login
>>
>> curl -v -b cookies.txt -c cookies.txt \
>>      -H "Accept: application/json" \
>>      -H "Content-type: application/json" \
>>      -u "myuser:mypass" \
>>      -X GET http://quickstarts-edewit.rhcloud.com/rest/security/user/info
>>
>> Update Contact
>>
>> curl -v -b cookies.txt -c cookies.txt \
>>      -H "Accept: application/json" \
>>      -H "Content-type: application/json" \
>>      -X PUT \
>>      -d '{"firstName":"fname","lastName":"lname","phoneNumber":"1234567","email":"example at example.com", "birthDate":"2001-03-24"}' \
>>       http://quickstarts-edewit.rhcloud.com/rest/contacts/7
>>
>> ? Passos
>> ?
>>
>>
>> On Tue, May 20, 2014 at 3:13 PM, Sebastien Blanc <scm.blanc at gmail.com>
>> wrote:
>>
>>> Since we changed the use case for the Push part (now we broadcast) ,
>>> passing a alias to UPS is not relevant anymore. For the login it's indeed
>>> "loginName" to be passed in the auth header along with the password.
>>>
>>>
>>>
>>> On Tue, May 20, 2014 at 7:34 PM, Daniel Passos <daniel at passos.me> wrote:
>>>
>>>> To register I send "userName" and the login response "loginName"?
>>>>
>>>> -- Passos
>>>>
>>>>
>>>>
>>>> On Thu, Apr 17, 2014 at 6:07 PM, Sebastien Blanc <scm.blanc at gmail.com>
>>>> wrote:
>>>>
>>>>> Sure !
>>>>> This is just a version to ease the client development.
>>>>> I will ask PL team and Joshua their plans around HSTS and HTTPS.
>>>>> In the mean time we can track all of this with
>>>>> https://issues.jboss.org/browse/AGPUSH-596
>>>>>
>>>>> Thx for the comment !
>>>>> Sebi
>>>>>
>>>>>
>>>>> On Thu, Apr 17, 2014 at 9:48 PM, Bruno Oliveira <bruno at abstractj.org>
>>>>> wrote:
>>>>>
>>>>>> If your idea is to be secure, please make sure to use HTTPS and
>>>>>> enforce
>>>>>> users to be redirected. We did it in the past with HSTS on AG
>>>>>> Security,
>>>>>> might not be hard to copy & paste.
>>>>>>
>>>>>> Sebastien Blanc wrote:
>>>>>> > And because I love you, I deployed on OpenShift a version of this
>>>>>> secured
>>>>>> > backend to ease the development of the clients !
>>>>>> >
>>>>>> > If you browse to http://contacts-sblanc.rhcloud.com/ you will even
>>>>>> see the
>>>>>> > mobile web client. This deployed version contains also the Push
>>>>>> Message
>>>>>> > endpoint.
>>>>>>
>>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140602/247b44ef/attachment-0001.html 

From scm.blanc at gmail.com  Mon Jun  2 08:10:29 2014
From: scm.blanc at gmail.com (Sebastien Blanc)
Date: Mon, 2 Jun 2014 14:10:29 +0200
Subject: [aerogear-dev] [QUICKSTART] Information for the mobile clients
In-Reply-To: <CAKjsGbtCzXkk7tNjrKot=5zUDoH+ECtfhLEyj-56pwp8ph-oxw@mail.gmail.com>
References: <CAD_dpu0q0X76hZj61FgDsqLB5D3MShknP7UXQDF0FJV+bJ7c=A@mail.gmail.com>
	<53502FF3.8010809@abstractj.org>
	<CAD_dpu0uKAwHh2vcXf3mr00O-2Za1dPG3wMdvZd4NbjfGiZQVw@mail.gmail.com>
	<CAKjsGbs1vusKkMBKFmjuqe3tC_H_ERtyaNhRxFP_9Qq1sdVaMg@mail.gmail.com>
	<CAD_dpu3v5yutnmAzwaHs5r3fRfBhHd4oY-CvqP-C5yhnD13ReA@mail.gmail.com>
	<CAKjsGbtZfJ1vSJfSz5pH4_UpwgJskyf+tdg2VQ8UctQduT3zGg@mail.gmail.com>
	<CAD_dpu0eZ7uaHHZzQq8pTLHKi3Y0_eyB82H8qwKrC3Db_wGh2A@mail.gmail.com>
	<CAKjsGbtCzXkk7tNjrKot=5zUDoH+ECtfhLEyj-56pwp8ph-oxw@mail.gmail.com>
Message-ID: <CAD_dpu2s77Nm439S3gfWV37ZXFrJDMnp2R9VDNH4qCUirdve4A@mail.gmail.com>

Your request look good but without having the application server log it's
hard to tell what is going on exactly. You could ask Erik to check the log
or deploy the backend locally.



On Mon, Jun 2, 2014 at 2:07 PM, Daniel Passos <daniel at passos.me> wrote:

> Sorry,
>
> Yes, I am try updating a contact and the server responded w/ status code
> 500
>
>
> * Adding handle: conn: 0x7ff159003000
> * Adding handle: send: 0
> * Adding handle: recv: 0
> * Curl_addHandleToPipeline: length: 1
> * - Conn 0 (0x7ff159003000) send_pipe: 1, recv_pipe: 0
> * About to connect() to quickstarts-edewit.rhcloud.com port 80 (#0)
> *   Trying 50.16.176.239...
> * Connected to quickstarts-edewit.rhcloud.com (50.16.176.239) port 80 (#0)
> > PUT /rest/contacts/7 HTTP/1.1
> > User-Agent: curl/7.30.0
> > Host: quickstarts-edewit.rhcloud.com
> > Cookie: JSESSIONID=zugucP2LNHLbCNNOwBrD3mx6.quickstarts-edewit.rhcloud.com
> > Accept: application/json
> > Content-type: application/json
> > Content-Length: 120
> >
> * upload completely sent off: 120 out of 120 bytes
> < HTTP/1.1 500 Internal Server Error
> < Date: Mon, 02 Jun 2014 12:04:59 GMT
> < Content-Type: text/html;charset=ISO-8859-1
> < Content-Length: 80
> < Connection: close
> <
> * Closing connection 0
> <html><head><title>Error</title></head><body>Internal Server Error</body></html>
>
> ?
>
>
> On Mon, Jun 2, 2014 at 4:39 AM, Sebastien Blanc <scm.blanc at gmail.com>
> wrote:
>
>> What is the issue you are having and what are you trying to do (issue
>> just with the update?) ?
>>
>>
>>
>> On Fri, May 30, 2014 at 8:48 PM, Daniel Passos <daniel at passos.me> wrote:
>>
>>> Someone know that I am doing wrong?
>>> Login
>>>
>>> curl -v -b cookies.txt -c cookies.txt \
>>>      -H "Accept: application/json" \
>>>      -H "Content-type: application/json" \
>>>      -u "myuser:mypass" \
>>>      -X GET http://quickstarts-edewit.rhcloud.com/rest/security/user/info
>>>
>>> Update Contact
>>>
>>> curl -v -b cookies.txt -c cookies.txt \
>>>      -H "Accept: application/json" \
>>>      -H "Content-type: application/json" \
>>>      -X PUT \
>>>      -d '{"firstName":"fname","lastName":"lname","phoneNumber":"1234567","email":"example at example.com", "birthDate":"2001-03-24"}' \
>>>       http://quickstarts-edewit.rhcloud.com/rest/contacts/7
>>>
>>> ? Passos
>>> ?
>>>
>>>
>>> On Tue, May 20, 2014 at 3:13 PM, Sebastien Blanc <scm.blanc at gmail.com>
>>> wrote:
>>>
>>>> Since we changed the use case for the Push part (now we broadcast) ,
>>>> passing a alias to UPS is not relevant anymore. For the login it's indeed
>>>> "loginName" to be passed in the auth header along with the password.
>>>>
>>>>
>>>>
>>>> On Tue, May 20, 2014 at 7:34 PM, Daniel Passos <daniel at passos.me>
>>>> wrote:
>>>>
>>>>> To register I send "userName" and the login response "loginName"?
>>>>>
>>>>> -- Passos
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Apr 17, 2014 at 6:07 PM, Sebastien Blanc <scm.blanc at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Sure !
>>>>>> This is just a version to ease the client development.
>>>>>> I will ask PL team and Joshua their plans around HSTS and HTTPS.
>>>>>> In the mean time we can track all of this with
>>>>>> https://issues.jboss.org/browse/AGPUSH-596
>>>>>>
>>>>>> Thx for the comment !
>>>>>> Sebi
>>>>>>
>>>>>>
>>>>>> On Thu, Apr 17, 2014 at 9:48 PM, Bruno Oliveira <bruno at abstractj.org>
>>>>>> wrote:
>>>>>>
>>>>>>> If your idea is to be secure, please make sure to use HTTPS and
>>>>>>> enforce
>>>>>>> users to be redirected. We did it in the past with HSTS on AG
>>>>>>> Security,
>>>>>>> might not be hard to copy & paste.
>>>>>>>
>>>>>>> Sebastien Blanc wrote:
>>>>>>> > And because I love you, I deployed on OpenShift a version of this
>>>>>>> secured
>>>>>>> > backend to ease the development of the clients !
>>>>>>> >
>>>>>>> > If you browse to http://contacts-sblanc.rhcloud.com/ you will
>>>>>>> even see the
>>>>>>> > mobile web client. This deployed version contains also the Push
>>>>>>> Message
>>>>>>> > endpoint.
>>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> aerogear-dev mailing list
>>>>> aerogear-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140602/b6585c39/attachment.html 

From edewit at redhat.com  Mon Jun  2 08:31:00 2014
From: edewit at redhat.com (Erik Jan de Wit)
Date: Mon, 2 Jun 2014 14:31:00 +0200
Subject: [aerogear-dev] [QUICKSTART] Information for the mobile clients
In-Reply-To: <CAD_dpu2s77Nm439S3gfWV37ZXFrJDMnp2R9VDNH4qCUirdve4A@mail.gmail.com>
References: <CAD_dpu0q0X76hZj61FgDsqLB5D3MShknP7UXQDF0FJV+bJ7c=A@mail.gmail.com>
	<53502FF3.8010809@abstractj.org>
	<CAD_dpu0uKAwHh2vcXf3mr00O-2Za1dPG3wMdvZd4NbjfGiZQVw@mail.gmail.com>
	<CAKjsGbs1vusKkMBKFmjuqe3tC_H_ERtyaNhRxFP_9Qq1sdVaMg@mail.gmail.com>
	<CAD_dpu3v5yutnmAzwaHs5r3fRfBhHd4oY-CvqP-C5yhnD13ReA@mail.gmail.com>
	<CAKjsGbtZfJ1vSJfSz5pH4_UpwgJskyf+tdg2VQ8UctQduT3zGg@mail.gmail.com>
	<CAD_dpu0eZ7uaHHZzQq8pTLHKi3Y0_eyB82H8qwKrC3Db_wGh2A@mail.gmail.com>
	<CAKjsGbtCzXkk7tNjrKot=5zUDoH+ECtfhLEyj-56pwp8ph-oxw@mail.gmail.com>
	<CAD_dpu2s77Nm439S3gfWV37ZXFrJDMnp2R9VDNH4qCUirdve4A@mail.gmail.com>
Message-ID: <65F33CC6-9BC7-4D2D-9451-D075CC0238A3@redhat.com>

Seems to be a NullPointer:

Caused by: java.lang.NullPointerException
	at org.jboss.quickstarts.wfk.contacts.customer.ContactRESTService.updateContact(ContactRESTService.java:192) [classes:]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_55]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_55]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_55]
	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_55]
	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:407)
	at org.jboss.as.weld.ejb.DelegatingInterceptorInvocationContext.proceed(DelegatingInterceptorInvocationContext.java:87) [wildfly-weld-8.1.0.CR1.jar:8.1.0.CR1]
	at org.apache.deltaspike.security.impl.extension.DefaultSecurityStrategy.execute(DefaultSecurityStrategy.java:61) [deltaspike-security-module-impl-0.5.jar:0.5]
	at org.apache.deltaspike.security.impl.extension.SecurityInterceptor.filterDeniedInvocations(SecurityInterceptor.java:44) [deltaspike-security-module-impl-0.5.jar:0.5]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_55]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_55]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_55]
	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_55]
	at org.jboss.weld.interceptor.proxy.SimpleMethodInvocation.invoke(SimpleMethodInvocation.java:30) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
	at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNext(AbstractInterceptionChain.java:103) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
	at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNextInterceptor(AbstractInterceptionChain.java:81) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
	at org.jboss.weld.bean.InterceptorImpl.intercept(InterceptorImpl.java:105) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
	at org.jboss.as.weld.ejb.DelegatingInterceptorInvocationContext.proceed(DelegatingInterceptorInvocationContext.java:77) [wildfly-weld-8.1.0.CR1.jar:8.1.0.CR1]
	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.delegateInterception(Jsr299BindingsInterceptor.java:68) [wildfly-weld-8.1.0.CR1.jar:8.1.0.CR1]
	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:80) [wildfly-weld-8.1.0.CR1.jar:8.1.0.CR1]
	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93) [wildfly-weld-8.1.0.CR1.jar:8.1.0.CR1]
	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-8.1.0.CR1.jar:8.1.0.CR1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47) [wildfly-jpa-8.1.0.CR1.jar:8.1.0.CR1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:407)
	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83) [wildfly-weld-8.1.0.CR1.jar:8.1.0.CR1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) [wildfly-ee-8.1.0.CR1.jar:8.1.0.CR1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ejb3.component.interceptors.NonPooledEJBComponentInstanceAssociatingInterceptor.processInvocation(NonPooledEJBComponentInstanceAssociatingInterceptor.java:59) [wildfly-ejb3-8.1.0.CR1.jar:8.1.0.CR1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:273) [wildfly-ejb3-8.1.0.CR1.jar:8.1.0.CR1]
	... 81 more

And that means the contact Id is null:

https://github.com/edewit/jboss-wfk-quickstarts/blob/push/contacts-mobile-picketlink-secured/src/main/java/org/jboss/quickstarts/wfk/contacts/customer/ContactRESTService.java#L192

So your data should also contain the same id as the id in the url

 -d '{"firstName":"Davey","lastName":"Jones","phoneNumber":"1(212)555-3333","email":"davey.jones at locker.com","birthDate":"1996-08-07","id?:"7"}'


On 2 Jun,2014, at 14:10 , Sebastien Blanc <scm.blanc at gmail.com> wrote:

> Your request look good but without having the application server log it's hard to tell what is going on exactly. You could ask Erik to check the log or deploy the backend locally. 
> 
> 
> 
> On Mon, Jun 2, 2014 at 2:07 PM, Daniel Passos <daniel at passos.me> wrote:
> Sorry,
> 
> Yes, I am try updating a contact and the server responded w/ status code 500
> 
> 
> * Adding handle: conn: 0x7ff159003000 
> * Adding handle: send: 0 
> * Adding handle: recv: 0 
> * Curl_addHandleToPipeline: length: 1 
> * - Conn 0 (0x7ff159003000) send_pipe: 1, recv_pipe: 0 
> * About to connect() to quickstarts-edewit.rhcloud.com port 80 (#0) 
> *   Trying 50.16.176.239... 
> * Connected to quickstarts-edewit.rhcloud.com (50.16.176.239) port 80 (#0) 
> > PUT /rest/contacts/7 HTTP/1.1 
> > User-Agent: curl/7.30.0 
> > Host: quickstarts-edewit.rhcloud.com 
> > Cookie: JSESSIONID=zugucP2LNHLbCNNOwBrD3mx6.quickstarts-edewit.rhcloud.com 
> > Accept: application/json 
> > Content-type: application/json 
> > Content-Length: 120 
> >  
> * upload completely sent off: 120 out of 120 bytes 
> < HTTP/1.1 500 Internal Server Error 
> < Date: Mon, 02 Jun 2014 12:04:59 GMT 
> < Content-Type: text/html;charset=ISO-8859-1 
> < Content-Length: 80 
> < Connection: close 
> <  
> * Closing connection 0 
> <html><head><title>Error</title></head><body>Internal Server Error</body></html>
> ?
> 
> 
> On Mon, Jun 2, 2014 at 4:39 AM, Sebastien Blanc <scm.blanc at gmail.com> wrote:
> What is the issue you are having and what are you trying to do (issue just with the update?) ? 
> 
> 
> 
> On Fri, May 30, 2014 at 8:48 PM, Daniel Passos <daniel at passos.me> wrote:
> Someone know that I am doing wrong?
> 
> Login
> 
> curl -v -b cookies.txt -c cookies.txt \
>      -H "Accept: application/json" \
>      -H "Content-type: application/json" \
>      -u "myuser:mypass" \
>      -X GET http://quickstarts-edewit.rhcloud.com/rest/security/user/info
> Update Contact
> 
> curl -v -b cookies.txt -c cookies.txt \
>      -H "Accept: application/json" \
>      -H "Content-type: application/json" \
>      -X PUT \
>      -d '{"firstName":"fname","lastName":"lname","phoneNumber":"1234567","email":"example at example.com", "birthDate":"2001-03-24"}' \
>       http://quickstarts-edewit.rhcloud.com/rest/contacts/7
> ? Passos
> 
> ?
> 
> 
> On Tue, May 20, 2014 at 3:13 PM, Sebastien Blanc <scm.blanc at gmail.com> wrote:
> Since we changed the use case for the Push part (now we broadcast) , passing a alias to UPS is not relevant anymore. For the login it's indeed "loginName" to be passed in the auth header along with the password.
>  
> 
> 
> On Tue, May 20, 2014 at 7:34 PM, Daniel Passos <daniel at passos.me> wrote:
> To register I send "userName" and the login response "loginName"?
> -- Passos
> 
> 
> 
> On Thu, Apr 17, 2014 at 6:07 PM, Sebastien Blanc <scm.blanc at gmail.com> wrote:
> Sure !
> This is just a version to ease the client development.
> I will ask PL team and Joshua their plans around HSTS and HTTPS.
> In the mean time we can track all of this with https://issues.jboss.org/browse/AGPUSH-596
> 
> Thx for the comment !
> Sebi
> 
> 
> On Thu, Apr 17, 2014 at 9:48 PM, Bruno Oliveira <bruno at abstractj.org> wrote:
> If your idea is to be secure, please make sure to use HTTPS and enforce
> users to be redirected. We did it in the past with HSTS on AG Security,
> might not be hard to copy & paste.
> 
> Sebastien Blanc wrote:
> > And because I love you, I deployed on OpenShift a version of this secured
> > backend to ease the development of the clients !
> >
> > If you browse to http://contacts-sblanc.rhcloud.com/ you will even see the
> > mobile web client. This deployed version contains also the Push Message
> > endpoint.
> 
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> 
> 
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> 
> 
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> 
> 
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> 
> 
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> 
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140602/78254344/attachment-0001.html 

From bruno at abstractj.com  Mon Jun  2 08:45:22 2014
From: bruno at abstractj.com (Bruno Oliveira)
Date: Mon, 2 Jun 2014 09:45:22 -0300
Subject: [aerogear-dev] IRC meeting for Offline spec
In-Reply-To: <CAEroY374v5_ySkGYhCFhohqd=wP-EPE9dai1hzpj4KbvDbJP2A@mail.gmail.com>
References: <20140530130332.GA9911@abstractj.org>
	<CAEroY374v5_ySkGYhCFhohqd=wP-EPE9dai1hzpj4KbvDbJP2A@mail.gmail.com>
Message-ID: <20140602124522.GD48904@abstractj.com>

Ahoy! It's related with all client implementations and you are welcome.

On 2014-06-02, Luk?? Fry? wrote:
> +1 count me in
>
> Just to be clear, it is related to all the client implementations, right?
> iOS, Android and JS?
>
> ~ Lukas
>
>
>
>
> On Fri, May 30, 2014 at 3:03 PM, Bruno Oliveira <bruno at abstractj.org> wrote:
>
> > Good morning, after talking with Corinne and Christos we are planning a
> > IRC meeting on Monday (Jun 2) 12 p.m BRT, just after our team meeting.
> >
> > The goal is to discuss the offline spec, what we've been planning and
> > how it could help OAuth2 implementation on the client side.
> >
> > If you want to join, let us know.
> >
> > --
> >
> > abstractj
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >

> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


--

abstractj

From lholmqui at redhat.com  Mon Jun  2 09:09:47 2014
From: lholmqui at redhat.com (Lucas Holmquist)
Date: Mon, 2 Jun 2014 09:09:47 -0400
Subject: [aerogear-dev] UPS admin-ui distribution compiled by
	frontend-maven-plugin
In-Reply-To: <CAAg5f2TjULHmm=zu2syL4wQjyX=42BZdyRxnen66CMv7odj54A@mail.gmail.com>
References: <CAEroY35YqT=B6G4a4YAHS5t0hgdA=gtjXjvbfUrHVHJuAF+g9Q@mail.gmail.com>
	<20140529130009.GA33519@abstractj.org>
	<CAAg5f2TjULHmm=zu2syL4wQjyX=42BZdyRxnen66CMv7odj54A@mail.gmail.com>
Message-ID: <4F5EC984-FE42-4D99-9BC2-8A20BCC273DB@redhat.com>


On Jun 2, 2014, at 3:24 AM, Matthias Wessendorf <matzew at apache.org> wrote:

> 
> 
> 
> On Thu, May 29, 2014 at 3:00 PM, Bruno Oliveira <bruno at abstractj.org> wrote:
> Good morning, I have some n00b questions. What happens with web
> developer or node developers who don't care about Maven?
> 
> Generally that's a huge problem: requiring maven for 'web folks'; For 'pure' JS/Web projects I'd be -1 on something like this
> 
> However this case here is different, IMO;
> To build the entire UPS, maven is the tool and the admin-ui itself (standalone) is pretty useless;
not entirely,  i was messing around with creating a node.js version of the UPS( following the spec's ),  and i was able to just copy the admin UI to it and it worked.



> 
> 
> -Matthias
> 
>  
> Is still
> possible to make use of pure node to build admin-ui?
> 
> Speaking about the downsides:
> 
> I think this might be a concern, if is necessary to fix something at each Node
> upgrade.
> 
> > * he had some issues himself to get it work, especially during Node
> upgrades
> > * stability of the build can be questionable
> 
> I'm not sure about the negative influence if is possible to choose. Could you
> please elaborate?
> 
> > * it can negatively influence developers that are not aware of Node
> tooling
> 
> My latest question is: do we really need this? why?
> 
> On 2014-05-29, Luk?? Fry? wrote:
> > Hey guys,
> >
> > we would like to evaluate "frontend-maven-plugin" [1] that could be used as
> > a mean to compile admin-ui distribution files into ag-push.war webapp
> > during Maven build time
> >
> > This way we would enable people not familiar with node/npm/bower/grunt
> > tooling to compile latest and greatest,
> >
> > and additionally avoid a need to compile and save into git repository.
> >
> > https://issues.jboss.org/browse/AGPUSH-672
> >
> > Note1: web developer will still leverage Node tooling
> >
> > Note2: this is post UPS 0.11.0 thing! ;-)
> >
> >
> > As pointed out in the JIRA, this may have its downsides,
> >
> > so if anyone has some concerns please speak up now. :-)
> >
> >
> > Cheers,
> >
> > ~ Lukas
> >
> > [1] https://github.com/eirslett/frontend-maven-plugin
> 
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> 
> 
> --
> 
> abstractj
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> 
> 
> 
> -- 
> Matthias Wessendorf 
> 
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140602/8d557d00/attachment.html 

From lholmqui at redhat.com  Mon Jun  2 09:10:34 2014
From: lholmqui at redhat.com (Lucas Holmquist)
Date: Mon, 2 Jun 2014 09:10:34 -0400
Subject: [aerogear-dev] UPS admin-ui distribution compiled by
	frontend-maven-plugin
In-Reply-To: <4F5EC984-FE42-4D99-9BC2-8A20BCC273DB@redhat.com>
References: <CAEroY35YqT=B6G4a4YAHS5t0hgdA=gtjXjvbfUrHVHJuAF+g9Q@mail.gmail.com>
	<20140529130009.GA33519@abstractj.org>
	<CAAg5f2TjULHmm=zu2syL4wQjyX=42BZdyRxnen66CMv7odj54A@mail.gmail.com>
	<4F5EC984-FE42-4D99-9BC2-8A20BCC273DB@redhat.com>
Message-ID: <E3C522E8-2775-487E-8FF3-57CB90144989@redhat.com>


On Jun 2, 2014, at 9:09 AM, Lucas Holmquist <lholmqui at redhat.com> wrote:

> 
> On Jun 2, 2014, at 3:24 AM, Matthias Wessendorf <matzew at apache.org> wrote:
> 
>> 
>> 
>> 
>> On Thu, May 29, 2014 at 3:00 PM, Bruno Oliveira <bruno at abstractj.org> wrote:
>> Good morning, I have some n00b questions. What happens with web
>> developer or node developers who don't care about Maven?
>> 
>> Generally that's a huge problem: requiring maven for 'web folks'; For 'pure' JS/Web projects I'd be -1 on something like this
>> 
>> However this case here is different, IMO;
>> To build the entire UPS, maven is the tool and the admin-ui itself (standalone) is pretty useless;
> not entirely,  i was messing around with creating a node.js version of the UPS( following the spec's ),  and i was able to just copy the admin UI to it and it worked.

clarification: it was the old Ember UI in that separate repo that i used

> 
> 
>> 
>> 
>> -Matthias
>> 
>>  
>> Is still
>> possible to make use of pure node to build admin-ui?
>> 
>> Speaking about the downsides:
>> 
>> I think this might be a concern, if is necessary to fix something at each Node
>> upgrade.
>> 
>> > * he had some issues himself to get it work, especially during Node
>> upgrades
>> > * stability of the build can be questionable
>> 
>> I'm not sure about the negative influence if is possible to choose. Could you
>> please elaborate?
>> 
>> > * it can negatively influence developers that are not aware of Node
>> tooling
>> 
>> My latest question is: do we really need this? why?
>> 
>> On 2014-05-29, Luk?? Fry? wrote:
>> > Hey guys,
>> >
>> > we would like to evaluate "frontend-maven-plugin" [1] that could be used as
>> > a mean to compile admin-ui distribution files into ag-push.war webapp
>> > during Maven build time
>> >
>> > This way we would enable people not familiar with node/npm/bower/grunt
>> > tooling to compile latest and greatest,
>> >
>> > and additionally avoid a need to compile and save into git repository.
>> >
>> > https://issues.jboss.org/browse/AGPUSH-672
>> >
>> > Note1: web developer will still leverage Node tooling
>> >
>> > Note2: this is post UPS 0.11.0 thing! ;-)
>> >
>> >
>> > As pointed out in the JIRA, this may have its downsides,
>> >
>> > so if anyone has some concerns please speak up now. :-)
>> >
>> >
>> > Cheers,
>> >
>> > ~ Lukas
>> >
>> > [1] https://github.com/eirslett/frontend-maven-plugin
>> 
>> > _______________________________________________
>> > aerogear-dev mailing list
>> > aerogear-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> 
>> 
>> --
>> 
>> abstractj
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> 
>> 
>> 
>> -- 
>> Matthias Wessendorf 
>> 
>> blog: http://matthiaswessendorf.wordpress.com/
>> sessions: http://www.slideshare.net/mwessendorf
>> twitter: http://twitter.com/mwessendorf
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140602/81d9144f/attachment-0001.html 

From bruno at abstractj.org  Mon Jun  2 09:24:30 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Mon, 2 Jun 2014 10:24:30 -0300
Subject: [aerogear-dev] Offline IRC meeting Agenda
Message-ID: <20140602132430.GA51012@abstractj.org>

Please, feel free to change if you want to.

http://oksoclap.com/p/eD60ucpbdg

--

abstractj

From matzew at apache.org  Mon Jun  2 09:42:24 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Mon, 2 Jun 2014 15:42:24 +0200
Subject: [aerogear-dev] UPS admin-ui distribution compiled by
	frontend-maven-plugin
In-Reply-To: <4F5EC984-FE42-4D99-9BC2-8A20BCC273DB@redhat.com>
References: <CAEroY35YqT=B6G4a4YAHS5t0hgdA=gtjXjvbfUrHVHJuAF+g9Q@mail.gmail.com>
	<20140529130009.GA33519@abstractj.org>
	<CAAg5f2TjULHmm=zu2syL4wQjyX=42BZdyRxnen66CMv7odj54A@mail.gmail.com>
	<4F5EC984-FE42-4D99-9BC2-8A20BCC273DB@redhat.com>
Message-ID: <CAAg5f2Q58+asTLxw7gSJARcaBdx2FF1fL2LDmHUFDGjnmsx4bA@mail.gmail.com>

On Mon, Jun 2, 2014 at 3:09 PM, Lucas Holmquist <lholmqui at redhat.com> wrote:

>
> On Jun 2, 2014, at 3:24 AM, Matthias Wessendorf <matzew at apache.org> wrote:
>
>
>
>
> On Thu, May 29, 2014 at 3:00 PM, Bruno Oliveira <bruno at abstractj.org>
> wrote:
>
>> Good morning, I have some n00b questions. What happens with web
>> developer or node developers who don't care about Maven?
>
>
> Generally that's a huge problem: requiring maven for 'web folks'; For
> 'pure' JS/Web projects I'd be -1 on something like this
>
> However this case here is different, IMO;
> To build the entire UPS, maven is the tool and the admin-ui itself
> (standalone) is pretty useless;
>
> not entirely,  i was messing around with creating a node.js version of the
> UPS( following the spec's ),  and i was able to just copy the admin UI to
> it and it worked.
>

The AdminUI still can be build with the vanilla JS tools - the
maven-frontend-plugin would just leverage those JS tools (as a convenience
for those that build the entire server w/ java)



>
>
>
>
>
> -Matthias
>
>
>
>> Is still
>> possible to make use of pure node to build admin-ui?
>>
>> Speaking about the downsides:
>>
>> I think this might be a concern, if is necessary to fix something at each
>> Node
>> upgrade.
>>
>> > * he had some issues himself to get it work, especially during Node
>> upgrades
>> > * stability of the build can be questionable
>>
>> I'm not sure about the negative influence if is possible to choose. Could
>> you
>> please elaborate?
>>
>> > * it can negatively influence developers that are not aware of Node
>> tooling
>>
>> My latest question is: do we really need this? why?
>>
>> On 2014-05-29, Luk?? Fry? wrote:
>> > Hey guys,
>> >
>> > we would like to evaluate "frontend-maven-plugin" [1] that could be
>> used as
>> > a mean to compile admin-ui distribution files into ag-push.war webapp
>> > during Maven build time
>> >
>> > This way we would enable people not familiar with node/npm/bower/grunt
>> > tooling to compile latest and greatest,
>> >
>> > and additionally avoid a need to compile and save into git repository.
>> >
>> > https://issues.jboss.org/browse/AGPUSH-672
>> >
>> > Note1: web developer will still leverage Node tooling
>> >
>> > Note2: this is post UPS 0.11.0 thing! ;-)
>> >
>> >
>> > As pointed out in the JIRA, this may have its downsides,
>> >
>> > so if anyone has some concerns please speak up now. :-)
>> >
>> >
>> > Cheers,
>> >
>> > ~ Lukas
>> >
>> > [1] https://github.com/eirslett/frontend-maven-plugin
>>
>> > _______________________________________________
>> > aerogear-dev mailing list
>> > aerogear-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>> --
>>
>> abstractj
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140602/651e95db/attachment.html 

From bruno at abstractj.org  Mon Jun  2 10:05:45 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Mon, 2 Jun 2014 11:05:45 -0300
Subject: [aerogear-dev] [QUICKSTART] Information for the mobile clients
In-Reply-To: <65F33CC6-9BC7-4D2D-9451-D075CC0238A3@redhat.com>
References: <CAD_dpu0q0X76hZj61FgDsqLB5D3MShknP7UXQDF0FJV+bJ7c=A@mail.gmail.com>
	<53502FF3.8010809@abstractj.org>
	<CAD_dpu0uKAwHh2vcXf3mr00O-2Za1dPG3wMdvZd4NbjfGiZQVw@mail.gmail.com>
	<CAKjsGbs1vusKkMBKFmjuqe3tC_H_ERtyaNhRxFP_9Qq1sdVaMg@mail.gmail.com>
	<CAD_dpu3v5yutnmAzwaHs5r3fRfBhHd4oY-CvqP-C5yhnD13ReA@mail.gmail.com>
	<CAKjsGbtZfJ1vSJfSz5pH4_UpwgJskyf+tdg2VQ8UctQduT3zGg@mail.gmail.com>
	<CAD_dpu0eZ7uaHHZzQq8pTLHKi3Y0_eyB82H8qwKrC3Db_wGh2A@mail.gmail.com>
	<CAKjsGbtCzXkk7tNjrKot=5zUDoH+ECtfhLEyj-56pwp8ph-oxw@mail.gmail.com>
	<CAD_dpu2s77Nm439S3gfWV37ZXFrJDMnp2R9VDNH4qCUirdve4A@mail.gmail.com>
	<65F33CC6-9BC7-4D2D-9451-D075CC0238A3@redhat.com>
Message-ID: <20140602140544.GB51012@abstractj.org>

Would make sense to file a Jira to:
https://issues.jboss.org/browse/JBWFK ?

On 2014-06-02, Erik Jan de Wit wrote:
> Seems to be a NullPointer:
>
> Caused by: java.lang.NullPointerException
> 	at org.jboss.quickstarts.wfk.contacts.customer.ContactRESTService.updateContact(ContactRESTService.java:192) [classes:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_55]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_55]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_55]
> 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_55]
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:407)
> 	at org.jboss.as.weld.ejb.DelegatingInterceptorInvocationContext.proceed(DelegatingInterceptorInvocationContext.java:87) [wildfly-weld-8.1.0.CR1.jar:8.1.0.CR1]
> 	at org.apache.deltaspike.security.impl.extension.DefaultSecurityStrategy.execute(DefaultSecurityStrategy.java:61) [deltaspike-security-module-impl-0.5.jar:0.5]
> 	at org.apache.deltaspike.security.impl.extension.SecurityInterceptor.filterDeniedInvocations(SecurityInterceptor.java:44) [deltaspike-security-module-impl-0.5.jar:0.5]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_55]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_55]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_55]
> 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_55]
> 	at org.jboss.weld.interceptor.proxy.SimpleMethodInvocation.invoke(SimpleMethodInvocation.java:30) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
> 	at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNext(AbstractInterceptionChain.java:103) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
> 	at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNextInterceptor(AbstractInterceptionChain.java:81) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
> 	at org.jboss.weld.bean.InterceptorImpl.intercept(InterceptorImpl.java:105) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
> 	at org.jboss.as.weld.ejb.DelegatingInterceptorInvocationContext.proceed(DelegatingInterceptorInvocationContext.java:77) [wildfly-weld-8.1.0.CR1.jar:8.1.0.CR1]
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.delegateInterception(Jsr299BindingsInterceptor.java:68) [wildfly-weld-8.1.0.CR1.jar:8.1.0.CR1]
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:80) [wildfly-weld-8.1.0.CR1.jar:8.1.0.CR1]
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93) [wildfly-weld-8.1.0.CR1.jar:8.1.0.CR1]
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-8.1.0.CR1.jar:8.1.0.CR1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47) [wildfly-jpa-8.1.0.CR1.jar:8.1.0.CR1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:407)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83) [wildfly-weld-8.1.0.CR1.jar:8.1.0.CR1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) [wildfly-ee-8.1.0.CR1.jar:8.1.0.CR1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.interceptors.NonPooledEJBComponentInstanceAssociatingInterceptor.processInvocation(NonPooledEJBComponentInstanceAssociatingInterceptor.java:59) [wildfly-ejb3-8.1.0.CR1.jar:8.1.0.CR1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:273) [wildfly-ejb3-8.1.0.CR1.jar:8.1.0.CR1]
> 	... 81 more
>
> And that means the contact Id is null:
>
> https://github.com/edewit/jboss-wfk-quickstarts/blob/push/contacts-mobile-picketlink-secured/src/main/java/org/jboss/quickstarts/wfk/contacts/customer/ContactRESTService.java#L192
>
> So your data should also contain the same id as the id in the url
>
>  -d '{"firstName":"Davey","lastName":"Jones","phoneNumber":"1(212)555-3333","email":"davey.jones at locker.com","birthDate":"1996-08-07","id?:"7"}'
>
>
> On 2 Jun,2014, at 14:10 , Sebastien Blanc <scm.blanc at gmail.com> wrote:
>
> > Your request look good but without having the application server log it's hard to tell what is going on exactly. You could ask Erik to check the log or deploy the backend locally.
> >
> >
> >
> > On Mon, Jun 2, 2014 at 2:07 PM, Daniel Passos <daniel at passos.me> wrote:
> > Sorry,
> >
> > Yes, I am try updating a contact and the server responded w/ status code 500
> >
> >
> > * Adding handle: conn: 0x7ff159003000
> > * Adding handle: send: 0
> > * Adding handle: recv: 0
> > * Curl_addHandleToPipeline: length: 1
> > * - Conn 0 (0x7ff159003000) send_pipe: 1, recv_pipe: 0
> > * About to connect() to quickstarts-edewit.rhcloud.com port 80 (#0)
> > *   Trying 50.16.176.239...
> > * Connected to quickstarts-edewit.rhcloud.com (50.16.176.239) port 80 (#0)
> > > PUT /rest/contacts/7 HTTP/1.1
> > > User-Agent: curl/7.30.0
> > > Host: quickstarts-edewit.rhcloud.com
> > > Cookie: JSESSIONID=zugucP2LNHLbCNNOwBrD3mx6.quickstarts-edewit.rhcloud.com
> > > Accept: application/json
> > > Content-type: application/json
> > > Content-Length: 120
> > >
> > * upload completely sent off: 120 out of 120 bytes
> > < HTTP/1.1 500 Internal Server Error
> > < Date: Mon, 02 Jun 2014 12:04:59 GMT
> > < Content-Type: text/html;charset=ISO-8859-1
> > < Content-Length: 80
> > < Connection: close
> > <
> > * Closing connection 0
> > <html><head><title>Error</title></head><body>Internal Server Error</body></html>
> > ?
> >
> >
> > On Mon, Jun 2, 2014 at 4:39 AM, Sebastien Blanc <scm.blanc at gmail.com> wrote:
> > What is the issue you are having and what are you trying to do (issue just with the update?) ?
> >
> >
> >
> > On Fri, May 30, 2014 at 8:48 PM, Daniel Passos <daniel at passos.me> wrote:
> > Someone know that I am doing wrong?
> >
> > Login
> >
> > curl -v -b cookies.txt -c cookies.txt \
> >      -H "Accept: application/json" \
> >      -H "Content-type: application/json" \
> >      -u "myuser:mypass" \
> >      -X GET http://quickstarts-edewit.rhcloud.com/rest/security/user/info
> > Update Contact
> >
> > curl -v -b cookies.txt -c cookies.txt \
> >      -H "Accept: application/json" \
> >      -H "Content-type: application/json" \
> >      -X PUT \
> >      -d '{"firstName":"fname","lastName":"lname","phoneNumber":"1234567","email":"example at example.com", "birthDate":"2001-03-24"}' \
> >       http://quickstarts-edewit.rhcloud.com/rest/contacts/7
> > ? Passos
> >
> > ?
> >
> >
> > On Tue, May 20, 2014 at 3:13 PM, Sebastien Blanc <scm.blanc at gmail.com> wrote:
> > Since we changed the use case for the Push part (now we broadcast) , passing a alias to UPS is not relevant anymore. For the login it's indeed "loginName" to be passed in the auth header along with the password.
> >
> >
> >
> > On Tue, May 20, 2014 at 7:34 PM, Daniel Passos <daniel at passos.me> wrote:
> > To register I send "userName" and the login response "loginName"?
> > -- Passos
> >
> >
> >
> > On Thu, Apr 17, 2014 at 6:07 PM, Sebastien Blanc <scm.blanc at gmail.com> wrote:
> > Sure !
> > This is just a version to ease the client development.
> > I will ask PL team and Joshua their plans around HSTS and HTTPS.
> > In the mean time we can track all of this with https://issues.jboss.org/browse/AGPUSH-596
> >
> > Thx for the comment !
> > Sebi
> >
> >
> > On Thu, Apr 17, 2014 at 9:48 PM, Bruno Oliveira <bruno at abstractj.org> wrote:
> > If your idea is to be secure, please make sure to use HTTPS and enforce
> > users to be redirected. We did it in the past with HSTS on AG Security,
> > might not be hard to copy & paste.
> >
> > Sebastien Blanc wrote:
> > > And because I love you, I deployed on OpenShift a version of this secured
> > > backend to ease the development of the clients !
> > >
> > > If you browse to http://contacts-sblanc.rhcloud.com/ you will even see the
> > > mobile web client. This deployed version contains also the Push Message
> > > endpoint.
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>

> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


--

abstractj

From cvasilak at gmail.com  Mon Jun  2 10:13:25 2014
From: cvasilak at gmail.com (Christos Vasilakis)
Date: Mon, 2 Jun 2014 17:13:25 +0300
Subject: [aerogear-dev] Team meeting
In-Reply-To: <CAFJm-3Ec9TWGR_6W2uONYd5gy+Q+0hUoWrJBvUGbtC2_y8eRWg@mail.gmail.com>
References: <CAFJm-3Ec9TWGR_6W2uONYd5gy+Q+0hUoWrJBvUGbtC2_y8eRWg@mail.gmail.com>
Message-ID: <E474F4B2-27C7-4C43-BA78-638E994F68A4@gmail.com>

fyi, 
meeting minutes:

<jbott>	 Meeting ended Mon Jun  2 13:55:20 2014 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
<jbott>	 Minutes:        http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-06-02-13.43.html
<jbott>	 Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-06-02-13.43.txt
<jbott>	 Log:            http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-06-02-13.43.log.html


On Jun 2, 2014, at 9:52 AM, Daniel Bevenius <daniel.bevenius at gmail.com> wrote:

> Agenda:
> http://oksoclap.com/p/aerogear-team-mgt-20140602
> 
> 
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140602/76510818/attachment.html 

From matzew at apache.org  Mon Jun  2 10:27:44 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Mon, 2 Jun 2014 16:27:44 +0200
Subject: [aerogear-dev] First go at stats/activity wireframes
In-Reply-To: <CAAg5f2Rne99mhV8p4Ux0mvvA2Fvir8EZe4aWkhDs_xwObyXw8Q@mail.gmail.com>
References: <5374DB1B.9020405@redhat.com> <53888A9D.8020308@redhat.com>
	<CAD_dpu2P3nW2pVPDd8HhJiBofDjqrmQ_W-6D1TC8H-WoaGQZFQ@mail.gmail.com>
	<CAAg5f2Rne99mhV8p4Ux0mvvA2Fvir8EZe4aWkhDs_xwObyXw8Q@mail.gmail.com>
Message-ID: <CAAg5f2Qd6_jpLVD1O14s5r268hwbgYpozOkyY-K8Trh707jA8Q@mail.gmail.com>

Hylke,

I marked this as well as resolved:
https://issues.jboss.org/browse/AGPUSH-654

Can you check if there are some more JIRAs assigned to you, related to UX
on AGPUSH ?


On Sat, May 31, 2014 at 7:28 AM, Matthias Wessendorf <matzew at apache.org>
wrote:

> Awesome!
>
> Hylke, I marked your two tickets as resolved:
> https://issues.jboss.org/browse/AGPUSH-579
> https://issues.jboss.org/browse/AGPUSH-580
>
> @Sebi: I assigned this to you:
> https://issues.jboss.org/browse/AGPUSH-636
>
>
> On Fri, May 30, 2014 at 4:00 PM, Sebastien Blanc <scm.blanc at gmail.com>
> wrote:
>
>> Hey !
>>
>> Looks nice !
>> I will probably start integrating this on Monday.
>>
>> Sebi
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>



-- 
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-dev/attachments/20140602/0656f616/attachment.html 

From daniel at passos.me  Mon Jun  2 10:35:49 2014
From: daniel at passos.me (Daniel Passos)
Date: Mon, 2 Jun 2014 11:35:49 -0300
Subject: [aerogear-dev] [status] Quickstarts for Mobile Push 1.0.0
 community release
In-Reply-To: <CAAg5f2QE_6mp+EFuOhkb=GCfo_OpkDTZmWroMj25QJpKaOsHbA@mail.gmail.com>
References: <CAAg5f2QE_6mp+EFuOhkb=GCfo_OpkDTZmWroMj25QJpKaOsHbA@mail.gmail.com>
Message-ID: <CAKjsGbtCmvTp0UyusmXymu6PTGw_EXAZLOHqC7pk3SDM7Zfyvg@mail.gmail.com>

I renamed the android client directory
to contacts-mobile-android-client[1]. Should I use the same in
artifactId[2]?

[1]:  https://github.com/danielpassos/aerogear-push-quickstarts/tree/android
[2]:
https://github.com/danielpassos/aerogear-push-quickstarts/blob/android/contacts-mobile-android-client/pom.xml#L8

-- Passos


On Wed, May 28, 2014 at 11:00 AM, Matthias Wessendorf <matzew at apache.org>
wrote:

> Hello,
>
> we just met for the quickstarts; The work should be done by mid June or
> earlier. So that we have all of that working fine and polished for our
> Face2Face meeting.
>  <https://gist.github.com/matzew/459590aa794c5f97c99a#server>SERVER
>
>    - Josh's PicketLink/JAX-RS version is almost there (a few things to
>    polish)
>    - Dan worked with James on a gateway version (using Fabric8, see [1])
>    (The idea is have the mobile devices talk to the gateway and have the
>    gateway/proxy do the work against the JAX-RS app (that might behind the
>    firewall))
>
> <https://gist.github.com/matzew/459590aa794c5f97c99a#clients>CLIENTS
>
>    - Passos is about to finish the Android version
>    - Christos is about to finish the iOS version
>    - Cordova versions (jqm / Angular) are done, by Erik
>
>
> <https://gist.github.com/matzew/459590aa794c5f97c99a#structure-of-the-gh-repo>Structure
> of the GH REPO
>
> /servers/
> ... /contacts-mobile-picketlink-secured
> ... /contacts-mobile-proxy
> /clients/
> ... /cordova/
> ...... /contacts-mobile-cordova-jqm-client
> ...... /contacts-mobile-cordova-angular-client
> ... /contacts-mobile-android-client
> ... /contacts-mobile-ios-client
>
>
>    - If time allows (we think yes), the 'web-app' from the PL/JAXRS will
>    be a separated WAR file
>
>  <https://gist.github.com/matzew/459590aa794c5f97c99a#issues>ISSUES
>
>    - jqm has issues with older androids; Well, according to the team only
>    Android 4.4 only works 'acceptable' w/ JQM
>    - Erik suggested removing the transitions (might make things faster)
>
> We will revist next week, otherwise Luke/Lukas might get a 'chance' :-) to
> take a look as well
>
> Any questions ?
>
> -Matthias
>
> [1] https://github.com/fabric8io/fabric8/tree/master/gateway
>
> --
> 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-dev/attachments/20140602/0c453efd/attachment.html 

From kpiwko at redhat.com  Mon Jun  2 10:40:35 2014
From: kpiwko at redhat.com (Karel Piwko)
Date: Mon, 2 Jun 2014 16:40:35 +0200
Subject: [aerogear-dev] UPS admin-ui distribution compiled by
 frontend-maven-plugin
In-Reply-To: <CAEroY35YqT=B6G4a4YAHS5t0hgdA=gtjXjvbfUrHVHJuAF+g9Q@mail.gmail.com>
References: <CAEroY35YqT=B6G4a4YAHS5t0hgdA=gtjXjvbfUrHVHJuAF+g9Q@mail.gmail.com>
Message-ID: <20140602164035.03c2060e@kapy-ntb-x220>

I like this idea due to fact it reduces number of manual steps needed to build
UPS server WAR via a single command. Ideal for JS noobs such as myself. 

I don't like the fact that it could introduce test result inconsistencies, e.g.:

Alice: I can't register new variant via UI.
Bob: Which UPS version are you running?
Alice: Latest from master.
Bob: Works for me.
...both debugging...
Bob: Can you rebuild UPS? There was new UI with the fix committed meanwhile. 

So, I believe that adding such plugin is a good idea if we keep UPS track a
specific non-movable commit from UI repository.

Karel


On Thu, 29 May 2014 13:43:02 +0200
Luk?? Fry? <lukas.fryc at gmail.com> wrote:

> Hey guys,
> 
> we would like to evaluate "frontend-maven-plugin" [1] that could be used as
> a mean to compile admin-ui distribution files into ag-push.war webapp
> during Maven build time
> 
> This way we would enable people not familiar with node/npm/bower/grunt
> tooling to compile latest and greatest,
> 
> and additionally avoid a need to compile and save into git repository.
> 
> https://issues.jboss.org/browse/AGPUSH-672
> 
> Note1: web developer will still leverage Node tooling
> 
> Note2: this is post UPS 0.11.0 thing! ;-)
> 
> 
> As pointed out in the JIRA, this may have its downsides,
> 
> so if anyone has some concerns please speak up now. :-)
> 
> 
> Cheers,
> 
> ~ Lukas
> 
> [1] https://github.com/eirslett/frontend-maven-plugin



From matzew at apache.org  Mon Jun  2 11:17:04 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Mon, 2 Jun 2014 17:17:04 +0200
Subject: [aerogear-dev] UPS admin-ui distribution compiled by
	frontend-maven-plugin
In-Reply-To: <20140602164035.03c2060e@kapy-ntb-x220>
References: <CAEroY35YqT=B6G4a4YAHS5t0hgdA=gtjXjvbfUrHVHJuAF+g9Q@mail.gmail.com>
	<20140602164035.03c2060e@kapy-ntb-x220>
Message-ID: <CAAg5f2Srvm9DoWcY9MP451xqOw7B__9MMa0vNdE+pTNYgkTePQ@mail.gmail.com>

running againt master is IMO also using the latest development;

If folks want stable, have them use released versions, instead of master


On Mon, Jun 2, 2014 at 4:40 PM, Karel Piwko <kpiwko at redhat.com> wrote:

> I like this idea due to fact it reduces number of manual steps needed to
> build
> UPS server WAR via a single command. Ideal for JS noobs such as myself.
>
> I don't like the fact that it could introduce test result inconsistencies,
> e.g.:
>
> Alice: I can't register new variant via UI.
> Bob: Which UPS version are you running?
> Alice: Latest from master.
> Bob: Works for me.
> ...both debugging...
> Bob: Can you rebuild UPS? There was new UI with the fix committed
> meanwhile.
>
> So, I believe that adding such plugin is a good idea if we keep UPS track a
> specific non-movable commit from UI repository.
>
> Karel
>
>
> On Thu, 29 May 2014 13:43:02 +0200
> Luk?? Fry? <lukas.fryc at gmail.com> wrote:
>
> > Hey guys,
> >
> > we would like to evaluate "frontend-maven-plugin" [1] that could be used
> as
> > a mean to compile admin-ui distribution files into ag-push.war webapp
> > during Maven build time
> >
> > This way we would enable people not familiar with node/npm/bower/grunt
> > tooling to compile latest and greatest,
> >
> > and additionally avoid a need to compile and save into git repository.
> >
> > https://issues.jboss.org/browse/AGPUSH-672
> >
> > Note1: web developer will still leverage Node tooling
> >
> > Note2: this is post UPS 0.11.0 thing! ;-)
> >
> >
> > As pointed out in the JIRA, this may have its downsides,
> >
> > so if anyone has some concerns please speak up now. :-)
> >
> >
> > Cheers,
> >
> > ~ Lukas
> >
> > [1] https://github.com/eirslett/frontend-maven-plugin
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140602/719368f2/attachment-0001.html 

From kpiwko at redhat.com  Mon Jun  2 11:34:02 2014
From: kpiwko at redhat.com (Karel Piwko)
Date: Mon, 2 Jun 2014 17:34:02 +0200
Subject: [aerogear-dev] UPS admin-ui distribution compiled by
 frontend-maven-plugin
In-Reply-To: <CAAg5f2Srvm9DoWcY9MP451xqOw7B__9MMa0vNdE+pTNYgkTePQ@mail.gmail.com>
References: <CAEroY35YqT=B6G4a4YAHS5t0hgdA=gtjXjvbfUrHVHJuAF+g9Q@mail.gmail.com>
	<20140602164035.03c2060e@kapy-ntb-x220>
	<CAAg5f2Srvm9DoWcY9MP451xqOw7B__9MMa0vNdE+pTNYgkTePQ@mail.gmail.com>
Message-ID: <20140602173402.3896e648@kapy-ntb-x220>

On Mon, 2 Jun 2014 17:17:04 +0200
Matthias Wessendorf <matzew at apache.org> wrote:

> running againt master is IMO also using the latest development;
> 
> If folks want stable, have them use released versions, instead of master

Correct but the plugin would hide the fact there are two masters involved. If
we had UI as <dependency> with version -SNAPSHOT in pom.xml, that's a different
thing.

> 
> 
> On Mon, Jun 2, 2014 at 4:40 PM, Karel Piwko <kpiwko at redhat.com> wrote:
> 
> > I like this idea due to fact it reduces number of manual steps needed to
> > build
> > UPS server WAR via a single command. Ideal for JS noobs such as myself.
> >
> > I don't like the fact that it could introduce test result inconsistencies,
> > e.g.:
> >
> > Alice: I can't register new variant via UI.
> > Bob: Which UPS version are you running?
> > Alice: Latest from master.
> > Bob: Works for me.
> > ...both debugging...
> > Bob: Can you rebuild UPS? There was new UI with the fix committed
> > meanwhile.
> >
> > So, I believe that adding such plugin is a good idea if we keep UPS track a
> > specific non-movable commit from UI repository.
> >
> > Karel
> >
> >
> > On Thu, 29 May 2014 13:43:02 +0200
> > Luk?? Fry? <lukas.fryc at gmail.com> wrote:
> >
> > > Hey guys,
> > >
> > > we would like to evaluate "frontend-maven-plugin" [1] that could be used
> > as
> > > a mean to compile admin-ui distribution files into ag-push.war webapp
> > > during Maven build time
> > >
> > > This way we would enable people not familiar with node/npm/bower/grunt
> > > tooling to compile latest and greatest,
> > >
> > > and additionally avoid a need to compile and save into git repository.
> > >
> > > https://issues.jboss.org/browse/AGPUSH-672
> > >
> > > Note1: web developer will still leverage Node tooling
> > >
> > > Note2: this is post UPS 0.11.0 thing! ;-)
> > >
> > >
> > > As pointed out in the JIRA, this may have its downsides,
> > >
> > > so if anyone has some concerns please speak up now. :-)
> > >
> > >
> > > Cheers,
> > >
> > > ~ Lukas
> > >
> > > [1] https://github.com/eirslett/frontend-maven-plugin
> >
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> 
> 
> 



From matzew at apache.org  Mon Jun  2 11:55:43 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Mon, 2 Jun 2014 17:55:43 +0200
Subject: [aerogear-dev] UPS admin-ui distribution compiled by
	frontend-maven-plugin
In-Reply-To: <20140602173402.3896e648@kapy-ntb-x220>
References: <CAEroY35YqT=B6G4a4YAHS5t0hgdA=gtjXjvbfUrHVHJuAF+g9Q@mail.gmail.com>
	<20140602164035.03c2060e@kapy-ntb-x220>
	<CAAg5f2Srvm9DoWcY9MP451xqOw7B__9MMa0vNdE+pTNYgkTePQ@mail.gmail.com>
	<20140602173402.3896e648@kapy-ntb-x220>
Message-ID: <CAAg5f2QMxEwbMK3MFXPhdahq2yP15=GkLbc3BSD+k8kHEuCTOg@mail.gmail.com>

On Mon, Jun 2, 2014 at 5:34 PM, Karel Piwko <kpiwko at redhat.com> wrote:

> On Mon, 2 Jun 2014 17:17:04 +0200
> Matthias Wessendorf <matzew at apache.org> wrote:
>
> > running againt master is IMO also using the latest development;
> >
> > If folks want stable, have them use released versions, instead of master
>
> Correct but the plugin would hide the fact there are two masters involved.


two masters? master in terms of git?


> If
> we had UI as <dependency> with version -SNAPSHOT in pom.xml, that's a
> different
> thing.
>

as said earlier, I think Keycloak does that. But I am not sure on the
details of the UI bundling


>
> >
> >
> > On Mon, Jun 2, 2014 at 4:40 PM, Karel Piwko <kpiwko at redhat.com> wrote:
> >
> > > I like this idea due to fact it reduces number of manual steps needed
> to
> > > build
> > > UPS server WAR via a single command. Ideal for JS noobs such as myself.
> > >
> > > I don't like the fact that it could introduce test result
> inconsistencies,
> > > e.g.:
> > >
> > > Alice: I can't register new variant via UI.
> > > Bob: Which UPS version are you running?
> > > Alice: Latest from master.
> > > Bob: Works for me.
> > > ...both debugging...
> > > Bob: Can you rebuild UPS? There was new UI with the fix committed
> > > meanwhile.
> > >
> > > So, I believe that adding such plugin is a good idea if we keep UPS
> track a
> > > specific non-movable commit from UI repository.
> > >
> > > Karel
> > >
> > >
> > > On Thu, 29 May 2014 13:43:02 +0200
> > > Luk?? Fry? <lukas.fryc at gmail.com> wrote:
> > >
> > > > Hey guys,
> > > >
> > > > we would like to evaluate "frontend-maven-plugin" [1] that could be
> used
> > > as
> > > > a mean to compile admin-ui distribution files into ag-push.war webapp
> > > > during Maven build time
> > > >
> > > > This way we would enable people not familiar with
> node/npm/bower/grunt
> > > > tooling to compile latest and greatest,
> > > >
> > > > and additionally avoid a need to compile and save into git
> repository.
> > > >
> > > > https://issues.jboss.org/browse/AGPUSH-672
> > > >
> > > > Note1: web developer will still leverage Node tooling
> > > >
> > > > Note2: this is post UPS 0.11.0 thing! ;-)
> > > >
> > > >
> > > > As pointed out in the JIRA, this may have its downsides,
> > > >
> > > > so if anyone has some concerns please speak up now. :-)
> > > >
> > > >
> > > > Cheers,
> > > >
> > > > ~ Lukas
> > > >
> > > > [1] https://github.com/eirslett/frontend-maven-plugin
> > >
> > >
> > > _______________________________________________
> > > aerogear-dev mailing list
> > > aerogear-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > >
> >
> >
> >
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140602/e2988565/attachment.html 

From bruno at abstractj.org  Mon Jun  2 12:06:15 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Mon, 2 Jun 2014 13:06:15 -0300
Subject: [aerogear-dev] Offline IRC meeting Agenda
In-Reply-To: <20140602132430.GA51012@abstractj.org>
References: <20140602132430.GA51012@abstractj.org>
Message-ID: <20140602160615.GD51012@abstractj.org>

Meeting minutes:

[13:04]  jbott:jbott Ending meeting. Generating minutes. Be patient :)
[13:04]  jbott:jbott Meeting ended Mon Jun  2 15:47:57 2014 UTC.
Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
[13:04]  jbott:jbott Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-06-02-14.43.html
[13:04]  jbott:jbott Minutes (text):
http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-06-02-14.43.txt
[13:04]  jbott:jbott Log:
http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-06-02-14.43.log.html

On 2014-06-02, Bruno Oliveira wrote:
> Please, feel free to change if you want to.
>
> http://oksoclap.com/p/eD60ucpbdg
>
> --
>
> abstractj

--

abstractj

From matzew at apache.org  Mon Jun  2 13:39:59 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Mon, 2 Jun 2014 19:39:59 +0200
Subject: [aerogear-dev] UPS Production worthiness
In-Reply-To: <003c01cf78cd$1095df40$31c19dc0$@pinelabs.com>
References: <002b01cf7424$528dc0a0$f7a941e0$@pinelabs.com>
	<E4CB92A8-4F9E-490B-BB8D-21B402FE56A9@redhat.com>
	<005d01cf74ed$3d977140$b8c653c0$@pinelabs.com>
	<CAAg5f2QZYVo0FCESLrpF3oyBmYTUS132jtGkWKWWVeUmR=UjRg@mail.gmail.com>
	<003c01cf78cd$1095df40$31c19dc0$@pinelabs.com>
Message-ID: <CAAg5f2Q59qrXWOnx0Qv-fUqqwrZxch2McLPtbQPHM+a0xT6KrA@mail.gmail.com>

Hello Vivek!

On Monday, May 26, 2014, Vivek Pandey <vivek.pandey at pinelabs.com> wrote:

> Hi Matthias,
>
>
>
> It is good to know that activity in java-apns is picking up and also that
> you are looking at pushy.
>
>
We just released 1.0.0.Beta1 of java-apns to maven central:
https://t.co/2uBjtdiGIS


It will be integrated to our server pretty soon!

-Matthias


>
>
> I did a few tests which added installations to UPS with a concurrency of
> 4-8 threads. I was using Postgres 9.3 and UPS 0.10.3 war
>
>
>
> I noticed that response slowed down considerably after some time with high
> CPU usage and continued to get worse. After doing some profiling, I found
> that bulk of CPU cycles are being taken by
> org.postgresql.core.VisibleBufferedInputStream.readMore. The entire thread
> stack is attached. Also postgres continuously flagged
>
>
>
> select installati0_.variantID as variant10_0_0_, installati0_.id as
> id1_3_0_, installati0_.id as id1_3_1_, installati0_.alias as alias2_3_1_,
> installati0_.deviceToken as deviceTo3_3_1_, installati0_.deviceType as
> deviceTy4_3_1_, installati0_.enabled as enabled5_3_1_,
> installati0_.operatingSystem as operatin6_3_1_, installati0_.osVersion as
> osVersio7_3_1_, installati0_.platform as platform8_3_1_,
> installati0_.simplePushEndpoint as simplePu9_3_1_ from InstallationImpl
> installati0_ where installati0_.variantID=$1
>
>
>
> as the slow query. I am pretty sure that eager collection
> AbstractVariant.installations is the root cause of the problem.
>
>
>
> Please let me know if you need any more information.
>
>
>
> Thanks
>
> Vivek
>
>
>
> *From:* mwessendorf at gmail.com
> <javascript:_e(%7B%7D,'cvml','mwessendorf at gmail.com');> [mailto:
> mwessendorf at gmail.com
> <javascript:_e(%7B%7D,'cvml','mwessendorf at gmail.com');>] *On Behalf Of *Matthias
> Wessendorf
> *Sent:* Wednesday, May 21, 2014 5:55 PM
> *To:* vivek.pandey at pinelabs.com
> <javascript:_e(%7B%7D,'cvml','vivek.pandey at pinelabs.com');>; AeroGear
> Developer Mailing List
> *Subject:* Re: [aerogear-dev] UPS Production worthiness
>
>
>
> Hello Vivek!
>
>
>
> On Wed, May 21, 2014 at 2:07 PM, Vivek Pandey <vivek.pandey at pinelabs.com>
> wrote:
>
> Hi Jay,
>
>
>
> Thanks for your reply.
>
>
>
> While we have not faced any issues in using UPS in our limited testing, I
> often see info stacktraces in ups logs
>
>
>
> 2014-05-16 10:19:20,032 INFO
> [com.notnoop.apns.internal.ApnsConnectionImpl] (Thread-118) Exception while
> waiting for error code: java.net.SocketException: Socket closed
>
>         at java.net.SocketInputStream.socketRead0(Native Method)
> [rt.jar:1.7.0_51]
>
>         at java.net.SocketInputStream.read(SocketInputStream.java:152)
> [rt.jar:1.7.0_51]
>
>         at java.net.SocketInputStream.read(SocketInputStream.java:122)
> [rt.jar:1.7.0_51]
>
>        ?????
>
>         at
> com.notnoop.apns.internal.ApnsConnectionImpl$1MonitoringThread.run(ApnsConnectionImpl.java:114)
> [apns-0.2.3.jar:]
>
>
>
>
>
> These stacktraces coupled with low dev activity of noop/java-apns project
> are disconcerting to me.
>
>
>
> the stack-trace is no harm - it's only happening w/ doing a monitoring of
> the thread (that's what we currently do, when setting up ApnsService - I
> thought about explicitly disable that)
>
>
>
> The activity of the underlying java-apns is very low, yes! However @froh42
> is getting back:
>
> https://github.com/notnoop/java-apns/commits/master
>
>
>
> There will be a new release in the near future; @froh42 asked me if I
> could help with pushing the bits to maven central
>
>
>
>
>
> That said, I recently started looking at pushy:
>
> https://github.com/relayrides/pushy
>
>
>
> I also sent a PR that would allow us to feed pushy w/ our certificate from
> the database:
>
> https://github.com/relayrides/pushy/pull/87
>
>
>
> ------------------------------
> This message may contain privileged and confidential information and is
> solely for the use of intended recipient. The views expressed in this email
> are those of the sender and not of Pine Labs. The recipient should check
> this email and attachments for the presence of viruses / malwares etc. Pine
> Labs accepts no liability for any damage caused by any virus transmitted by
> this email. Pine Labs may monitor and record all emails.
> ------------------------------
>
>

-- 
Sent from Gmail Mobile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140602/0667ea85/attachment-0001.html 

From bruno at abstractj.org  Mon Jun  2 16:08:59 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Mon, 2 Jun 2014 17:08:59 -0300
Subject: [aerogear-dev] Instructions to build admin-ui
In-Reply-To: <CAD_dpu0n+-9YPDW=+3GN8V9d3PzAMiY5pHQcSMaGkm6KfUjZ9Q@mail.gmail.com>
References: <20140530160333.GA20669@abstractj.org>
	<CAEroY36Yg+jrx1OwSZ6T=HYXEok8b9QEdtOz6tes8EFCC6gCxw@mail.gmail.com>
	<CAAg5f2R_ESP-=P0YYhcNCW4v+Co1aNc1g4zxTm=cgEfE+bm-ug@mail.gmail.com>
	<CAD_dpu0n+-9YPDW=+3GN8V9d3PzAMiY5pHQcSMaGkm6KfUjZ9Q@mail.gmail.com>
Message-ID: <20140602200859.GA57261@abstractj.org>

Ahoy,

I might be doing something dead wrong, these are the steps followed
here:

1. rm -rf jboss-as-7.1.1.Final && tar xzvf jboss-as-7.1.1.Final.tar.gz
&& cd jboss-current && bin/standalone.sh
2. cp databases/unifiedpush-h2-ds.xml
~/servers/jboss-current/standalone/deployments && cp
auth-server/target/auth-server.war
~/servers/jboss-current/standalone/deployments && cp
server/target/ag-push.war
~/servers/jboss-current/standalone/deployments/ag-push.war.dodeploy

3. cp -Rv server/target/ag-push/ ~/servers/jboss-current/standalone/deployments/ag-push.war/
4. At unified push server project *cd admin-ui*
5. Run grunt initLocalConfig and edit local-config.json
(https://gist.github.com/abstractj/c355676a649611aa89d7)
6. Now at
/aerogear/agpush/unifiedpush/aerogear-unifiedpush-server/admin-ui run
*grunt server*
7. localhost:9000 shows
http://photon.abstractj.org/localhost9000_20140602_170702_20140602_170705.jpg
8. localhost:8080/ag-push doesn't trigger Sign out event

If you want to try
https://github.com/abstractj/aerogear-unifiedpush-server/tree/angular-auth.
Certainly is some missing detail during deployment, but that doesn't
work here, any idea about what's wrong is welcome.

On 2014-06-02, Sebastien Blanc wrote:
> Yes,
>
> We are a bit in a transition phase with the complete overhaul of the
> console. The old readme is not enterily up to date and could be confusing.
> This JIRA has been created to track this :
> https://issues.jboss.org/browse/AGPUSH-679
>
> @abstractj: in the mean time, you can follow the instructions that Lukas
> pointed out.
>
> Sebi
>
>
>
>
>
> On Mon, Jun 2, 2014 at 9:11 AM, Matthias Wessendorf <matzew at apache.org>
> wrote:
>
> >
> >
> >
> > On Fri, May 30, 2014 at 6:44 PM, Luk?? Fry? <lukas.fryc at gmail.com> wrote:
> >
> >> Hey man,
> >>
> >> I can't find the instructions myself atm.
> >> (they could have been lost during merge (?))
> >>
> >
> > hrm, yeah - surprised to see the README is no longer around
> >
> >
> >
> >>
> >> I found this copy, which is almost up to date:
> >>
> >> https://github.com/lfryc/aerogear-unifiedpush-server/tree/master/admin-ui#using-with-jboss-eapwildfly
> >>
> >> Basically, run
> >>
> >> upload exploded ag-push.war/ to JBoss AS 7.1.
> >> $ cd admin-ui/
> >> $ grunt server
> >> modify generated local-config.json to point to that exploded war
> >> $ grunt server
> >>
> >> Hope it helps.
> >>
> >> Meanwhile, I will update the instructions in the master.
> >>
> >> Cheers,
> >>
> >> ~ Lukas
> >>
> >>
> >> On Fri, May 30, 2014 at 6:03 PM, Bruno Oliveira <bruno at abstractj.org>
> >> wrote:
> >>
> >>> Good morning,
> >>>
> >>> I'm looking for instructions of how to build admin-ui correctly. Where
> >>> could I find it?
> >>>
> >>> Currently I tried
> >>>
> >>> https://github.com/aerogear/aerogear-unifiedpush-server-admin-ui/blob/master/README.md
> >>> and also
> >>> https://github.com/aerogear/collateral/wiki/UPS-Admin-Console-Process.
> >>> The reason why I want this is because Sebastien managed to get it
> >>> working
> >>>
> >>> https://github.com/abstractj/aerogear-unifiedpush-server/tree/angular-auth
> >>> and something very dirty might be happening with my environment.
> >>>
> >>> What I want to do is very simple. Trigger the following event:
> >>>
> >>> https://github.com/abstractj/aerogear-unifiedpush-server/commit/aeed989288ae0c42a8f163b303fb1d89a029b635#diff-bd44ccad477ae267b4939a7797ddc9eeR90
> >>> .
> >>>
> >>> I also tried to copy these files to server/src/main/webapp/ but it
> >>> didnt'work.
> >>>
> >>> Thanks in advance.
> >>>
> >>> --
> >>>
> >>> abstractj
> >>> _______________________________________________
> >>> aerogear-dev mailing list
> >>> aerogear-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>>
> >>
> >>
> >> _______________________________________________
> >> aerogear-dev mailing list
> >> aerogear-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>
> >
> >
> >
> > --
> > Matthias Wessendorf
> >
> > blog: http://matthiaswessendorf.wordpress.com/
> > sessions: http://www.slideshare.net/mwessendorf
> > twitter: http://twitter.com/mwessendorf
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >

> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


--

abstractj

From scm.blanc at gmail.com  Mon Jun  2 17:05:04 2014
From: scm.blanc at gmail.com (Sebastien Blanc)
Date: Mon, 2 Jun 2014 23:05:04 +0200
Subject: [aerogear-dev] Instructions to build admin-ui
In-Reply-To: <20140602200859.GA57261@abstractj.org>
References: <20140530160333.GA20669@abstractj.org>
	<CAEroY36Yg+jrx1OwSZ6T=HYXEok8b9QEdtOz6tes8EFCC6gCxw@mail.gmail.com>
	<CAAg5f2R_ESP-=P0YYhcNCW4v+Co1aNc1g4zxTm=cgEfE+bm-ug@mail.gmail.com>
	<CAD_dpu0n+-9YPDW=+3GN8V9d3PzAMiY5pHQcSMaGkm6KfUjZ9Q@mail.gmail.com>
	<20140602200859.GA57261@abstractj.org>
Message-ID: <CAD_dpu0rf715aj39wyVmO-abz2AcC2ZNVLJxcPKOVf4_PTdPJA@mail.gmail.com>

Do you copy the ag-push.war from target as an exploded war into
/deployments ? Otherwise the grunt task won't be able to make the copy tak.



On Mon, Jun 2, 2014 at 10:08 PM, Bruno Oliveira <bruno at abstractj.org> wrote:

> Ahoy,
>
> I might be doing something dead wrong, these are the steps followed
> here:
>
> 1. rm -rf jboss-as-7.1.1.Final && tar xzvf jboss-as-7.1.1.Final.tar.gz
> && cd jboss-current && bin/standalone.sh
> 2. cp databases/unifiedpush-h2-ds.xml
> ~/servers/jboss-current/standalone/deployments && cp
> auth-server/target/auth-server.war
> ~/servers/jboss-current/standalone/deployments && cp
> server/target/ag-push.war
> ~/servers/jboss-current/standalone/deployments/ag-push.war.dodeploy
>
> 3. cp -Rv server/target/ag-push/
> ~/servers/jboss-current/standalone/deployments/ag-push.war/
> 4. At unified push server project *cd admin-ui*
> 5. Run grunt initLocalConfig and edit local-config.json
> (https://gist.github.com/abstractj/c355676a649611aa89d7)
> 6. Now at
> /aerogear/agpush/unifiedpush/aerogear-unifiedpush-server/admin-ui run
> *grunt server*
> 7. localhost:9000 shows
>
> http://photon.abstractj.org/localhost9000_20140602_170702_20140602_170705.jpg
> 8. localhost:8080/ag-push doesn't trigger Sign out event
>
> If you want to try
> https://github.com/abstractj/aerogear-unifiedpush-server/tree/angular-auth
> .
> Certainly is some missing detail during deployment, but that doesn't
> work here, any idea about what's wrong is welcome.
>
> On 2014-06-02, Sebastien Blanc wrote:
> > Yes,
> >
> > We are a bit in a transition phase with the complete overhaul of the
> > console. The old readme is not enterily up to date and could be
> confusing.
> > This JIRA has been created to track this :
> > https://issues.jboss.org/browse/AGPUSH-679
> >
> > @abstractj: in the mean time, you can follow the instructions that Lukas
> > pointed out.
> >
> > Sebi
> >
> >
> >
> >
> >
> > On Mon, Jun 2, 2014 at 9:11 AM, Matthias Wessendorf <matzew at apache.org>
> > wrote:
> >
> > >
> > >
> > >
> > > On Fri, May 30, 2014 at 6:44 PM, Luk?? Fry? <lukas.fryc at gmail.com>
> wrote:
> > >
> > >> Hey man,
> > >>
> > >> I can't find the instructions myself atm.
> > >> (they could have been lost during merge (?))
> > >>
> > >
> > > hrm, yeah - surprised to see the README is no longer around
> > >
> > >
> > >
> > >>
> > >> I found this copy, which is almost up to date:
> > >>
> > >>
> https://github.com/lfryc/aerogear-unifiedpush-server/tree/master/admin-ui#using-with-jboss-eapwildfly
> > >>
> > >> Basically, run
> > >>
> > >> upload exploded ag-push.war/ to JBoss AS 7.1.
> > >> $ cd admin-ui/
> > >> $ grunt server
> > >> modify generated local-config.json to point to that exploded war
> > >> $ grunt server
> > >>
> > >> Hope it helps.
> > >>
> > >> Meanwhile, I will update the instructions in the master.
> > >>
> > >> Cheers,
> > >>
> > >> ~ Lukas
> > >>
> > >>
> > >> On Fri, May 30, 2014 at 6:03 PM, Bruno Oliveira <bruno at abstractj.org>
> > >> wrote:
> > >>
> > >>> Good morning,
> > >>>
> > >>> I'm looking for instructions of how to build admin-ui correctly.
> Where
> > >>> could I find it?
> > >>>
> > >>> Currently I tried
> > >>>
> > >>>
> https://github.com/aerogear/aerogear-unifiedpush-server-admin-ui/blob/master/README.md
> > >>> and also
> > >>>
> https://github.com/aerogear/collateral/wiki/UPS-Admin-Console-Process.
> > >>> The reason why I want this is because Sebastien managed to get it
> > >>> working
> > >>>
> > >>>
> https://github.com/abstractj/aerogear-unifiedpush-server/tree/angular-auth
> > >>> and something very dirty might be happening with my environment.
> > >>>
> > >>> What I want to do is very simple. Trigger the following event:
> > >>>
> > >>>
> https://github.com/abstractj/aerogear-unifiedpush-server/commit/aeed989288ae0c42a8f163b303fb1d89a029b635#diff-bd44ccad477ae267b4939a7797ddc9eeR90
> > >>> .
> > >>>
> > >>> I also tried to copy these files to server/src/main/webapp/ but it
> > >>> didnt'work.
> > >>>
> > >>> Thanks in advance.
> > >>>
> > >>> --
> > >>>
> > >>> abstractj
> > >>> _______________________________________________
> > >>> aerogear-dev mailing list
> > >>> aerogear-dev at lists.jboss.org
> > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > >>>
> > >>
> > >>
> > >> _______________________________________________
> > >> aerogear-dev mailing list
> > >> aerogear-dev at lists.jboss.org
> > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > >>
> > >
> > >
> > >
> > > --
> > > Matthias Wessendorf
> > >
> > > blog: http://matthiaswessendorf.wordpress.com/
> > > sessions: http://www.slideshare.net/mwessendorf
> > > twitter: http://twitter.com/mwessendorf
> > >
> > > _______________________________________________
> > > aerogear-dev mailing list
> > > aerogear-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > >
>
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> --
>
> abstractj
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140602/f81d342b/attachment.html 

From vivek.pandey at pinelabs.com  Mon Jun  2 23:55:44 2014
From: vivek.pandey at pinelabs.com (Vivek Pandey)
Date: Tue, 3 Jun 2014 09:25:44 +0530
Subject: [aerogear-dev] UPS Production worthiness
In-Reply-To: <CAAg5f2Q59qrXWOnx0Qv-fUqqwrZxch2McLPtbQPHM+a0xT6KrA@mail.gmail.com>
References: <002b01cf7424$528dc0a0$f7a941e0$@pinelabs.com>	<E4CB92A8-4F9E-490B-BB8D-21B402FE56A9@redhat.com>	<005d01cf74ed$3d977140$b8c653c0$@pinelabs.com>	<CAAg5f2QZYVo0FCESLrpF3oyBmYTUS132jtGkWKWWVeUmR=UjRg@mail.gmail.com>	<003c01cf78cd$1095df40$31c19dc0$@pinelabs.com>
	<CAAg5f2Q59qrXWOnx0Qv-fUqqwrZxch2McLPtbQPHM+a0xT6KrA@mail.gmail.com>
Message-ID: <001e01cf7edf$b41add60$1c509820$@pinelabs.com>

Thanks Matthias, the response and agility of Aerogear team has been phenomenal so far.

 

From: mwessendorf at gmail.com [mailto:mwessendorf at gmail.com] On Behalf Of Matthias Wessendorf
Sent: Monday, June 02, 2014 11:10 PM
To: vivek.pandey at pinelabs.com
Cc: AeroGear Developer Mailing List
Subject: Re: [aerogear-dev] UPS Production worthiness

 

Hello Vivek!

On Monday, May 26, 2014, Vivek Pandey <vivek.pandey at pinelabs.com> wrote:

Hi Matthias,

 

It is good to know that activity in java-apns is picking up and also that you are looking at pushy.

 

We just released 1.0.0.Beta1 of java-apns to maven central: https://t.co/2uBjtdiGIS

 

 

It will be integrated to our server pretty soon!

 

-Matthias

 

 

I did a few tests which added installations to UPS with a concurrency of 4-8 threads. I was using Postgres 9.3 and UPS 0.10.3 war

 

I noticed that response slowed down considerably after some time with high CPU usage and continued to get worse. After doing some profiling, I found that bulk of CPU cycles are being taken by org.postgresql.core.VisibleBufferedInputStream.readMore. The entire thread stack is attached. Also postgres continuously flagged 

 

select installati0_.variantID as variant10_0_0_, installati0_.id as id1_3_0_, installati0_.id as id1_3_1_, installati0_.alias as alias2_3_1_, installati0_.deviceToken as deviceTo3_3_1_, installati0_.deviceType as deviceTy4_3_1_, installati0_.enabled as enabled5_3_1_, installati0_.operatingSystem as operatin6_3_1_, installati0_.osVersion as osVersio7_3_1_, installati0_.platform as platform8_3_1_, installati0_.simplePushEndpoint as simplePu9_3_1_ from InstallationImpl installati0_ where installati0_.variantID=$1

 

as the slow query. I am pretty sure that eager collection AbstractVariant.installations is the root cause of the problem. 

 

Please let me know if you need any more information.

 

Thanks

Vivek

 

From: mwessendorf at gmail.com <javascript:_e(%7B%7D,'cvml','mwessendorf at gmail.com');>  [mailto:mwessendorf at gmail.com <javascript:_e(%7B%7D,'cvml','mwessendorf at gmail.com');> ] On Behalf Of Matthias Wessendorf
Sent: Wednesday, May 21, 2014 5:55 PM
To: vivek.pandey at pinelabs.com <javascript:_e(%7B%7D,'cvml','vivek.pandey at pinelabs.com');> ; AeroGear Developer Mailing List
Subject: Re: [aerogear-dev] UPS Production worthiness

 

Hello Vivek!

 

On Wed, May 21, 2014 at 2:07 PM, Vivek Pandey <vivek.pandey at pinelabs.com> wrote:

Hi Jay,

 

Thanks for your reply.

 

While we have not faced any issues in using UPS in our limited testing, I often see info stacktraces in ups logs

 

2014-05-16 10:19:20,032 INFO  [com.notnoop.apns.internal.ApnsConnectionImpl] (Thread-118) Exception while waiting for error code: java.net.SocketException: Socket closed

        at java.net.SocketInputStream.socketRead0(Native Method) [rt.jar:1.7.0_51]

        at java.net.SocketInputStream.read(SocketInputStream.java:152) [rt.jar:1.7.0_51]

        at java.net.SocketInputStream.read(SocketInputStream.java:122) [rt.jar:1.7.0_51]

       ?????

        at com.notnoop.apns.internal.ApnsConnectionImpl$1MonitoringThread.run(ApnsConnectionImpl.java:114) [apns-0.2.3.jar:]

 

 

These stacktraces coupled with low dev activity of noop/java-apns project are disconcerting to me.

 

the stack-trace is no harm - it's only happening w/ doing a monitoring of the thread (that's what we currently do, when setting up ApnsService - I thought about explicitly disable that)

 

The activity of the underlying java-apns is very low, yes! However @froh42 is getting back:

https://github.com/notnoop/java-apns/commits/master

 

There will be a new release in the near future; @froh42 asked me if I could help with pushing the bits to maven central

 

 

That said, I recently started looking at pushy:

https://github.com/relayrides/pushy

 

I also sent a PR that would allow us to feed pushy w/ our certificate from the database:

https://github.com/relayrides/pushy/pull/87

 

 

  _____  

This message may contain privileged and confidential information and is solely for the use of intended recipient. The views expressed in this email are those of the sender and not of Pine Labs. The recipient should check this email and attachments for the presence of viruses / malwares etc. Pine Labs accepts no liability for any damage caused by any virus transmitted by this email. Pine Labs may monitor and record all emails.

  _____  

 



-- 
Sent from Gmail Mobile


This message may contain privileged and confidential information and is solely for the use of intended recipient. The views expressed in this email are those of the sender and not of Pine Labs. The recipient should check this email and attachments for the presence of viruses / malwares etc. Pine Labs accepts no liability for any damage caused by any virus transmitted by this email. Pine Labs may monitor and record all emails.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140603/0f0814af/attachment-0001.html 

From daniel.bevenius at gmail.com  Tue Jun  3 02:25:40 2014
From: daniel.bevenius at gmail.com (danielbevenius)
Date: Mon, 2 Jun 2014 23:25:40 -0700 (PDT)
Subject: [aerogear-dev] contacts-mobile-basic quick start
In-Reply-To: <682680FC-677F-4566-8E2C-9392CEC4FC83@gmail.com>
References: <33FAC87C-F08E-4C86-842F-7A3F7D107D45@redhat.com>
	<A7CCCFDE-F89A-4E8F-9C06-BD7BC1577259@gmail.com>
	<CAFJm-3FOidFs5D7ogThjO7mORtb5q55r8BRCcn9jNbjoiHFy6w@mail.gmail.com>
	<CAAg5f2Q536Zi1A=OvhFEmdcN_8jzd3uALJ4sbfUom89d3p5Pzw@mail.gmail.com>
	<CAFJm-3ES4VQL8=rBT22jKuo+6T-18AB4Oh=XP4p172o4fSLR1g@mail.gmail.com>
	<CAFJm-3H9-t1E--T+_ctZ7+YVpw2XVwByoHFm-hFSBZWTxMiQag@mail.gmail.com>
	<CAFJm-3Fxd8LR8eqhGTBzutpc_Tu+LsQ5VW+ANzrKaq0QnbBmZw@mail.gmail.com>
	<682680FC-677F-4566-8E2C-9392CEC4FC83@gmail.com>
Message-ID: <1401776740005-8059.post@n5.nabble.com>

I'm struggling with extracting the webapp from
contacts-mobile-picketlink-secured. I've put the details of the problem I'm
having in this gist:
https://gist.github.com/danbev/ef3a2a08b5d8e41d6879

If you don't have time to read the above gist the issue is basically that I
don't understand why two logins are required for a user to be considered
logged in by PicketLink. If anyone has input or can spot something I'm doing
wrong please let me know. 

With two logins I'm able to get the webapp working in Chrome, FireFox,
Safari, and Opera.

/Dan



--
View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-contacts-mobile-basic-quick-start-tp7534p8059.html
Sent from the aerogear-dev mailing list archive at Nabble.com.

From matzew at apache.org  Tue Jun  3 02:49:13 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Tue, 3 Jun 2014 08:49:13 +0200
Subject: [aerogear-dev] Java-Sender release?
Message-ID: <CAAg5f2SEcf0pv-MxGm5X3nJ1ztpKoM2HGXnpCRRywG5U5Acuog@mail.gmail.com>

Hi,

based on recent changes, I think it's good time to release the client
version 0.7.0.

Any concerns against such a release ?

-- 
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-dev/attachments/20140603/6ff6bce9/attachment.html 

From daniel.bevenius at gmail.com  Tue Jun  3 02:50:20 2014
From: daniel.bevenius at gmail.com (Daniel Bevenius)
Date: Tue, 3 Jun 2014 08:50:20 +0200
Subject: [aerogear-dev] Java-Sender release?
In-Reply-To: <CAAg5f2SEcf0pv-MxGm5X3nJ1ztpKoM2HGXnpCRRywG5U5Acuog@mail.gmail.com>
References: <CAAg5f2SEcf0pv-MxGm5X3nJ1ztpKoM2HGXnpCRRywG5U5Acuog@mail.gmail.com>
Message-ID: <CAFJm-3F0NsLrutoJDWVRt2DL5LW0DqZdgiaGuQAq5=-PZ0ruZA@mail.gmail.com>

Sounds good!


On 3 June 2014 08:49, Matthias Wessendorf <matzew at apache.org> wrote:

> Hi,
>
> based on recent changes, I think it's good time to release the client
> version 0.7.0.
>
> Any concerns against such a release ?
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140603/b00a54e7/attachment.html 

From scm.blanc at gmail.com  Tue Jun  3 02:50:44 2014
From: scm.blanc at gmail.com (Sebastien Blanc)
Date: Tue, 3 Jun 2014 08:50:44 +0200
Subject: [aerogear-dev] Java-Sender release?
In-Reply-To: <CAAg5f2SEcf0pv-MxGm5X3nJ1ztpKoM2HGXnpCRRywG5U5Acuog@mail.gmail.com>
References: <CAAg5f2SEcf0pv-MxGm5X3nJ1ztpKoM2HGXnpCRRywG5U5Acuog@mail.gmail.com>
Message-ID: <CAD_dpu24iCiSZPt0HeuoC5EC10XiC0nxLvZAe6A6p6DgePno5Q@mail.gmail.com>

I was thinking the same, I would like to include
https://github.com/aerogear/aerogear-unifiedpush-java-client/pull/39 and
https://github.com/aerogear/aerogear-unifiedpush-java-client/pull/40


On Tue, Jun 3, 2014 at 8:49 AM, Matthias Wessendorf <matzew at apache.org>
wrote:

> Hi,
>
> based on recent changes, I think it's good time to release the client
> version 0.7.0.
>
> Any concerns against such a release ?
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140603/4563ec01/attachment.html 

From matzew at apache.org  Tue Jun  3 02:51:36 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Tue, 3 Jun 2014 08:51:36 +0200
Subject: [aerogear-dev] Instructions to build admin-ui
In-Reply-To: <20140602200859.GA57261@abstractj.org>
References: <20140530160333.GA20669@abstractj.org>
	<CAEroY36Yg+jrx1OwSZ6T=HYXEok8b9QEdtOz6tes8EFCC6gCxw@mail.gmail.com>
	<CAAg5f2R_ESP-=P0YYhcNCW4v+Co1aNc1g4zxTm=cgEfE+bm-ug@mail.gmail.com>
	<CAD_dpu0n+-9YPDW=+3GN8V9d3PzAMiY5pHQcSMaGkm6KfUjZ9Q@mail.gmail.com>
	<20140602200859.GA57261@abstractj.org>
Message-ID: <CAAg5f2S-D4F1CxjNw8F7nhg8R3SczoWuBfwuBmdkYW5QC2eVVQ@mail.gmail.com>

On Mon, Jun 2, 2014 at 10:08 PM, Bruno Oliveira <bruno at abstractj.org> wrote:

> Ahoy,
>
> I might be doing something dead wrong, these are the steps followed
> here:
>
> 1. rm -rf jboss-as-7.1.1.Final && tar xzvf jboss-as-7.1.1.Final.tar.gz
> && cd jboss-current && bin/standalone.sh
> 2. cp databases/unifiedpush-h2-ds.xml
> ~/servers/jboss-current/standalone/deployments && cp
> auth-server/target/auth-server.war
> ~/servers/jboss-current/standalone/deployments && cp
> server/target/ag-push.war
> ~/servers/jboss-current/standalone/deployments/ag-push.war.dodeploy
>
> 3. cp -Rv server/target/ag-push/
> ~/servers/jboss-current/standalone/deployments/ag-push.war/
> 4. At unified push server project *cd admin-ui*
> 5. Run grunt initLocalConfig and edit local-config.json
> (https://gist.github.com/abstractj/c355676a649611aa89d7)
> 6. Now at
> /aerogear/agpush/unifiedpush/aerogear-unifiedpush-server/admin-ui run
> *grunt server*
> 7. localhost:9000 shows
>
> http://photon.abstractj.org/localhost9000_20140602_170702_20140602_170705.jpg
> 8. localhost:8080/ag-push doesn't trigger Sign out event
>

might be unrelated, but perhaps not. After their Beta1 release Bill fixed a
bug on the AS7 adapter:
https://github.com/keycloak/keycloak/pull/446


-Matthias


>
> If you want to try
> https://github.com/abstractj/aerogear-unifiedpush-server/tree/angular-auth
> .
> Certainly is some missing detail during deployment, but that doesn't
> work here, any idea about what's wrong is welcome.
>
> On 2014-06-02, Sebastien Blanc wrote:
> > Yes,
> >
> > We are a bit in a transition phase with the complete overhaul of the
> > console. The old readme is not enterily up to date and could be
> confusing.
> > This JIRA has been created to track this :
> > https://issues.jboss.org/browse/AGPUSH-679
> >
> > @abstractj: in the mean time, you can follow the instructions that Lukas
> > pointed out.
> >
> > Sebi
> >
> >
> >
> >
> >
> > On Mon, Jun 2, 2014 at 9:11 AM, Matthias Wessendorf <matzew at apache.org>
> > wrote:
> >
> > >
> > >
> > >
> > > On Fri, May 30, 2014 at 6:44 PM, Luk?? Fry? <lukas.fryc at gmail.com>
> wrote:
> > >
> > >> Hey man,
> > >>
> > >> I can't find the instructions myself atm.
> > >> (they could have been lost during merge (?))
> > >>
> > >
> > > hrm, yeah - surprised to see the README is no longer around
> > >
> > >
> > >
> > >>
> > >> I found this copy, which is almost up to date:
> > >>
> > >>
> https://github.com/lfryc/aerogear-unifiedpush-server/tree/master/admin-ui#using-with-jboss-eapwildfly
> > >>
> > >> Basically, run
> > >>
> > >> upload exploded ag-push.war/ to JBoss AS 7.1.
> > >> $ cd admin-ui/
> > >> $ grunt server
> > >> modify generated local-config.json to point to that exploded war
> > >> $ grunt server
> > >>
> > >> Hope it helps.
> > >>
> > >> Meanwhile, I will update the instructions in the master.
> > >>
> > >> Cheers,
> > >>
> > >> ~ Lukas
> > >>
> > >>
> > >> On Fri, May 30, 2014 at 6:03 PM, Bruno Oliveira <bruno at abstractj.org>
> > >> wrote:
> > >>
> > >>> Good morning,
> > >>>
> > >>> I'm looking for instructions of how to build admin-ui correctly.
> Where
> > >>> could I find it?
> > >>>
> > >>> Currently I tried
> > >>>
> > >>>
> https://github.com/aerogear/aerogear-unifiedpush-server-admin-ui/blob/master/README.md
> > >>> and also
> > >>>
> https://github.com/aerogear/collateral/wiki/UPS-Admin-Console-Process.
> > >>> The reason why I want this is because Sebastien managed to get it
> > >>> working
> > >>>
> > >>>
> https://github.com/abstractj/aerogear-unifiedpush-server/tree/angular-auth
> > >>> and something very dirty might be happening with my environment.
> > >>>
> > >>> What I want to do is very simple. Trigger the following event:
> > >>>
> > >>>
> https://github.com/abstractj/aerogear-unifiedpush-server/commit/aeed989288ae0c42a8f163b303fb1d89a029b635#diff-bd44ccad477ae267b4939a7797ddc9eeR90
> > >>> .
> > >>>
> > >>> I also tried to copy these files to server/src/main/webapp/ but it
> > >>> didnt'work.
> > >>>
> > >>> Thanks in advance.
> > >>>
> > >>> --
> > >>>
> > >>> abstractj
> > >>> _______________________________________________
> > >>> aerogear-dev mailing list
> > >>> aerogear-dev at lists.jboss.org
> > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > >>>
> > >>
> > >>
> > >> _______________________________________________
> > >> aerogear-dev mailing list
> > >> aerogear-dev at lists.jboss.org
> > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > >>
> > >
> > >
> > >
> > > --
> > > Matthias Wessendorf
> > >
> > > blog: http://matthiaswessendorf.wordpress.com/
> > > sessions: http://www.slideshare.net/mwessendorf
> > > twitter: http://twitter.com/mwessendorf
> > >
> > > _______________________________________________
> > > aerogear-dev mailing list
> > > aerogear-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > >
>
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> --
>
> abstractj
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140603/dcac3e2d/attachment-0001.html 

From matzew at apache.org  Tue Jun  3 02:57:05 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Tue, 3 Jun 2014 08:57:05 +0200
Subject: [aerogear-dev] Java-Sender release?
In-Reply-To: <CAD_dpu24iCiSZPt0HeuoC5EC10XiC0nxLvZAe6A6p6DgePno5Q@mail.gmail.com>
References: <CAAg5f2SEcf0pv-MxGm5X3nJ1ztpKoM2HGXnpCRRywG5U5Acuog@mail.gmail.com>
	<CAD_dpu24iCiSZPt0HeuoC5EC10XiC0nxLvZAe6A6p6DgePno5Q@mail.gmail.com>
Message-ID: <CAAg5f2QxXUXaPPo9bdX+2HpzvzH5kgFXu2EkSbavMbFQ7YAjNw@mail.gmail.com>

that's already in :-)


On Tue, Jun 3, 2014 at 8:50 AM, Sebastien Blanc <scm.blanc at gmail.com> wrote:

> I was thinking the same, I would like to include
> https://github.com/aerogear/aerogear-unifiedpush-java-client/pull/39 and
> https://github.com/aerogear/aerogear-unifiedpush-java-client/pull/40
>
>
> On Tue, Jun 3, 2014 at 8:49 AM, Matthias Wessendorf <matzew at apache.org>
> wrote:
>
>> Hi,
>>
>> based on recent changes, I think it's good time to release the client
>> version 0.7.0.
>>
>> Any concerns against such a release ?
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> sessions: http://www.slideshare.net/mwessendorf
>> twitter: http://twitter.com/mwessendorf
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140603/c6cd1b29/attachment.html 

From matzew at apache.org  Tue Jun  3 03:15:00 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Tue, 3 Jun 2014 09:15:00 +0200
Subject: [aerogear-dev] Java Sender 0.7.0 has been staged (was: Re:
 Java-Sender release?)
Message-ID: <CAAg5f2TUssYY=tD-xnjZQmN1eJP3-nBL+MCGXXbSqupqgRvF3A@mail.gmail.com>

Hello,

the version 0.7.0 of the Java Sender has been staged. The staging
repository is located here:
http://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3338/

Changes since the last release:
* BOM and AeroGear-Parent update
* Java client: submit request header on sending (AGPUSH-682)
* Switching to com.fasterxml.jackson
* Refactoring of SenderClient and JavaSender

If nothing bad has been reported, I will release the bits by Thursday
afternoon (EU time)

Cheers!
Matthias


On Tue, Jun 3, 2014 at 8:57 AM, Matthias Wessendorf <matzew at apache.org>
wrote:

> that's already in :-)
>
>
> On Tue, Jun 3, 2014 at 8:50 AM, Sebastien Blanc <scm.blanc at gmail.com>
> wrote:
>
>> I was thinking the same, I would like to include
>> https://github.com/aerogear/aerogear-unifiedpush-java-client/pull/39 and
>> https://github.com/aerogear/aerogear-unifiedpush-java-client/pull/40
>>
>>
>> On Tue, Jun 3, 2014 at 8:49 AM, Matthias Wessendorf <matzew at apache.org>
>> wrote:
>>
>>> Hi,
>>>
>>> based on recent changes, I think it's good time to release the client
>>> version 0.7.0.
>>>
>>> Any concerns against such a release ?
>>>
>>> --
>>> Matthias Wessendorf
>>>
>>> blog: http://matthiaswessendorf.wordpress.com/
>>> sessions: http://www.slideshare.net/mwessendorf
>>> twitter: http://twitter.com/mwessendorf
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>



-- 
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-dev/attachments/20140603/4a5e3694/attachment.html 

From matzew at apache.org  Tue Jun  3 04:36:50 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Tue, 3 Jun 2014 10:36:50 +0200
Subject: [aerogear-dev] UnifiedPush 0.10.4 - release coming soon (Maven
	Central and OpenShift)
Message-ID: <CAAg5f2T5rc+_TV4pcpFXh2M+SLsywL22SB1XpJGjHMbaHF22CA@mail.gmail.com>

Hello,

as disscussed in our IRC meeting yesterday, I ran the release for the
0.10.4 version of UPS.

The staging repository is located here:
http://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3340/

I sent a PR for our OpenShift offerings:
https://github.com/aerogear/openshift-origin-cartridge-aerogear-push/pull/15


If you want to test it - it's simple! Just go ahead and use my fork of the
repo:
rhc app create --no-git <YOUR COOL APP NAME>
https://cartreflect-claytondev.rhcloud.com/reflect?github=matzew/openshift-origin-cartridge-aerogear-push
 mysql-5.5

The change log of the server:

* AGPUSH-642
* AGPUSH-643
* AGPUSH-687

Let me know the results of your testing;
If I hear nothing bad by Wednesday evening, the merges (and release to
maven central) will happen on Thursday;


Cheers,
Matthias


-- 
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-dev/attachments/20140603/a57bb87b/attachment.html 

From bruno at abstractj.org  Tue Jun  3 06:30:01 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Tue, 3 Jun 2014 07:30:01 -0300
Subject: [aerogear-dev] Instructions to build admin-ui
In-Reply-To: <CAD_dpu0rf715aj39wyVmO-abz2AcC2ZNVLJxcPKOVf4_PTdPJA@mail.gmail.com>
References: <20140530160333.GA20669@abstractj.org>
	<CAEroY36Yg+jrx1OwSZ6T=HYXEok8b9QEdtOz6tes8EFCC6gCxw@mail.gmail.com>
	<CAAg5f2R_ESP-=P0YYhcNCW4v+Co1aNc1g4zxTm=cgEfE+bm-ug@mail.gmail.com>
	<CAD_dpu0n+-9YPDW=+3GN8V9d3PzAMiY5pHQcSMaGkm6KfUjZ9Q@mail.gmail.com>
	<20140602200859.GA57261@abstractj.org>
	<CAD_dpu0rf715aj39wyVmO-abz2AcC2ZNVLJxcPKOVf4_PTdPJA@mail.gmail.com>
Message-ID: <20140603103001.GB88786@abstractj.org>

On 2014-06-02, Sebastien Blanc wrote:
> Do you copy the ag-push.war from target as an exploded war into
> /deployments ? Otherwise the grunt task won't be able to make the copy tak.

I guess so, please see step 3. That's what am I supposed to do, right?

>
>
>
> On Mon, Jun 2, 2014 at 10:08 PM, Bruno Oliveira <bruno at abstractj.org> wrote:
>
> > Ahoy,
> >
> > I might be doing something dead wrong, these are the steps followed
> > here:
> >
> > 1. rm -rf jboss-as-7.1.1.Final && tar xzvf jboss-as-7.1.1.Final.tar.gz
> > && cd jboss-current && bin/standalone.sh
> > 2. cp databases/unifiedpush-h2-ds.xml
> > ~/servers/jboss-current/standalone/deployments && cp
> > auth-server/target/auth-server.war
> > ~/servers/jboss-current/standalone/deployments && cp
> > server/target/ag-push.war
> > ~/servers/jboss-current/standalone/deployments/ag-push.war.dodeploy
> >
> > 3. cp -Rv server/target/ag-push/
> > ~/servers/jboss-current/standalone/deployments/ag-push.war/
> > 4. At unified push server project *cd admin-ui*
> > 5. Run grunt initLocalConfig and edit local-config.json
> > (https://gist.github.com/abstractj/c355676a649611aa89d7)
> > 6. Now at
> > /aerogear/agpush/unifiedpush/aerogear-unifiedpush-server/admin-ui run
> > *grunt server*
> > 7. localhost:9000 shows
> >
> > http://photon.abstractj.org/localhost9000_20140602_170702_20140602_170705.jpg
> > 8. localhost:8080/ag-push doesn't trigger Sign out event
> >
> > If you want to try
> > https://github.com/abstractj/aerogear-unifiedpush-server/tree/angular-auth
> > .
> > Certainly is some missing detail during deployment, but that doesn't
> > work here, any idea about what's wrong is welcome.
> >
> > On 2014-06-02, Sebastien Blanc wrote:
> > > Yes,
> > >
> > > We are a bit in a transition phase with the complete overhaul of the
> > > console. The old readme is not enterily up to date and could be
> > confusing.
> > > This JIRA has been created to track this :
> > > https://issues.jboss.org/browse/AGPUSH-679
> > >
> > > @abstractj: in the mean time, you can follow the instructions that Lukas
> > > pointed out.
> > >
> > > Sebi
> > >
> > >
> > >
> > >
> > >
> > > On Mon, Jun 2, 2014 at 9:11 AM, Matthias Wessendorf <matzew at apache.org>
> > > wrote:
> > >
> > > >
> > > >
> > > >
> > > > On Fri, May 30, 2014 at 6:44 PM, Luk?? Fry? <lukas.fryc at gmail.com>
> > wrote:
> > > >
> > > >> Hey man,
> > > >>
> > > >> I can't find the instructions myself atm.
> > > >> (they could have been lost during merge (?))
> > > >>
> > > >
> > > > hrm, yeah - surprised to see the README is no longer around
> > > >
> > > >
> > > >
> > > >>
> > > >> I found this copy, which is almost up to date:
> > > >>
> > > >>
> > https://github.com/lfryc/aerogear-unifiedpush-server/tree/master/admin-ui#using-with-jboss-eapwildfly
> > > >>
> > > >> Basically, run
> > > >>
> > > >> upload exploded ag-push.war/ to JBoss AS 7.1.
> > > >> $ cd admin-ui/
> > > >> $ grunt server
> > > >> modify generated local-config.json to point to that exploded war
> > > >> $ grunt server
> > > >>
> > > >> Hope it helps.
> > > >>
> > > >> Meanwhile, I will update the instructions in the master.
> > > >>
> > > >> Cheers,
> > > >>
> > > >> ~ Lukas
> > > >>
> > > >>
> > > >> On Fri, May 30, 2014 at 6:03 PM, Bruno Oliveira <bruno at abstractj.org>
> > > >> wrote:
> > > >>
> > > >>> Good morning,
> > > >>>
> > > >>> I'm looking for instructions of how to build admin-ui correctly.
> > Where
> > > >>> could I find it?
> > > >>>
> > > >>> Currently I tried
> > > >>>
> > > >>>
> > https://github.com/aerogear/aerogear-unifiedpush-server-admin-ui/blob/master/README.md
> > > >>> and also
> > > >>>
> > https://github.com/aerogear/collateral/wiki/UPS-Admin-Console-Process.
> > > >>> The reason why I want this is because Sebastien managed to get it
> > > >>> working
> > > >>>
> > > >>>
> > https://github.com/abstractj/aerogear-unifiedpush-server/tree/angular-auth
> > > >>> and something very dirty might be happening with my environment.
> > > >>>
> > > >>> What I want to do is very simple. Trigger the following event:
> > > >>>
> > > >>>
> > https://github.com/abstractj/aerogear-unifiedpush-server/commit/aeed989288ae0c42a8f163b303fb1d89a029b635#diff-bd44ccad477ae267b4939a7797ddc9eeR90
> > > >>> .
> > > >>>
> > > >>> I also tried to copy these files to server/src/main/webapp/ but it
> > > >>> didnt'work.
> > > >>>
> > > >>> Thanks in advance.
> > > >>>
> > > >>> --
> > > >>>
> > > >>> abstractj
> > > >>> _______________________________________________
> > > >>> aerogear-dev mailing list
> > > >>> aerogear-dev at lists.jboss.org
> > > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > >>>
> > > >>
> > > >>
> > > >> _______________________________________________
> > > >> aerogear-dev mailing list
> > > >> aerogear-dev at lists.jboss.org
> > > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > >>
> > > >
> > > >
> > > >
> > > > --
> > > > Matthias Wessendorf
> > > >
> > > > blog: http://matthiaswessendorf.wordpress.com/
> > > > sessions: http://www.slideshare.net/mwessendorf
> > > > twitter: http://twitter.com/mwessendorf
> > > >
> > > > _______________________________________________
> > > > aerogear-dev mailing list
> > > > aerogear-dev at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > >
> >
> > > _______________________________________________
> > > aerogear-dev mailing list
> > > aerogear-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> >
> > --
> >
> > abstractj
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >

> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


--

abstractj

From bruno at abstractj.org  Tue Jun  3 06:31:10 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Tue, 3 Jun 2014 07:31:10 -0300
Subject: [aerogear-dev] Instructions to build admin-ui
In-Reply-To: <CAAg5f2S-D4F1CxjNw8F7nhg8R3SczoWuBfwuBmdkYW5QC2eVVQ@mail.gmail.com>
References: <20140530160333.GA20669@abstractj.org>
	<CAEroY36Yg+jrx1OwSZ6T=HYXEok8b9QEdtOz6tes8EFCC6gCxw@mail.gmail.com>
	<CAAg5f2R_ESP-=P0YYhcNCW4v+Co1aNc1g4zxTm=cgEfE+bm-ug@mail.gmail.com>
	<CAD_dpu0n+-9YPDW=+3GN8V9d3PzAMiY5pHQcSMaGkm6KfUjZ9Q@mail.gmail.com>
	<20140602200859.GA57261@abstractj.org>
	<CAAg5f2S-D4F1CxjNw8F7nhg8R3SczoWuBfwuBmdkYW5QC2eVVQ@mail.gmail.com>
Message-ID: <20140603103110.GC88786@abstractj.org>

On 2014-06-03, Matthias Wessendorf wrote:
> On Mon, Jun 2, 2014 at 10:08 PM, Bruno Oliveira <bruno at abstractj.org> wrote:
>
> > Ahoy,
> >
> > I might be doing something dead wrong, these are the steps followed
> > here:
> >
> > 1. rm -rf jboss-as-7.1.1.Final && tar xzvf jboss-as-7.1.1.Final.tar.gz
> > && cd jboss-current && bin/standalone.sh
> > 2. cp databases/unifiedpush-h2-ds.xml
> > ~/servers/jboss-current/standalone/deployments && cp
> > auth-server/target/auth-server.war
> > ~/servers/jboss-current/standalone/deployments && cp
> > server/target/ag-push.war
> > ~/servers/jboss-current/standalone/deployments/ag-push.war.dodeploy
> >
> > 3. cp -Rv server/target/ag-push/
> > ~/servers/jboss-current/standalone/deployments/ag-push.war/
> > 4. At unified push server project *cd admin-ui*
> > 5. Run grunt initLocalConfig and edit local-config.json
> > (https://gist.github.com/abstractj/c355676a649611aa89d7)
> > 6. Now at
> > /aerogear/agpush/unifiedpush/aerogear-unifiedpush-server/admin-ui run
> > *grunt server*
> > 7. localhost:9000 shows
> >
> > http://photon.abstractj.org/localhost9000_20140602_170702_20140602_170705.jpg
> > 8. localhost:8080/ag-push doesn't trigger Sign out event
> >
>
> might be unrelated, but perhaps not. After their Beta1 release Bill fixed a
> bug on the AS7 adapter:
> https://github.com/keycloak/keycloak/pull/446

I think it's unrelated because I don't even make use of Keycloak.js.
It's just plain Angular.js for testing purposes.

>
>
> -Matthias
>
>
> >
> > If you want to try
> > https://github.com/abstractj/aerogear-unifiedpush-server/tree/angular-auth
> > .
> > Certainly is some missing detail during deployment, but that doesn't
> > work here, any idea about what's wrong is welcome.
> >
> > On 2014-06-02, Sebastien Blanc wrote:
> > > Yes,
> > >
> > > We are a bit in a transition phase with the complete overhaul of the
> > > console. The old readme is not enterily up to date and could be
> > confusing.
> > > This JIRA has been created to track this :
> > > https://issues.jboss.org/browse/AGPUSH-679
> > >
> > > @abstractj: in the mean time, you can follow the instructions that Lukas
> > > pointed out.
> > >
> > > Sebi
> > >
> > >
> > >
> > >
> > >
> > > On Mon, Jun 2, 2014 at 9:11 AM, Matthias Wessendorf <matzew at apache.org>
> > > wrote:
> > >
> > > >
> > > >
> > > >
> > > > On Fri, May 30, 2014 at 6:44 PM, Luk?? Fry? <lukas.fryc at gmail.com>
> > wrote:
> > > >
> > > >> Hey man,
> > > >>
> > > >> I can't find the instructions myself atm.
> > > >> (they could have been lost during merge (?))
> > > >>
> > > >
> > > > hrm, yeah - surprised to see the README is no longer around
> > > >
> > > >
> > > >
> > > >>
> > > >> I found this copy, which is almost up to date:
> > > >>
> > > >>
> > https://github.com/lfryc/aerogear-unifiedpush-server/tree/master/admin-ui#using-with-jboss-eapwildfly
> > > >>
> > > >> Basically, run
> > > >>
> > > >> upload exploded ag-push.war/ to JBoss AS 7.1.
> > > >> $ cd admin-ui/
> > > >> $ grunt server
> > > >> modify generated local-config.json to point to that exploded war
> > > >> $ grunt server
> > > >>
> > > >> Hope it helps.
> > > >>
> > > >> Meanwhile, I will update the instructions in the master.
> > > >>
> > > >> Cheers,
> > > >>
> > > >> ~ Lukas
> > > >>
> > > >>
> > > >> On Fri, May 30, 2014 at 6:03 PM, Bruno Oliveira <bruno at abstractj.org>
> > > >> wrote:
> > > >>
> > > >>> Good morning,
> > > >>>
> > > >>> I'm looking for instructions of how to build admin-ui correctly.
> > Where
> > > >>> could I find it?
> > > >>>
> > > >>> Currently I tried
> > > >>>
> > > >>>
> > https://github.com/aerogear/aerogear-unifiedpush-server-admin-ui/blob/master/README.md
> > > >>> and also
> > > >>>
> > https://github.com/aerogear/collateral/wiki/UPS-Admin-Console-Process.
> > > >>> The reason why I want this is because Sebastien managed to get it
> > > >>> working
> > > >>>
> > > >>>
> > https://github.com/abstractj/aerogear-unifiedpush-server/tree/angular-auth
> > > >>> and something very dirty might be happening with my environment.
> > > >>>
> > > >>> What I want to do is very simple. Trigger the following event:
> > > >>>
> > > >>>
> > https://github.com/abstractj/aerogear-unifiedpush-server/commit/aeed989288ae0c42a8f163b303fb1d89a029b635#diff-bd44ccad477ae267b4939a7797ddc9eeR90
> > > >>> .
> > > >>>
> > > >>> I also tried to copy these files to server/src/main/webapp/ but it
> > > >>> didnt'work.
> > > >>>
> > > >>> Thanks in advance.
> > > >>>
> > > >>> --
> > > >>>
> > > >>> abstractj
> > > >>> _______________________________________________
> > > >>> aerogear-dev mailing list
> > > >>> aerogear-dev at lists.jboss.org
> > > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > >>>
> > > >>
> > > >>
> > > >> _______________________________________________
> > > >> aerogear-dev mailing list
> > > >> aerogear-dev at lists.jboss.org
> > > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > >>
> > > >
> > > >
> > > >
> > > > --
> > > > Matthias Wessendorf
> > > >
> > > > blog: http://matthiaswessendorf.wordpress.com/
> > > > sessions: http://www.slideshare.net/mwessendorf
> > > > twitter: http://twitter.com/mwessendorf
> > > >
> > > > _______________________________________________
> > > > aerogear-dev mailing list
> > > > aerogear-dev at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > >
> >
> > > _______________________________________________
> > > aerogear-dev mailing list
> > > aerogear-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> >
> > --
> >
> > abstractj
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf

> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


--

abstractj

From bruno at abstractj.org  Tue Jun  3 06:39:48 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Tue, 3 Jun 2014 07:39:48 -0300
Subject: [aerogear-dev] contacts-mobile-basic quick start
In-Reply-To: <1401776740005-8059.post@n5.nabble.com>
References: <33FAC87C-F08E-4C86-842F-7A3F7D107D45@redhat.com>
	<A7CCCFDE-F89A-4E8F-9C06-BD7BC1577259@gmail.com>
	<CAFJm-3FOidFs5D7ogThjO7mORtb5q55r8BRCcn9jNbjoiHFy6w@mail.gmail.com>
	<CAAg5f2Q536Zi1A=OvhFEmdcN_8jzd3uALJ4sbfUom89d3p5Pzw@mail.gmail.com>
	<CAFJm-3ES4VQL8=rBT22jKuo+6T-18AB4Oh=XP4p172o4fSLR1g@mail.gmail.com>
	<CAFJm-3H9-t1E--T+_ctZ7+YVpw2XVwByoHFm-hFSBZWTxMiQag@mail.gmail.com>
	<CAFJm-3Fxd8LR8eqhGTBzutpc_Tu+LsQ5VW+ANzrKaq0QnbBmZw@mail.gmail.com>
	<682680FC-677F-4566-8E2C-9392CEC4FC83@gmail.com>
	<1401776740005-8059.post@n5.nabble.com>
Message-ID: <20140603103948.GD88786@abstractj.org>

My feeling is that the server is not keeping the session properly. I
think Pedro could help you with this.

On 2014-06-02, danielbevenius wrote:
> I'm struggling with extracting the webapp from
> contacts-mobile-picketlink-secured. I've put the details of the problem I'm
> having in this gist:
> https://gist.github.com/danbev/ef3a2a08b5d8e41d6879
>
> If you don't have time to read the above gist the issue is basically that I
> don't understand why two logins are required for a user to be considered
> logged in by PicketLink. If anyone has input or can spot something I'm doing
> wrong please let me know.
>
> With two logins I'm able to get the webapp working in Chrome, FireFox,
> Safari, and Opera.
>
> /Dan
>
>
>
> --
> View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-contacts-mobile-basic-quick-start-tp7534p8059.html
> Sent from the aerogear-dev mailing list archive at Nabble.com.
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev

--

abstractj

From scm.blanc at gmail.com  Tue Jun  3 07:08:57 2014
From: scm.blanc at gmail.com (Sebastien Blanc)
Date: Tue, 3 Jun 2014 13:08:57 +0200
Subject: [aerogear-dev] Instructions to build admin-ui
In-Reply-To: <20140603103001.GB88786@abstractj.org>
References: <20140530160333.GA20669@abstractj.org>
	<CAEroY36Yg+jrx1OwSZ6T=HYXEok8b9QEdtOz6tes8EFCC6gCxw@mail.gmail.com>
	<CAAg5f2R_ESP-=P0YYhcNCW4v+Co1aNc1g4zxTm=cgEfE+bm-ug@mail.gmail.com>
	<CAD_dpu0n+-9YPDW=+3GN8V9d3PzAMiY5pHQcSMaGkm6KfUjZ9Q@mail.gmail.com>
	<20140602200859.GA57261@abstractj.org>
	<CAD_dpu0rf715aj39wyVmO-abz2AcC2ZNVLJxcPKOVf4_PTdPJA@mail.gmail.com>
	<20140603103001.GB88786@abstractj.org>
Message-ID: <CAD_dpu0dr1u5ZS2YKXm8VES89GV=dsiB=3GYT3tN1isZ_Tureg@mail.gmail.com>

Ah right ! Sorry
Ok I think I know what's missing :
before "grunt server" do a "npm install" and then "bower install" , should
help :)



On Tue, Jun 3, 2014 at 12:30 PM, Bruno Oliveira <bruno at abstractj.org> wrote:

> On 2014-06-02, Sebastien Blanc wrote:
> > Do you copy the ag-push.war from target as an exploded war into
> > /deployments ? Otherwise the grunt task won't be able to make the copy
> tak.
>
> I guess so, please see step 3. That's what am I supposed to do, right?
>
> >
> >
> >
> > On Mon, Jun 2, 2014 at 10:08 PM, Bruno Oliveira <bruno at abstractj.org>
> wrote:
> >
> > > Ahoy,
> > >
> > > I might be doing something dead wrong, these are the steps followed
> > > here:
> > >
> > > 1. rm -rf jboss-as-7.1.1.Final && tar xzvf jboss-as-7.1.1.Final.tar.gz
> > > && cd jboss-current && bin/standalone.sh
> > > 2. cp databases/unifiedpush-h2-ds.xml
> > > ~/servers/jboss-current/standalone/deployments && cp
> > > auth-server/target/auth-server.war
> > > ~/servers/jboss-current/standalone/deployments && cp
> > > server/target/ag-push.war
> > > ~/servers/jboss-current/standalone/deployments/ag-push.war.dodeploy
> > >
> > > 3. cp -Rv server/target/ag-push/
> > > ~/servers/jboss-current/standalone/deployments/ag-push.war/
> > > 4. At unified push server project *cd admin-ui*
> > > 5. Run grunt initLocalConfig and edit local-config.json
> > > (https://gist.github.com/abstractj/c355676a649611aa89d7)
> > > 6. Now at
> > > /aerogear/agpush/unifiedpush/aerogear-unifiedpush-server/admin-ui run
> > > *grunt server*
> > > 7. localhost:9000 shows
> > >
> > >
> http://photon.abstractj.org/localhost9000_20140602_170702_20140602_170705.jpg
> > > 8. localhost:8080/ag-push doesn't trigger Sign out event
> > >
> > > If you want to try
> > >
> https://github.com/abstractj/aerogear-unifiedpush-server/tree/angular-auth
> > > .
> > > Certainly is some missing detail during deployment, but that doesn't
> > > work here, any idea about what's wrong is welcome.
> > >
> > > On 2014-06-02, Sebastien Blanc wrote:
> > > > Yes,
> > > >
> > > > We are a bit in a transition phase with the complete overhaul of the
> > > > console. The old readme is not enterily up to date and could be
> > > confusing.
> > > > This JIRA has been created to track this :
> > > > https://issues.jboss.org/browse/AGPUSH-679
> > > >
> > > > @abstractj: in the mean time, you can follow the instructions that
> Lukas
> > > > pointed out.
> > > >
> > > > Sebi
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Mon, Jun 2, 2014 at 9:11 AM, Matthias Wessendorf <
> matzew at apache.org>
> > > > wrote:
> > > >
> > > > >
> > > > >
> > > > >
> > > > > On Fri, May 30, 2014 at 6:44 PM, Luk?? Fry? <lukas.fryc at gmail.com>
> > > wrote:
> > > > >
> > > > >> Hey man,
> > > > >>
> > > > >> I can't find the instructions myself atm.
> > > > >> (they could have been lost during merge (?))
> > > > >>
> > > > >
> > > > > hrm, yeah - surprised to see the README is no longer around
> > > > >
> > > > >
> > > > >
> > > > >>
> > > > >> I found this copy, which is almost up to date:
> > > > >>
> > > > >>
> > >
> https://github.com/lfryc/aerogear-unifiedpush-server/tree/master/admin-ui#using-with-jboss-eapwildfly
> > > > >>
> > > > >> Basically, run
> > > > >>
> > > > >> upload exploded ag-push.war/ to JBoss AS 7.1.
> > > > >> $ cd admin-ui/
> > > > >> $ grunt server
> > > > >> modify generated local-config.json to point to that exploded war
> > > > >> $ grunt server
> > > > >>
> > > > >> Hope it helps.
> > > > >>
> > > > >> Meanwhile, I will update the instructions in the master.
> > > > >>
> > > > >> Cheers,
> > > > >>
> > > > >> ~ Lukas
> > > > >>
> > > > >>
> > > > >> On Fri, May 30, 2014 at 6:03 PM, Bruno Oliveira <
> bruno at abstractj.org>
> > > > >> wrote:
> > > > >>
> > > > >>> Good morning,
> > > > >>>
> > > > >>> I'm looking for instructions of how to build admin-ui correctly.
> > > Where
> > > > >>> could I find it?
> > > > >>>
> > > > >>> Currently I tried
> > > > >>>
> > > > >>>
> > >
> https://github.com/aerogear/aerogear-unifiedpush-server-admin-ui/blob/master/README.md
> > > > >>> and also
> > > > >>>
> > > https://github.com/aerogear/collateral/wiki/UPS-Admin-Console-Process.
> > > > >>> The reason why I want this is because Sebastien managed to get it
> > > > >>> working
> > > > >>>
> > > > >>>
> > >
> https://github.com/abstractj/aerogear-unifiedpush-server/tree/angular-auth
> > > > >>> and something very dirty might be happening with my environment.
> > > > >>>
> > > > >>> What I want to do is very simple. Trigger the following event:
> > > > >>>
> > > > >>>
> > >
> https://github.com/abstractj/aerogear-unifiedpush-server/commit/aeed989288ae0c42a8f163b303fb1d89a029b635#diff-bd44ccad477ae267b4939a7797ddc9eeR90
> > > > >>> .
> > > > >>>
> > > > >>> I also tried to copy these files to server/src/main/webapp/ but
> it
> > > > >>> didnt'work.
> > > > >>>
> > > > >>> Thanks in advance.
> > > > >>>
> > > > >>> --
> > > > >>>
> > > > >>> abstractj
> > > > >>> _______________________________________________
> > > > >>> aerogear-dev mailing list
> > > > >>> aerogear-dev at lists.jboss.org
> > > > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > > >>>
> > > > >>
> > > > >>
> > > > >> _______________________________________________
> > > > >> aerogear-dev mailing list
> > > > >> aerogear-dev at lists.jboss.org
> > > > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > > >>
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Matthias Wessendorf
> > > > >
> > > > > blog: http://matthiaswessendorf.wordpress.com/
> > > > > sessions: http://www.slideshare.net/mwessendorf
> > > > > twitter: http://twitter.com/mwessendorf
> > > > >
> > > > > _______________________________________________
> > > > > aerogear-dev mailing list
> > > > > aerogear-dev at lists.jboss.org
> > > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > > >
> > >
> > > > _______________________________________________
> > > > aerogear-dev mailing list
> > > > aerogear-dev at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > >
> > >
> > > --
> > >
> > > abstractj
> > > _______________________________________________
> > > aerogear-dev mailing list
> > > aerogear-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > >
>
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> --
>
> abstractj
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140603/96c2b529/attachment.html 

From lukas.fryc at gmail.com  Tue Jun  3 07:09:37 2014
From: lukas.fryc at gmail.com (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=)
Date: Tue, 3 Jun 2014 13:09:37 +0200
Subject: [aerogear-dev] Instructions to build admin-ui
In-Reply-To: <20140603103110.GC88786@abstractj.org>
References: <20140530160333.GA20669@abstractj.org>
	<CAEroY36Yg+jrx1OwSZ6T=HYXEok8b9QEdtOz6tes8EFCC6gCxw@mail.gmail.com>
	<CAAg5f2R_ESP-=P0YYhcNCW4v+Co1aNc1g4zxTm=cgEfE+bm-ug@mail.gmail.com>
	<CAD_dpu0n+-9YPDW=+3GN8V9d3PzAMiY5pHQcSMaGkm6KfUjZ9Q@mail.gmail.com>
	<20140602200859.GA57261@abstractj.org>
	<CAAg5f2S-D4F1CxjNw8F7nhg8R3SczoWuBfwuBmdkYW5QC2eVVQ@mail.gmail.com>
	<20140603103110.GC88786@abstractj.org>
Message-ID: <CAEroY34FsWbHjwC-bAX=09rxUheLGAeDFhnXt79Jdw-E9+B_KQ@mail.gmail.com>

Yeah, step (3) is correct,

I assume you are missing

$ bower install (npm install you probably did since you can run grunt)

just after step (4). (I've just run into this issue now)


On Tue, Jun 3, 2014 at 12:31 PM, Bruno Oliveira <bruno at abstractj.org> wrote:

> On 2014-06-03, Matthias Wessendorf wrote:
> > On Mon, Jun 2, 2014 at 10:08 PM, Bruno Oliveira <bruno at abstractj.org>
> wrote:
> >
> > > Ahoy,
> > >
> > > I might be doing something dead wrong, these are the steps followed
> > > here:
> > >
> > > 1. rm -rf jboss-as-7.1.1.Final && tar xzvf jboss-as-7.1.1.Final.tar.gz
> > > && cd jboss-current && bin/standalone.sh
> > > 2. cp databases/unifiedpush-h2-ds.xml
> > > ~/servers/jboss-current/standalone/deployments && cp
> > > auth-server/target/auth-server.war
> > > ~/servers/jboss-current/standalone/deployments && cp
> > > server/target/ag-push.war
> > > ~/servers/jboss-current/standalone/deployments/ag-push.war.dodeploy
> > >
> > > 3. cp -Rv server/target/ag-push/
> > > ~/servers/jboss-current/standalone/deployments/ag-push.war/
> > > 4. At unified push server project *cd admin-ui*
> > > 5. Run grunt initLocalConfig and edit local-config.json
> > > (https://gist.github.com/abstractj/c355676a649611aa89d7)
> > > 6. Now at
> > > /aerogear/agpush/unifiedpush/aerogear-unifiedpush-server/admin-ui run
> > > *grunt server*
> > > 7. localhost:9000 shows
> > >
> > >
> http://photon.abstractj.org/localhost9000_20140602_170702_20140602_170705.jpg
> > > 8. localhost:8080/ag-push doesn't trigger Sign out event
> > >
> >
> > might be unrelated, but perhaps not. After their Beta1 release Bill
> fixed a
> > bug on the AS7 adapter:
> > https://github.com/keycloak/keycloak/pull/446
>
> I think it's unrelated because I don't even make use of Keycloak.js.
> It's just plain Angular.js for testing purposes.
>
> >
> >
> > -Matthias
> >
> >
> > >
> > > If you want to try
> > >
> https://github.com/abstractj/aerogear-unifiedpush-server/tree/angular-auth
> > > .
> > > Certainly is some missing detail during deployment, but that doesn't
> > > work here, any idea about what's wrong is welcome.
> > >
> > > On 2014-06-02, Sebastien Blanc wrote:
> > > > Yes,
> > > >
> > > > We are a bit in a transition phase with the complete overhaul of the
> > > > console. The old readme is not enterily up to date and could be
> > > confusing.
> > > > This JIRA has been created to track this :
> > > > https://issues.jboss.org/browse/AGPUSH-679
> > > >
> > > > @abstractj: in the mean time, you can follow the instructions that
> Lukas
> > > > pointed out.
> > > >
> > > > Sebi
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Mon, Jun 2, 2014 at 9:11 AM, Matthias Wessendorf <
> matzew at apache.org>
> > > > wrote:
> > > >
> > > > >
> > > > >
> > > > >
> > > > > On Fri, May 30, 2014 at 6:44 PM, Luk?? Fry? <lukas.fryc at gmail.com>
> > > wrote:
> > > > >
> > > > >> Hey man,
> > > > >>
> > > > >> I can't find the instructions myself atm.
> > > > >> (they could have been lost during merge (?))
> > > > >>
> > > > >
> > > > > hrm, yeah - surprised to see the README is no longer around
> > > > >
> > > > >
> > > > >
> > > > >>
> > > > >> I found this copy, which is almost up to date:
> > > > >>
> > > > >>
> > >
> https://github.com/lfryc/aerogear-unifiedpush-server/tree/master/admin-ui#using-with-jboss-eapwildfly
> > > > >>
> > > > >> Basically, run
> > > > >>
> > > > >> upload exploded ag-push.war/ to JBoss AS 7.1.
> > > > >> $ cd admin-ui/
> > > > >> $ grunt server
> > > > >> modify generated local-config.json to point to that exploded war
> > > > >> $ grunt server
> > > > >>
> > > > >> Hope it helps.
> > > > >>
> > > > >> Meanwhile, I will update the instructions in the master.
> > > > >>
> > > > >> Cheers,
> > > > >>
> > > > >> ~ Lukas
> > > > >>
> > > > >>
> > > > >> On Fri, May 30, 2014 at 6:03 PM, Bruno Oliveira <
> bruno at abstractj.org>
> > > > >> wrote:
> > > > >>
> > > > >>> Good morning,
> > > > >>>
> > > > >>> I'm looking for instructions of how to build admin-ui correctly.
> > > Where
> > > > >>> could I find it?
> > > > >>>
> > > > >>> Currently I tried
> > > > >>>
> > > > >>>
> > >
> https://github.com/aerogear/aerogear-unifiedpush-server-admin-ui/blob/master/README.md
> > > > >>> and also
> > > > >>>
> > > https://github.com/aerogear/collateral/wiki/UPS-Admin-Console-Process.
> > > > >>> The reason why I want this is because Sebastien managed to get it
> > > > >>> working
> > > > >>>
> > > > >>>
> > >
> https://github.com/abstractj/aerogear-unifiedpush-server/tree/angular-auth
> > > > >>> and something very dirty might be happening with my environment.
> > > > >>>
> > > > >>> What I want to do is very simple. Trigger the following event:
> > > > >>>
> > > > >>>
> > >
> https://github.com/abstractj/aerogear-unifiedpush-server/commit/aeed989288ae0c42a8f163b303fb1d89a029b635#diff-bd44ccad477ae267b4939a7797ddc9eeR90
> > > > >>> .
> > > > >>>
> > > > >>> I also tried to copy these files to server/src/main/webapp/ but
> it
> > > > >>> didnt'work.
> > > > >>>
> > > > >>> Thanks in advance.
> > > > >>>
> > > > >>> --
> > > > >>>
> > > > >>> abstractj
> > > > >>> _______________________________________________
> > > > >>> aerogear-dev mailing list
> > > > >>> aerogear-dev at lists.jboss.org
> > > > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > > >>>
> > > > >>
> > > > >>
> > > > >> _______________________________________________
> > > > >> aerogear-dev mailing list
> > > > >> aerogear-dev at lists.jboss.org
> > > > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > > >>
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Matthias Wessendorf
> > > > >
> > > > > blog: http://matthiaswessendorf.wordpress.com/
> > > > > sessions: http://www.slideshare.net/mwessendorf
> > > > > twitter: http://twitter.com/mwessendorf
> > > > >
> > > > > _______________________________________________
> > > > > aerogear-dev mailing list
> > > > > aerogear-dev at lists.jboss.org
> > > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > > >
> > >
> > > > _______________________________________________
> > > > aerogear-dev mailing list
> > > > aerogear-dev at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > >
> > >
> > > --
> > >
> > > abstractj
> > > _______________________________________________
> > > aerogear-dev mailing list
> > > aerogear-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > >
> >
> >
> >
> > --
> > Matthias Wessendorf
> >
> > blog: http://matthiaswessendorf.wordpress.com/
> > sessions: http://www.slideshare.net/mwessendorf
> > twitter: http://twitter.com/mwessendorf
>
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> --
>
> abstractj
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140603/eb5edd65/attachment-0001.html 

From daniel.bevenius at gmail.com  Tue Jun  3 08:32:09 2014
From: daniel.bevenius at gmail.com (danielbevenius)
Date: Tue, 3 Jun 2014 05:32:09 -0700 (PDT)
Subject: [aerogear-dev] contacts-mobile-basic quick start
In-Reply-To: <20140603103948.GD88786@abstractj.org>
References: <33FAC87C-F08E-4C86-842F-7A3F7D107D45@redhat.com>
	<A7CCCFDE-F89A-4E8F-9C06-BD7BC1577259@gmail.com>
	<CAFJm-3FOidFs5D7ogThjO7mORtb5q55r8BRCcn9jNbjoiHFy6w@mail.gmail.com>
	<CAAg5f2Q536Zi1A=OvhFEmdcN_8jzd3uALJ4sbfUom89d3p5Pzw@mail.gmail.com>
	<CAFJm-3ES4VQL8=rBT22jKuo+6T-18AB4Oh=XP4p172o4fSLR1g@mail.gmail.com>
	<CAFJm-3H9-t1E--T+_ctZ7+YVpw2XVwByoHFm-hFSBZWTxMiQag@mail.gmail.com>
	<CAFJm-3Fxd8LR8eqhGTBzutpc_Tu+LsQ5VW+ANzrKaq0QnbBmZw@mail.gmail.com>
	<682680FC-677F-4566-8E2C-9392CEC4FC83@gmail.com>
	<1401776740005-8059.post@n5.nabble.com>
	<20140603103948.GD88786@abstractj.org>
Message-ID: <1401798729477-8072.post@n5.nabble.com>

This was all me (again). I think I found the issue I was having with the
first login and that was that I did not set withCredentials for that call
which I should since there will be a preflight request for this request.
This effected the session handling which caused the session on the server to
not be found. The second login had withCredentials which explains why it
worked. 

I also removed the loadCurrentUser method and I'm just storing the data
returned from the first login to save the additional request. So only one
login will be performed. 

The branch can be found here:
https://github.com/danbev/jboss-wfk-quickstarts/tree/push-proxy-quickstart

As soon we have a fabric8-1.1.0.Beta7 tag to build against I'll issue a PR
for this work.





--
View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-contacts-mobile-basic-quick-start-tp7534p8072.html
Sent from the aerogear-dev mailing list archive at Nabble.com.

From matzew at apache.org  Tue Jun  3 10:00:12 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Tue, 3 Jun 2014 16:00:12 +0200
Subject: [aerogear-dev] Instructions to build admin-ui
In-Reply-To: <CAD_dpu0dr1u5ZS2YKXm8VES89GV=dsiB=3GYT3tN1isZ_Tureg@mail.gmail.com>
References: <20140530160333.GA20669@abstractj.org>
	<CAEroY36Yg+jrx1OwSZ6T=HYXEok8b9QEdtOz6tes8EFCC6gCxw@mail.gmail.com>
	<CAAg5f2R_ESP-=P0YYhcNCW4v+Co1aNc1g4zxTm=cgEfE+bm-ug@mail.gmail.com>
	<CAD_dpu0n+-9YPDW=+3GN8V9d3PzAMiY5pHQcSMaGkm6KfUjZ9Q@mail.gmail.com>
	<20140602200859.GA57261@abstractj.org>
	<CAD_dpu0rf715aj39wyVmO-abz2AcC2ZNVLJxcPKOVf4_PTdPJA@mail.gmail.com>
	<20140603103001.GB88786@abstractj.org>
	<CAD_dpu0dr1u5ZS2YKXm8VES89GV=dsiB=3GYT3tN1isZ_Tureg@mail.gmail.com>
Message-ID: <CAAg5f2SbtBi6ODnaQKsiCSFcHhU2MR22ij8g18b+yb6PATJrTg@mail.gmail.com>

On Tue, Jun 3, 2014 at 1:08 PM, Sebastien Blanc <scm.blanc at gmail.com> wrote:

> Ah right ! Sorry
> Ok I think I know what's missing :
> before "grunt server" do a "npm install"
>


running npm install - I get this:

https://gist.github.com/matzew/8d9ffb415394286915c3



> and then "bower install" , should help :)
>
>
>
> On Tue, Jun 3, 2014 at 12:30 PM, Bruno Oliveira <bruno at abstractj.org>
> wrote:
>
>> On 2014-06-02, Sebastien Blanc wrote:
>> > Do you copy the ag-push.war from target as an exploded war into
>> > /deployments ? Otherwise the grunt task won't be able to make the copy
>> tak.
>>
>> I guess so, please see step 3. That's what am I supposed to do, right?
>>
>> >
>> >
>> >
>> > On Mon, Jun 2, 2014 at 10:08 PM, Bruno Oliveira <bruno at abstractj.org>
>> wrote:
>> >
>> > > Ahoy,
>> > >
>> > > I might be doing something dead wrong, these are the steps followed
>> > > here:
>> > >
>> > > 1. rm -rf jboss-as-7.1.1.Final && tar xzvf jboss-as-7.1.1.Final.tar.gz
>> > > && cd jboss-current && bin/standalone.sh
>> > > 2. cp databases/unifiedpush-h2-ds.xml
>> > > ~/servers/jboss-current/standalone/deployments && cp
>> > > auth-server/target/auth-server.war
>> > > ~/servers/jboss-current/standalone/deployments && cp
>> > > server/target/ag-push.war
>> > > ~/servers/jboss-current/standalone/deployments/ag-push.war.dodeploy
>> > >
>> > > 3. cp -Rv server/target/ag-push/
>> > > ~/servers/jboss-current/standalone/deployments/ag-push.war/
>> > > 4. At unified push server project *cd admin-ui*
>> > > 5. Run grunt initLocalConfig and edit local-config.json
>> > > (https://gist.github.com/abstractj/c355676a649611aa89d7)
>> > > 6. Now at
>> > > /aerogear/agpush/unifiedpush/aerogear-unifiedpush-server/admin-ui run
>> > > *grunt server*
>> > > 7. localhost:9000 shows
>> > >
>> > >
>> http://photon.abstractj.org/localhost9000_20140602_170702_20140602_170705.jpg
>> > > 8. localhost:8080/ag-push doesn't trigger Sign out event
>> > >
>> > > If you want to try
>> > >
>> https://github.com/abstractj/aerogear-unifiedpush-server/tree/angular-auth
>> > > .
>> > > Certainly is some missing detail during deployment, but that doesn't
>> > > work here, any idea about what's wrong is welcome.
>> > >
>> > > On 2014-06-02, Sebastien Blanc wrote:
>> > > > Yes,
>> > > >
>> > > > We are a bit in a transition phase with the complete overhaul of the
>> > > > console. The old readme is not enterily up to date and could be
>> > > confusing.
>> > > > This JIRA has been created to track this :
>> > > > https://issues.jboss.org/browse/AGPUSH-679
>> > > >
>> > > > @abstractj: in the mean time, you can follow the instructions that
>> Lukas
>> > > > pointed out.
>> > > >
>> > > > Sebi
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > On Mon, Jun 2, 2014 at 9:11 AM, Matthias Wessendorf <
>> matzew at apache.org>
>> > > > wrote:
>> > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > > On Fri, May 30, 2014 at 6:44 PM, Luk?? Fry? <lukas.fryc at gmail.com
>> >
>> > > wrote:
>> > > > >
>> > > > >> Hey man,
>> > > > >>
>> > > > >> I can't find the instructions myself atm.
>> > > > >> (they could have been lost during merge (?))
>> > > > >>
>> > > > >
>> > > > > hrm, yeah - surprised to see the README is no longer around
>> > > > >
>> > > > >
>> > > > >
>> > > > >>
>> > > > >> I found this copy, which is almost up to date:
>> > > > >>
>> > > > >>
>> > >
>> https://github.com/lfryc/aerogear-unifiedpush-server/tree/master/admin-ui#using-with-jboss-eapwildfly
>> > > > >>
>> > > > >> Basically, run
>> > > > >>
>> > > > >> upload exploded ag-push.war/ to JBoss AS 7.1.
>> > > > >> $ cd admin-ui/
>> > > > >> $ grunt server
>> > > > >> modify generated local-config.json to point to that exploded war
>> > > > >> $ grunt server
>> > > > >>
>> > > > >> Hope it helps.
>> > > > >>
>> > > > >> Meanwhile, I will update the instructions in the master.
>> > > > >>
>> > > > >> Cheers,
>> > > > >>
>> > > > >> ~ Lukas
>> > > > >>
>> > > > >>
>> > > > >> On Fri, May 30, 2014 at 6:03 PM, Bruno Oliveira <
>> bruno at abstractj.org>
>> > > > >> wrote:
>> > > > >>
>> > > > >>> Good morning,
>> > > > >>>
>> > > > >>> I'm looking for instructions of how to build admin-ui correctly.
>> > > Where
>> > > > >>> could I find it?
>> > > > >>>
>> > > > >>> Currently I tried
>> > > > >>>
>> > > > >>>
>> > >
>> https://github.com/aerogear/aerogear-unifiedpush-server-admin-ui/blob/master/README.md
>> > > > >>> and also
>> > > > >>>
>> > > https://github.com/aerogear/collateral/wiki/UPS-Admin-Console-Process
>> .
>> > > > >>> The reason why I want this is because Sebastien managed to get
>> it
>> > > > >>> working
>> > > > >>>
>> > > > >>>
>> > >
>> https://github.com/abstractj/aerogear-unifiedpush-server/tree/angular-auth
>> > > > >>> and something very dirty might be happening with my environment.
>> > > > >>>
>> > > > >>> What I want to do is very simple. Trigger the following event:
>> > > > >>>
>> > > > >>>
>> > >
>> https://github.com/abstractj/aerogear-unifiedpush-server/commit/aeed989288ae0c42a8f163b303fb1d89a029b635#diff-bd44ccad477ae267b4939a7797ddc9eeR90
>> > > > >>> .
>> > > > >>>
>> > > > >>> I also tried to copy these files to server/src/main/webapp/ but
>> it
>> > > > >>> didnt'work.
>> > > > >>>
>> > > > >>> Thanks in advance.
>> > > > >>>
>> > > > >>> --
>> > > > >>>
>> > > > >>> abstractj
>> > > > >>> _______________________________________________
>> > > > >>> aerogear-dev mailing list
>> > > > >>> aerogear-dev at lists.jboss.org
>> > > > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> > > > >>>
>> > > > >>
>> > > > >>
>> > > > >> _______________________________________________
>> > > > >> aerogear-dev mailing list
>> > > > >> aerogear-dev at lists.jboss.org
>> > > > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> > > > >>
>> > > > >
>> > > > >
>> > > > >
>> > > > > --
>> > > > > Matthias Wessendorf
>> > > > >
>> > > > > blog: http://matthiaswessendorf.wordpress.com/
>> > > > > sessions: http://www.slideshare.net/mwessendorf
>> > > > > twitter: http://twitter.com/mwessendorf
>> > > > >
>> > > > > _______________________________________________
>> > > > > aerogear-dev mailing list
>> > > > > aerogear-dev at lists.jboss.org
>> > > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> > > > >
>> > >
>> > > > _______________________________________________
>> > > > aerogear-dev mailing list
>> > > > aerogear-dev at lists.jboss.org
>> > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> > >
>> > >
>> > > --
>> > >
>> > > abstractj
>> > > _______________________________________________
>> > > aerogear-dev mailing list
>> > > aerogear-dev at lists.jboss.org
>> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> > >
>>
>> > _______________________________________________
>> > aerogear-dev mailing list
>> > aerogear-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>> --
>>
>> abstractj
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140603/d1b44d2d/attachment.html 

From bruno at abstractj.org  Tue Jun  3 11:24:43 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Tue, 3 Jun 2014 12:24:43 -0300
Subject: [aerogear-dev] Instructions to build admin-ui
In-Reply-To: <CAEroY34FsWbHjwC-bAX=09rxUheLGAeDFhnXt79Jdw-E9+B_KQ@mail.gmail.com>
References: <20140530160333.GA20669@abstractj.org>
	<CAEroY36Yg+jrx1OwSZ6T=HYXEok8b9QEdtOz6tes8EFCC6gCxw@mail.gmail.com>
	<CAAg5f2R_ESP-=P0YYhcNCW4v+Co1aNc1g4zxTm=cgEfE+bm-ug@mail.gmail.com>
	<CAD_dpu0n+-9YPDW=+3GN8V9d3PzAMiY5pHQcSMaGkm6KfUjZ9Q@mail.gmail.com>
	<20140602200859.GA57261@abstractj.org>
	<CAAg5f2S-D4F1CxjNw8F7nhg8R3SczoWuBfwuBmdkYW5QC2eVVQ@mail.gmail.com>
	<20140603103110.GC88786@abstractj.org>
	<CAEroY34FsWbHjwC-bAX=09rxUheLGAeDFhnXt79Jdw-E9+B_KQ@mail.gmail.com>
Message-ID: <20140603152442.GA6724@abstractj.org>

Thank you Luk??, that displayed the admin-ui properly here. Now I think
I'm almost there.

The "Sign out" event was supposed to trigger an event[1], but nothing
happens. The unziped war file has the changes included by Sebastien[2] and
I can see the grunt server reloading when something change.

[1] -
https://github.com/abstractj/aerogear-unifiedpush-server/blob/angular-auth/admin-ui/app/index.html#L64
[2] -
https://github.com/abstractj/aerogear-unifiedpush-server/commit/2dd1b60048d85f62b734aa1050c71b0a89f7ee81

Thanks in advance.

On 2014-06-03, Luk?? Fry? wrote:
> Yeah, step (3) is correct,
>
> I assume you are missing
>
> $ bower install (npm install you probably did since you can run grunt)
>
> just after step (4). (I've just run into this issue now)
>
>
> On Tue, Jun 3, 2014 at 12:31 PM, Bruno Oliveira <bruno at abstractj.org> wrote:
>
> > On 2014-06-03, Matthias Wessendorf wrote:
> > > On Mon, Jun 2, 2014 at 10:08 PM, Bruno Oliveira <bruno at abstractj.org>
> > wrote:
> > >
> > > > Ahoy,
> > > >
> > > > I might be doing something dead wrong, these are the steps followed
> > > > here:
> > > >
> > > > 1. rm -rf jboss-as-7.1.1.Final && tar xzvf jboss-as-7.1.1.Final.tar.gz
> > > > && cd jboss-current && bin/standalone.sh
> > > > 2. cp databases/unifiedpush-h2-ds.xml
> > > > ~/servers/jboss-current/standalone/deployments && cp
> > > > auth-server/target/auth-server.war
> > > > ~/servers/jboss-current/standalone/deployments && cp
> > > > server/target/ag-push.war
> > > > ~/servers/jboss-current/standalone/deployments/ag-push.war.dodeploy
> > > >
> > > > 3. cp -Rv server/target/ag-push/
> > > > ~/servers/jboss-current/standalone/deployments/ag-push.war/
> > > > 4. At unified push server project *cd admin-ui*
> > > > 5. Run grunt initLocalConfig and edit local-config.json
> > > > (https://gist.github.com/abstractj/c355676a649611aa89d7)
> > > > 6. Now at
> > > > /aerogear/agpush/unifiedpush/aerogear-unifiedpush-server/admin-ui run
> > > > *grunt server*
> > > > 7. localhost:9000 shows
> > > >
> > > >
> > http://photon.abstractj.org/localhost9000_20140602_170702_20140602_170705.jpg
> > > > 8. localhost:8080/ag-push doesn't trigger Sign out event
> > > >
> > >
> > > might be unrelated, but perhaps not. After their Beta1 release Bill
> > fixed a
> > > bug on the AS7 adapter:
> > > https://github.com/keycloak/keycloak/pull/446
> >
> > I think it's unrelated because I don't even make use of Keycloak.js.
> > It's just plain Angular.js for testing purposes.
> >
> > >
> > >
> > > -Matthias
> > >
> > >
> > > >
> > > > If you want to try
> > > >
> > https://github.com/abstractj/aerogear-unifiedpush-server/tree/angular-auth
> > > > .
> > > > Certainly is some missing detail during deployment, but that doesn't
> > > > work here, any idea about what's wrong is welcome.
> > > >
> > > > On 2014-06-02, Sebastien Blanc wrote:
> > > > > Yes,
> > > > >
> > > > > We are a bit in a transition phase with the complete overhaul of the
> > > > > console. The old readme is not enterily up to date and could be
> > > > confusing.
> > > > > This JIRA has been created to track this :
> > > > > https://issues.jboss.org/browse/AGPUSH-679
> > > > >
> > > > > @abstractj: in the mean time, you can follow the instructions that
> > Lukas
> > > > > pointed out.
> > > > >
> > > > > Sebi
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Mon, Jun 2, 2014 at 9:11 AM, Matthias Wessendorf <
> > matzew at apache.org>
> > > > > wrote:
> > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Fri, May 30, 2014 at 6:44 PM, Luk?? Fry? <lukas.fryc at gmail.com>
> > > > wrote:
> > > > > >
> > > > > >> Hey man,
> > > > > >>
> > > > > >> I can't find the instructions myself atm.
> > > > > >> (they could have been lost during merge (?))
> > > > > >>
> > > > > >
> > > > > > hrm, yeah - surprised to see the README is no longer around
> > > > > >
> > > > > >
> > > > > >
> > > > > >>
> > > > > >> I found this copy, which is almost up to date:
> > > > > >>
> > > > > >>
> > > >
> > https://github.com/lfryc/aerogear-unifiedpush-server/tree/master/admin-ui#using-with-jboss-eapwildfly
> > > > > >>
> > > > > >> Basically, run
> > > > > >>
> > > > > >> upload exploded ag-push.war/ to JBoss AS 7.1.
> > > > > >> $ cd admin-ui/
> > > > > >> $ grunt server
> > > > > >> modify generated local-config.json to point to that exploded war
> > > > > >> $ grunt server
> > > > > >>
> > > > > >> Hope it helps.
> > > > > >>
> > > > > >> Meanwhile, I will update the instructions in the master.
> > > > > >>
> > > > > >> Cheers,
> > > > > >>
> > > > > >> ~ Lukas
> > > > > >>
> > > > > >>
> > > > > >> On Fri, May 30, 2014 at 6:03 PM, Bruno Oliveira <
> > bruno at abstractj.org>
> > > > > >> wrote:
> > > > > >>
> > > > > >>> Good morning,
> > > > > >>>
> > > > > >>> I'm looking for instructions of how to build admin-ui correctly.
> > > > Where
> > > > > >>> could I find it?
> > > > > >>>
> > > > > >>> Currently I tried
> > > > > >>>
> > > > > >>>
> > > >
> > https://github.com/aerogear/aerogear-unifiedpush-server-admin-ui/blob/master/README.md
> > > > > >>> and also
> > > > > >>>
> > > > https://github.com/aerogear/collateral/wiki/UPS-Admin-Console-Process.
> > > > > >>> The reason why I want this is because Sebastien managed to get it
> > > > > >>> working
> > > > > >>>
> > > > > >>>
> > > >
> > https://github.com/abstractj/aerogear-unifiedpush-server/tree/angular-auth
> > > > > >>> and something very dirty might be happening with my environment.
> > > > > >>>
> > > > > >>> What I want to do is very simple. Trigger the following event:
> > > > > >>>
> > > > > >>>
> > > >
> > https://github.com/abstractj/aerogear-unifiedpush-server/commit/aeed989288ae0c42a8f163b303fb1d89a029b635#diff-bd44ccad477ae267b4939a7797ddc9eeR90
> > > > > >>> .
> > > > > >>>
> > > > > >>> I also tried to copy these files to server/src/main/webapp/ but
> > it
> > > > > >>> didnt'work.
> > > > > >>>
> > > > > >>> Thanks in advance.
> > > > > >>>
> > > > > >>> --
> > > > > >>>
> > > > > >>> abstractj
> > > > > >>> _______________________________________________
> > > > > >>> aerogear-dev mailing list
> > > > > >>> aerogear-dev at lists.jboss.org
> > > > > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > > > >>>
> > > > > >>
> > > > > >>
> > > > > >> _______________________________________________
> > > > > >> aerogear-dev mailing list
> > > > > >> aerogear-dev at lists.jboss.org
> > > > > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > > > >>
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Matthias Wessendorf
> > > > > >
> > > > > > blog: http://matthiaswessendorf.wordpress.com/
> > > > > > sessions: http://www.slideshare.net/mwessendorf
> > > > > > twitter: http://twitter.com/mwessendorf
> > > > > >
> > > > > > _______________________________________________
> > > > > > aerogear-dev mailing list
> > > > > > aerogear-dev at lists.jboss.org
> > > > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > > > >
> > > >
> > > > > _______________________________________________
> > > > > aerogear-dev mailing list
> > > > > aerogear-dev at lists.jboss.org
> > > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > >
> > > >
> > > > --
> > > >
> > > > abstractj
> > > > _______________________________________________
> > > > aerogear-dev mailing list
> > > > aerogear-dev at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > >
> > >
> > >
> > >
> > > --
> > > Matthias Wessendorf
> > >
> > > blog: http://matthiaswessendorf.wordpress.com/
> > > sessions: http://www.slideshare.net/mwessendorf
> > > twitter: http://twitter.com/mwessendorf
> >
> > > _______________________________________________
> > > aerogear-dev mailing list
> > > aerogear-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> >
> > --
> >
> > abstractj
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >

> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


--

abstractj

From matzew at apache.org  Tue Jun  3 11:34:59 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Tue, 3 Jun 2014 17:34:59 +0200
Subject: [aerogear-dev] Instructions to build admin-ui
In-Reply-To: <20140603152442.GA6724@abstractj.org>
References: <20140530160333.GA20669@abstractj.org>
	<CAEroY36Yg+jrx1OwSZ6T=HYXEok8b9QEdtOz6tes8EFCC6gCxw@mail.gmail.com>
	<CAAg5f2R_ESP-=P0YYhcNCW4v+Co1aNc1g4zxTm=cgEfE+bm-ug@mail.gmail.com>
	<CAD_dpu0n+-9YPDW=+3GN8V9d3PzAMiY5pHQcSMaGkm6KfUjZ9Q@mail.gmail.com>
	<20140602200859.GA57261@abstractj.org>
	<CAAg5f2S-D4F1CxjNw8F7nhg8R3SczoWuBfwuBmdkYW5QC2eVVQ@mail.gmail.com>
	<20140603103110.GC88786@abstractj.org>
	<CAEroY34FsWbHjwC-bAX=09rxUheLGAeDFhnXt79Jdw-E9+B_KQ@mail.gmail.com>
	<20140603152442.GA6724@abstractj.org>
Message-ID: <CAAg5f2RZVuyY7sBtq=c43Si6aqyfvLmhun0p9152hPWX38bqWw@mail.gmail.com>

On Tue, Jun 3, 2014 at 5:24 PM, Bruno Oliveira <bruno at abstractj.org> wrote:

> Thank you Luk??, that displayed the admin-ui properly here. Now I think
> I'm almost there.
>
> The "Sign out" event was supposed to trigger an event[1], but nothing
> happens.



So, you can't integrate any custom JS into that logout()



> The unziped war file has the changes included by Sebastien[2] and
> I can see the grunt server reloading when something change.
>
> [1] -
>
> https://github.com/abstractj/aerogear-unifiedpush-server/blob/angular-auth/admin-ui/app/index.html#L64
> [2] -
>
> https://github.com/abstractj/aerogear-unifiedpush-server/commit/2dd1b60048d85f62b734aa1050c71b0a89f7ee81
>
> Thanks in advance.
>
> On 2014-06-03, Luk?? Fry? wrote:
> > Yeah, step (3) is correct,
> >
> > I assume you are missing
> >
> > $ bower install (npm install you probably did since you can run grunt)
> >
> > just after step (4). (I've just run into this issue now)
> >
> >
> > On Tue, Jun 3, 2014 at 12:31 PM, Bruno Oliveira <bruno at abstractj.org>
> wrote:
> >
> > > On 2014-06-03, Matthias Wessendorf wrote:
> > > > On Mon, Jun 2, 2014 at 10:08 PM, Bruno Oliveira <bruno at abstractj.org
> >
> > > wrote:
> > > >
> > > > > Ahoy,
> > > > >
> > > > > I might be doing something dead wrong, these are the steps followed
> > > > > here:
> > > > >
> > > > > 1. rm -rf jboss-as-7.1.1.Final && tar xzvf
> jboss-as-7.1.1.Final.tar.gz
> > > > > && cd jboss-current && bin/standalone.sh
> > > > > 2. cp databases/unifiedpush-h2-ds.xml
> > > > > ~/servers/jboss-current/standalone/deployments && cp
> > > > > auth-server/target/auth-server.war
> > > > > ~/servers/jboss-current/standalone/deployments && cp
> > > > > server/target/ag-push.war
> > > > > ~/servers/jboss-current/standalone/deployments/ag-push.war.dodeploy
> > > > >
> > > > > 3. cp -Rv server/target/ag-push/
> > > > > ~/servers/jboss-current/standalone/deployments/ag-push.war/
> > > > > 4. At unified push server project *cd admin-ui*
> > > > > 5. Run grunt initLocalConfig and edit local-config.json
> > > > > (https://gist.github.com/abstractj/c355676a649611aa89d7)
> > > > > 6. Now at
> > > > > /aerogear/agpush/unifiedpush/aerogear-unifiedpush-server/admin-ui
> run
> > > > > *grunt server*
> > > > > 7. localhost:9000 shows
> > > > >
> > > > >
> > >
> http://photon.abstractj.org/localhost9000_20140602_170702_20140602_170705.jpg
> > > > > 8. localhost:8080/ag-push doesn't trigger Sign out event
> > > > >
> > > >
> > > > might be unrelated, but perhaps not. After their Beta1 release Bill
> > > fixed a
> > > > bug on the AS7 adapter:
> > > > https://github.com/keycloak/keycloak/pull/446
> > >
> > > I think it's unrelated because I don't even make use of Keycloak.js.
> > > It's just plain Angular.js for testing purposes.
> > >
> > > >
> > > >
> > > > -Matthias
> > > >
> > > >
> > > > >
> > > > > If you want to try
> > > > >
> > >
> https://github.com/abstractj/aerogear-unifiedpush-server/tree/angular-auth
> > > > > .
> > > > > Certainly is some missing detail during deployment, but that
> doesn't
> > > > > work here, any idea about what's wrong is welcome.
> > > > >
> > > > > On 2014-06-02, Sebastien Blanc wrote:
> > > > > > Yes,
> > > > > >
> > > > > > We are a bit in a transition phase with the complete overhaul of
> the
> > > > > > console. The old readme is not enterily up to date and could be
> > > > > confusing.
> > > > > > This JIRA has been created to track this :
> > > > > > https://issues.jboss.org/browse/AGPUSH-679
> > > > > >
> > > > > > @abstractj: in the mean time, you can follow the instructions
> that
> > > Lukas
> > > > > > pointed out.
> > > > > >
> > > > > > Sebi
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Mon, Jun 2, 2014 at 9:11 AM, Matthias Wessendorf <
> > > matzew at apache.org>
> > > > > > wrote:
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Fri, May 30, 2014 at 6:44 PM, Luk?? Fry? <
> lukas.fryc at gmail.com>
> > > > > wrote:
> > > > > > >
> > > > > > >> Hey man,
> > > > > > >>
> > > > > > >> I can't find the instructions myself atm.
> > > > > > >> (they could have been lost during merge (?))
> > > > > > >>
> > > > > > >
> > > > > > > hrm, yeah - surprised to see the README is no longer around
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >>
> > > > > > >> I found this copy, which is almost up to date:
> > > > > > >>
> > > > > > >>
> > > > >
> > >
> https://github.com/lfryc/aerogear-unifiedpush-server/tree/master/admin-ui#using-with-jboss-eapwildfly
> > > > > > >>
> > > > > > >> Basically, run
> > > > > > >>
> > > > > > >> upload exploded ag-push.war/ to JBoss AS 7.1.
> > > > > > >> $ cd admin-ui/
> > > > > > >> $ grunt server
> > > > > > >> modify generated local-config.json to point to that exploded
> war
> > > > > > >> $ grunt server
> > > > > > >>
> > > > > > >> Hope it helps.
> > > > > > >>
> > > > > > >> Meanwhile, I will update the instructions in the master.
> > > > > > >>
> > > > > > >> Cheers,
> > > > > > >>
> > > > > > >> ~ Lukas
> > > > > > >>
> > > > > > >>
> > > > > > >> On Fri, May 30, 2014 at 6:03 PM, Bruno Oliveira <
> > > bruno at abstractj.org>
> > > > > > >> wrote:
> > > > > > >>
> > > > > > >>> Good morning,
> > > > > > >>>
> > > > > > >>> I'm looking for instructions of how to build admin-ui
> correctly.
> > > > > Where
> > > > > > >>> could I find it?
> > > > > > >>>
> > > > > > >>> Currently I tried
> > > > > > >>>
> > > > > > >>>
> > > > >
> > >
> https://github.com/aerogear/aerogear-unifiedpush-server-admin-ui/blob/master/README.md
> > > > > > >>> and also
> > > > > > >>>
> > > > >
> https://github.com/aerogear/collateral/wiki/UPS-Admin-Console-Process.
> > > > > > >>> The reason why I want this is because Sebastien managed to
> get it
> > > > > > >>> working
> > > > > > >>>
> > > > > > >>>
> > > > >
> > >
> https://github.com/abstractj/aerogear-unifiedpush-server/tree/angular-auth
> > > > > > >>> and something very dirty might be happening with my
> environment.
> > > > > > >>>
> > > > > > >>> What I want to do is very simple. Trigger the following
> event:
> > > > > > >>>
> > > > > > >>>
> > > > >
> > >
> https://github.com/abstractj/aerogear-unifiedpush-server/commit/aeed989288ae0c42a8f163b303fb1d89a029b635#diff-bd44ccad477ae267b4939a7797ddc9eeR90
> > > > > > >>> .
> > > > > > >>>
> > > > > > >>> I also tried to copy these files to server/src/main/webapp/
> but
> > > it
> > > > > > >>> didnt'work.
> > > > > > >>>
> > > > > > >>> Thanks in advance.
> > > > > > >>>
> > > > > > >>> --
> > > > > > >>>
> > > > > > >>> abstractj
> > > > > > >>> _______________________________________________
> > > > > > >>> aerogear-dev mailing list
> > > > > > >>> aerogear-dev at lists.jboss.org
> > > > > > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > > > > >>>
> > > > > > >>
> > > > > > >>
> > > > > > >> _______________________________________________
> > > > > > >> aerogear-dev mailing list
> > > > > > >> aerogear-dev at lists.jboss.org
> > > > > > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > > > > >>
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Matthias Wessendorf
> > > > > > >
> > > > > > > blog: http://matthiaswessendorf.wordpress.com/
> > > > > > > sessions: http://www.slideshare.net/mwessendorf
> > > > > > > twitter: http://twitter.com/mwessendorf
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > aerogear-dev mailing list
> > > > > > > aerogear-dev at lists.jboss.org
> > > > > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > > > > >
> > > > >
> > > > > > _______________________________________________
> > > > > > aerogear-dev mailing list
> > > > > > aerogear-dev at lists.jboss.org
> > > > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > > >
> > > > >
> > > > > --
> > > > >
> > > > > abstractj
> > > > > _______________________________________________
> > > > > aerogear-dev mailing list
> > > > > aerogear-dev at lists.jboss.org
> > > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Matthias Wessendorf
> > > >
> > > > blog: http://matthiaswessendorf.wordpress.com/
> > > > sessions: http://www.slideshare.net/mwessendorf
> > > > twitter: http://twitter.com/mwessendorf
> > >
> > > > _______________________________________________
> > > > aerogear-dev mailing list
> > > > aerogear-dev at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > >
> > >
> > > --
> > >
> > > abstractj
> > > _______________________________________________
> > > aerogear-dev mailing list
> > > aerogear-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > >
>
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> --
>
> abstractj
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140603/05203d58/attachment.html 

From scm.blanc at gmail.com  Tue Jun  3 11:37:25 2014
From: scm.blanc at gmail.com (Sebastien Blanc)
Date: Tue, 3 Jun 2014 17:37:25 +0200
Subject: [aerogear-dev] Instructions to build admin-ui
In-Reply-To: <20140603152442.GA6724@abstractj.org>
References: <20140530160333.GA20669@abstractj.org>
	<CAEroY36Yg+jrx1OwSZ6T=HYXEok8b9QEdtOz6tes8EFCC6gCxw@mail.gmail.com>
	<CAAg5f2R_ESP-=P0YYhcNCW4v+Co1aNc1g4zxTm=cgEfE+bm-ug@mail.gmail.com>
	<CAD_dpu0n+-9YPDW=+3GN8V9d3PzAMiY5pHQcSMaGkm6KfUjZ9Q@mail.gmail.com>
	<20140602200859.GA57261@abstractj.org>
	<CAAg5f2S-D4F1CxjNw8F7nhg8R3SczoWuBfwuBmdkYW5QC2eVVQ@mail.gmail.com>
	<20140603103110.GC88786@abstractj.org>
	<CAEroY34FsWbHjwC-bAX=09rxUheLGAeDFhnXt79Jdw-E9+B_KQ@mail.gmail.com>
	<20140603152442.GA6724@abstractj.org>
Message-ID: <CAD_dpu1QukLMR-Z74GY+2-zWcpQ9rfov-x2tamZgTE=-uX_JGw@mail.gmail.com>

On Tue, Jun 3, 2014 at 5:24 PM, Bruno Oliveira <bruno at abstractj.org> wrote:

> Thank you Luk??, that displayed the admin-ui properly here. Now I think
> I'm almost there.
>
> The "Sign out" event was supposed to trigger an event[1], but nothing
> happens. The unziped war file has the changes included by Sebastien[2] and
> I can see the grunt server reloading when something change.
>

And still nothing in the JS console ? It's just like the situation before
my fix ?
Let me try your branch again.

>
> [1] -
>
> https://github.com/abstractj/aerogear-unifiedpush-server/blob/angular-auth/admin-ui/app/index.html#L64
> [2] -
>
> https://github.com/abstractj/aerogear-unifiedpush-server/commit/2dd1b60048d85f62b734aa1050c71b0a89f7ee81
>
> Thanks in advance.
>
> On 2014-06-03, Luk?? Fry? wrote:
> > Yeah, step (3) is correct,
> >
> > I assume you are missing
> >
> > $ bower install (npm install you probably did since you can run grunt)
> >
> > just after step (4). (I've just run into this issue now)
> >
> >
> > On Tue, Jun 3, 2014 at 12:31 PM, Bruno Oliveira <bruno at abstractj.org>
> wrote:
> >
> > > On 2014-06-03, Matthias Wessendorf wrote:
> > > > On Mon, Jun 2, 2014 at 10:08 PM, Bruno Oliveira <bruno at abstractj.org
> >
> > > wrote:
> > > >
> > > > > Ahoy,
> > > > >
> > > > > I might be doing something dead wrong, these are the steps followed
> > > > > here:
> > > > >
> > > > > 1. rm -rf jboss-as-7.1.1.Final && tar xzvf
> jboss-as-7.1.1.Final.tar.gz
> > > > > && cd jboss-current && bin/standalone.sh
> > > > > 2. cp databases/unifiedpush-h2-ds.xml
> > > > > ~/servers/jboss-current/standalone/deployments && cp
> > > > > auth-server/target/auth-server.war
> > > > > ~/servers/jboss-current/standalone/deployments && cp
> > > > > server/target/ag-push.war
> > > > > ~/servers/jboss-current/standalone/deployments/ag-push.war.dodeploy
> > > > >
> > > > > 3. cp -Rv server/target/ag-push/
> > > > > ~/servers/jboss-current/standalone/deployments/ag-push.war/
> > > > > 4. At unified push server project *cd admin-ui*
> > > > > 5. Run grunt initLocalConfig and edit local-config.json
> > > > > (https://gist.github.com/abstractj/c355676a649611aa89d7)
> > > > > 6. Now at
> > > > > /aerogear/agpush/unifiedpush/aerogear-unifiedpush-server/admin-ui
> run
> > > > > *grunt server*
> > > > > 7. localhost:9000 shows
> > > > >
> > > > >
> > >
> http://photon.abstractj.org/localhost9000_20140602_170702_20140602_170705.jpg
> > > > > 8. localhost:8080/ag-push doesn't trigger Sign out event
> > > > >
> > > >
> > > > might be unrelated, but perhaps not. After their Beta1 release Bill
> > > fixed a
> > > > bug on the AS7 adapter:
> > > > https://github.com/keycloak/keycloak/pull/446
> > >
> > > I think it's unrelated because I don't even make use of Keycloak.js.
> > > It's just plain Angular.js for testing purposes.
> > >
> > > >
> > > >
> > > > -Matthias
> > > >
> > > >
> > > > >
> > > > > If you want to try
> > > > >
> > >
> https://github.com/abstractj/aerogear-unifiedpush-server/tree/angular-auth
> > > > > .
> > > > > Certainly is some missing detail during deployment, but that
> doesn't
> > > > > work here, any idea about what's wrong is welcome.
> > > > >
> > > > > On 2014-06-02, Sebastien Blanc wrote:
> > > > > > Yes,
> > > > > >
> > > > > > We are a bit in a transition phase with the complete overhaul of
> the
> > > > > > console. The old readme is not enterily up to date and could be
> > > > > confusing.
> > > > > > This JIRA has been created to track this :
> > > > > > https://issues.jboss.org/browse/AGPUSH-679
> > > > > >
> > > > > > @abstractj: in the mean time, you can follow the instructions
> that
> > > Lukas
> > > > > > pointed out.
> > > > > >
> > > > > > Sebi
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Mon, Jun 2, 2014 at 9:11 AM, Matthias Wessendorf <
> > > matzew at apache.org>
> > > > > > wrote:
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Fri, May 30, 2014 at 6:44 PM, Luk?? Fry? <
> lukas.fryc at gmail.com>
> > > > > wrote:
> > > > > > >
> > > > > > >> Hey man,
> > > > > > >>
> > > > > > >> I can't find the instructions myself atm.
> > > > > > >> (they could have been lost during merge (?))
> > > > > > >>
> > > > > > >
> > > > > > > hrm, yeah - surprised to see the README is no longer around
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >>
> > > > > > >> I found this copy, which is almost up to date:
> > > > > > >>
> > > > > > >>
> > > > >
> > >
> https://github.com/lfryc/aerogear-unifiedpush-server/tree/master/admin-ui#using-with-jboss-eapwildfly
> > > > > > >>
> > > > > > >> Basically, run
> > > > > > >>
> > > > > > >> upload exploded ag-push.war/ to JBoss AS 7.1.
> > > > > > >> $ cd admin-ui/
> > > > > > >> $ grunt server
> > > > > > >> modify generated local-config.json to point to that exploded
> war
> > > > > > >> $ grunt server
> > > > > > >>
> > > > > > >> Hope it helps.
> > > > > > >>
> > > > > > >> Meanwhile, I will update the instructions in the master.
> > > > > > >>
> > > > > > >> Cheers,
> > > > > > >>
> > > > > > >> ~ Lukas
> > > > > > >>
> > > > > > >>
> > > > > > >> On Fri, May 30, 2014 at 6:03 PM, Bruno Oliveira <
> > > bruno at abstractj.org>
> > > > > > >> wrote:
> > > > > > >>
> > > > > > >>> Good morning,
> > > > > > >>>
> > > > > > >>> I'm looking for instructions of how to build admin-ui
> correctly.
> > > > > Where
> > > > > > >>> could I find it?
> > > > > > >>>
> > > > > > >>> Currently I tried
> > > > > > >>>
> > > > > > >>>
> > > > >
> > >
> https://github.com/aerogear/aerogear-unifiedpush-server-admin-ui/blob/master/README.md
> > > > > > >>> and also
> > > > > > >>>
> > > > >
> https://github.com/aerogear/collateral/wiki/UPS-Admin-Console-Process.
> > > > > > >>> The reason why I want this is because Sebastien managed to
> get it
> > > > > > >>> working
> > > > > > >>>
> > > > > > >>>
> > > > >
> > >
> https://github.com/abstractj/aerogear-unifiedpush-server/tree/angular-auth
> > > > > > >>> and something very dirty might be happening with my
> environment.
> > > > > > >>>
> > > > > > >>> What I want to do is very simple. Trigger the following
> event:
> > > > > > >>>
> > > > > > >>>
> > > > >
> > >
> https://github.com/abstractj/aerogear-unifiedpush-server/commit/aeed989288ae0c42a8f163b303fb1d89a029b635#diff-bd44ccad477ae267b4939a7797ddc9eeR90
> > > > > > >>> .
> > > > > > >>>
> > > > > > >>> I also tried to copy these files to server/src/main/webapp/
> but
> > > it
> > > > > > >>> didnt'work.
> > > > > > >>>
> > > > > > >>> Thanks in advance.
> > > > > > >>>
> > > > > > >>> --
> > > > > > >>>
> > > > > > >>> abstractj
> > > > > > >>> _______________________________________________
> > > > > > >>> aerogear-dev mailing list
> > > > > > >>> aerogear-dev at lists.jboss.org
> > > > > > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > > > > >>>
> > > > > > >>
> > > > > > >>
> > > > > > >> _______________________________________________
> > > > > > >> aerogear-dev mailing list
> > > > > > >> aerogear-dev at lists.jboss.org
> > > > > > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > > > > >>
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Matthias Wessendorf
> > > > > > >
> > > > > > > blog: http://matthiaswessendorf.wordpress.com/
> > > > > > > sessions: http://www.slideshare.net/mwessendorf
> > > > > > > twitter: http://twitter.com/mwessendorf
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > aerogear-dev mailing list
> > > > > > > aerogear-dev at lists.jboss.org
> > > > > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > > > > >
> > > > >
> > > > > > _______________________________________________
> > > > > > aerogear-dev mailing list
> > > > > > aerogear-dev at lists.jboss.org
> > > > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > > >
> > > > >
> > > > > --
> > > > >
> > > > > abstractj
> > > > > _______________________________________________
> > > > > aerogear-dev mailing list
> > > > > aerogear-dev at lists.jboss.org
> > > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Matthias Wessendorf
> > > >
> > > > blog: http://matthiaswessendorf.wordpress.com/
> > > > sessions: http://www.slideshare.net/mwessendorf
> > > > twitter: http://twitter.com/mwessendorf
> > >
> > > > _______________________________________________
> > > > aerogear-dev mailing list
> > > > aerogear-dev at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > >
> > >
> > > --
> > >
> > > abstractj
> > > _______________________________________________
> > > aerogear-dev mailing list
> > > aerogear-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > >
>
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> --
>
> abstractj
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140603/c47463ce/attachment-0001.html 

From bruno at abstractj.org  Tue Jun  3 12:14:54 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Tue, 3 Jun 2014 13:14:54 -0300
Subject: [aerogear-dev] Instructions to build admin-ui
In-Reply-To: <CAEroY34FsWbHjwC-bAX=09rxUheLGAeDFhnXt79Jdw-E9+B_KQ@mail.gmail.com>
References: <20140530160333.GA20669@abstractj.org>
	<CAEroY36Yg+jrx1OwSZ6T=HYXEok8b9QEdtOz6tes8EFCC6gCxw@mail.gmail.com>
	<CAAg5f2R_ESP-=P0YYhcNCW4v+Co1aNc1g4zxTm=cgEfE+bm-ug@mail.gmail.com>
	<CAD_dpu0n+-9YPDW=+3GN8V9d3PzAMiY5pHQcSMaGkm6KfUjZ9Q@mail.gmail.com>
	<20140602200859.GA57261@abstractj.org>
	<CAAg5f2S-D4F1CxjNw8F7nhg8R3SczoWuBfwuBmdkYW5QC2eVVQ@mail.gmail.com>
	<20140603103110.GC88786@abstractj.org>
	<CAEroY34FsWbHjwC-bAX=09rxUheLGAeDFhnXt79Jdw-E9+B_KQ@mail.gmail.com>
Message-ID: <20140603161454.GB8674@abstractj.org>

Phew, the latest change from Sebi made it work:

https://github.com/abstractj/aerogear-unifiedpush-server/commit/10a16d146c66964aa75ef5a30f4002416ff9d6fb

Thank you guys

On 2014-06-03, Luk?? Fry? wrote:
> Yeah, step (3) is correct,
>
> I assume you are missing
>
> $ bower install (npm install you probably did since you can run grunt)
>
> just after step (4). (I've just run into this issue now)
>
>
> On Tue, Jun 3, 2014 at 12:31 PM, Bruno Oliveira <bruno at abstractj.org> wrote:
>
> > On 2014-06-03, Matthias Wessendorf wrote:
> > > On Mon, Jun 2, 2014 at 10:08 PM, Bruno Oliveira <bruno at abstractj.org>
> > wrote:
> > >
> > > > Ahoy,
> > > >
> > > > I might be doing something dead wrong, these are the steps followed
> > > > here:
> > > >
> > > > 1. rm -rf jboss-as-7.1.1.Final && tar xzvf jboss-as-7.1.1.Final.tar.gz
> > > > && cd jboss-current && bin/standalone.sh
> > > > 2. cp databases/unifiedpush-h2-ds.xml
> > > > ~/servers/jboss-current/standalone/deployments && cp
> > > > auth-server/target/auth-server.war
> > > > ~/servers/jboss-current/standalone/deployments && cp
> > > > server/target/ag-push.war
> > > > ~/servers/jboss-current/standalone/deployments/ag-push.war.dodeploy
> > > >
> > > > 3. cp -Rv server/target/ag-push/
> > > > ~/servers/jboss-current/standalone/deployments/ag-push.war/
> > > > 4. At unified push server project *cd admin-ui*
> > > > 5. Run grunt initLocalConfig and edit local-config.json
> > > > (https://gist.github.com/abstractj/c355676a649611aa89d7)
> > > > 6. Now at
> > > > /aerogear/agpush/unifiedpush/aerogear-unifiedpush-server/admin-ui run
> > > > *grunt server*
> > > > 7. localhost:9000 shows
> > > >
> > > >
> > http://photon.abstractj.org/localhost9000_20140602_170702_20140602_170705.jpg
> > > > 8. localhost:8080/ag-push doesn't trigger Sign out event
> > > >
> > >
> > > might be unrelated, but perhaps not. After their Beta1 release Bill
> > fixed a
> > > bug on the AS7 adapter:
> > > https://github.com/keycloak/keycloak/pull/446
> >
> > I think it's unrelated because I don't even make use of Keycloak.js.
> > It's just plain Angular.js for testing purposes.
> >
> > >
> > >
> > > -Matthias
> > >
> > >
> > > >
> > > > If you want to try
> > > >
> > https://github.com/abstractj/aerogear-unifiedpush-server/tree/angular-auth
> > > > .
> > > > Certainly is some missing detail during deployment, but that doesn't
> > > > work here, any idea about what's wrong is welcome.
> > > >
> > > > On 2014-06-02, Sebastien Blanc wrote:
> > > > > Yes,
> > > > >
> > > > > We are a bit in a transition phase with the complete overhaul of the
> > > > > console. The old readme is not enterily up to date and could be
> > > > confusing.
> > > > > This JIRA has been created to track this :
> > > > > https://issues.jboss.org/browse/AGPUSH-679
> > > > >
> > > > > @abstractj: in the mean time, you can follow the instructions that
> > Lukas
> > > > > pointed out.
> > > > >
> > > > > Sebi
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Mon, Jun 2, 2014 at 9:11 AM, Matthias Wessendorf <
> > matzew at apache.org>
> > > > > wrote:
> > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Fri, May 30, 2014 at 6:44 PM, Luk?? Fry? <lukas.fryc at gmail.com>
> > > > wrote:
> > > > > >
> > > > > >> Hey man,
> > > > > >>
> > > > > >> I can't find the instructions myself atm.
> > > > > >> (they could have been lost during merge (?))
> > > > > >>
> > > > > >
> > > > > > hrm, yeah - surprised to see the README is no longer around
> > > > > >
> > > > > >
> > > > > >
> > > > > >>
> > > > > >> I found this copy, which is almost up to date:
> > > > > >>
> > > > > >>
> > > >
> > https://github.com/lfryc/aerogear-unifiedpush-server/tree/master/admin-ui#using-with-jboss-eapwildfly
> > > > > >>
> > > > > >> Basically, run
> > > > > >>
> > > > > >> upload exploded ag-push.war/ to JBoss AS 7.1.
> > > > > >> $ cd admin-ui/
> > > > > >> $ grunt server
> > > > > >> modify generated local-config.json to point to that exploded war
> > > > > >> $ grunt server
> > > > > >>
> > > > > >> Hope it helps.
> > > > > >>
> > > > > >> Meanwhile, I will update the instructions in the master.
> > > > > >>
> > > > > >> Cheers,
> > > > > >>
> > > > > >> ~ Lukas
> > > > > >>
> > > > > >>
> > > > > >> On Fri, May 30, 2014 at 6:03 PM, Bruno Oliveira <
> > bruno at abstractj.org>
> > > > > >> wrote:
> > > > > >>
> > > > > >>> Good morning,
> > > > > >>>
> > > > > >>> I'm looking for instructions of how to build admin-ui correctly.
> > > > Where
> > > > > >>> could I find it?
> > > > > >>>
> > > > > >>> Currently I tried
> > > > > >>>
> > > > > >>>
> > > >
> > https://github.com/aerogear/aerogear-unifiedpush-server-admin-ui/blob/master/README.md
> > > > > >>> and also
> > > > > >>>
> > > > https://github.com/aerogear/collateral/wiki/UPS-Admin-Console-Process.
> > > > > >>> The reason why I want this is because Sebastien managed to get it
> > > > > >>> working
> > > > > >>>
> > > > > >>>
> > > >
> > https://github.com/abstractj/aerogear-unifiedpush-server/tree/angular-auth
> > > > > >>> and something very dirty might be happening with my environment.
> > > > > >>>
> > > > > >>> What I want to do is very simple. Trigger the following event:
> > > > > >>>
> > > > > >>>
> > > >
> > https://github.com/abstractj/aerogear-unifiedpush-server/commit/aeed989288ae0c42a8f163b303fb1d89a029b635#diff-bd44ccad477ae267b4939a7797ddc9eeR90
> > > > > >>> .
> > > > > >>>
> > > > > >>> I also tried to copy these files to server/src/main/webapp/ but
> > it
> > > > > >>> didnt'work.
> > > > > >>>
> > > > > >>> Thanks in advance.
> > > > > >>>
> > > > > >>> --
> > > > > >>>
> > > > > >>> abstractj
> > > > > >>> _______________________________________________
> > > > > >>> aerogear-dev mailing list
> > > > > >>> aerogear-dev at lists.jboss.org
> > > > > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > > > >>>
> > > > > >>
> > > > > >>
> > > > > >> _______________________________________________
> > > > > >> aerogear-dev mailing list
> > > > > >> aerogear-dev at lists.jboss.org
> > > > > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > > > >>
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Matthias Wessendorf
> > > > > >
> > > > > > blog: http://matthiaswessendorf.wordpress.com/
> > > > > > sessions: http://www.slideshare.net/mwessendorf
> > > > > > twitter: http://twitter.com/mwessendorf
> > > > > >
> > > > > > _______________________________________________
> > > > > > aerogear-dev mailing list
> > > > > > aerogear-dev at lists.jboss.org
> > > > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > > > >
> > > >
> > > > > _______________________________________________
> > > > > aerogear-dev mailing list
> > > > > aerogear-dev at lists.jboss.org
> > > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > >
> > > >
> > > > --
> > > >
> > > > abstractj
> > > > _______________________________________________
> > > > aerogear-dev mailing list
> > > > aerogear-dev at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > >
> > >
> > >
> > >
> > > --
> > > Matthias Wessendorf
> > >
> > > blog: http://matthiaswessendorf.wordpress.com/
> > > sessions: http://www.slideshare.net/mwessendorf
> > > twitter: http://twitter.com/mwessendorf
> >
> > > _______________________________________________
> > > aerogear-dev mailing list
> > > aerogear-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> >
> > --
> >
> > abstractj
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >

> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


--

abstractj

From scm.blanc at gmail.com  Wed Jun  4 03:47:35 2014
From: scm.blanc at gmail.com (Sebastien Blanc)
Date: Wed, 4 Jun 2014 09:47:35 +0200
Subject: [aerogear-dev] First go at stats/activity wireframes
In-Reply-To: <CAAg5f2Rne99mhV8p4Ux0mvvA2Fvir8EZe4aWkhDs_xwObyXw8Q@mail.gmail.com>
References: <5374DB1B.9020405@redhat.com> <53888A9D.8020308@redhat.com>
	<CAD_dpu2P3nW2pVPDd8HhJiBofDjqrmQ_W-6D1TC8H-WoaGQZFQ@mail.gmail.com>
	<CAAg5f2Rne99mhV8p4Ux0mvvA2Fvir8EZe4aWkhDs_xwObyXw8Q@mail.gmail.com>
Message-ID: <CAD_dpu3i3O7hXdLb=F-Q=NNiWRMJp2m7ffOLcc6qz1295UHU9A@mail.gmail.com>

On Sat, May 31, 2014 at 7:28 AM, Matthias Wessendorf <matzew at apache.org>
wrote:

> Awesome!
>
> Hylke, I marked your two tickets as resolved:
> https://issues.jboss.org/browse/AGPUSH-579
> https://issues.jboss.org/browse/AGPUSH-580
>
> @Sebi: I assigned this to you:
> https://issues.jboss.org/browse/AGPUSH-636
>

Finally, Erik will be starting on this and I will jump in later , here is
the branch he started to see the progress :
https://github.com/edewit/aerogear-unifiedpush-server/tree/stats


>
>
>
> On Fri, May 30, 2014 at 4:00 PM, Sebastien Blanc <scm.blanc at gmail.com>
> wrote:
>
>> Hey !
>>
>> Looks nice !
>> I will probably start integrating this on Monday.
>>
>> Sebi
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140604/99c5e550/attachment.html 

From daniel.bevenius at gmail.com  Wed Jun  4 05:23:18 2014
From: daniel.bevenius at gmail.com (danielbevenius)
Date: Wed, 4 Jun 2014 02:23:18 -0700 (PDT)
Subject: [aerogear-dev] contacts-mobile-basic quick start
In-Reply-To: <1401798729477-8072.post@n5.nabble.com>
References: <A7CCCFDE-F89A-4E8F-9C06-BD7BC1577259@gmail.com>
	<CAFJm-3FOidFs5D7ogThjO7mORtb5q55r8BRCcn9jNbjoiHFy6w@mail.gmail.com>
	<CAAg5f2Q536Zi1A=OvhFEmdcN_8jzd3uALJ4sbfUom89d3p5Pzw@mail.gmail.com>
	<CAFJm-3ES4VQL8=rBT22jKuo+6T-18AB4Oh=XP4p172o4fSLR1g@mail.gmail.com>
	<CAFJm-3H9-t1E--T+_ctZ7+YVpw2XVwByoHFm-hFSBZWTxMiQag@mail.gmail.com>
	<CAFJm-3Fxd8LR8eqhGTBzutpc_Tu+LsQ5VW+ANzrKaq0QnbBmZw@mail.gmail.com>
	<682680FC-677F-4566-8E2C-9392CEC4FC83@gmail.com>
	<1401776740005-8059.post@n5.nabble.com>
	<20140603103948.GD88786@abstractj.org>
	<1401798729477-8072.post@n5.nabble.com>
Message-ID: <1401873798566-8079.post@n5.nabble.com>

I've added a branch that contains the removed roles/signup in case we decide
to take that route:
https://github.com/danbev/jboss-wfk-quickstarts/tree/remove-roles

The branch above contains the three default users 'maria', 'john', and 'dan'
as discussed.

I've deployed the following OpenShift instance with this:
http://backend-dbevenius.rhcloud.com/jboss-contacts-mobile-picketlink-secured
http://webapp-dbevenius.rhcloud.com/jboss-contacts-mobile-webapp/#signin-page

Please note that there is a bug in when you don't use the '/#signin-page'
fragment. The issue is that there is an access denied error which returns
401, we check for this status and then try to transition/display the login
page but this does not work. I'll look into this. 

I've also deployed a proxy and a proxied-webapp but discovered pretty
quickly a bug that causes the proxy to fail. The issues is that the proxy is
not allow to bind a socket. I'll create a task for this and fix it.
http://proxy-dbevenius.rhcloud.com/jboss-contacts-mobile-picketlink-secured
http://proxiedwebapp-dbevenius.rhcloud.com/jboss-contacts-mobile-webapp/#signin-page






--
View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-contacts-mobile-basic-quick-start-tp7534p8079.html
Sent from the aerogear-dev mailing list archive at Nabble.com.

From daniel.bevenius at gmail.com  Wed Jun  4 05:32:17 2014
From: daniel.bevenius at gmail.com (danielbevenius)
Date: Wed, 4 Jun 2014 02:32:17 -0700 (PDT)
Subject: [aerogear-dev] contacts-mobile-basic quick start
In-Reply-To: <1401873798566-8079.post@n5.nabble.com>
References: <CAFJm-3FOidFs5D7ogThjO7mORtb5q55r8BRCcn9jNbjoiHFy6w@mail.gmail.com>
	<CAAg5f2Q536Zi1A=OvhFEmdcN_8jzd3uALJ4sbfUom89d3p5Pzw@mail.gmail.com>
	<CAFJm-3ES4VQL8=rBT22jKuo+6T-18AB4Oh=XP4p172o4fSLR1g@mail.gmail.com>
	<CAFJm-3H9-t1E--T+_ctZ7+YVpw2XVwByoHFm-hFSBZWTxMiQag@mail.gmail.com>
	<CAFJm-3Fxd8LR8eqhGTBzutpc_Tu+LsQ5VW+ANzrKaq0QnbBmZw@mail.gmail.com>
	<682680FC-677F-4566-8E2C-9392CEC4FC83@gmail.com>
	<1401776740005-8059.post@n5.nabble.com>
	<20140603103948.GD88786@abstractj.org>
	<1401798729477-8072.post@n5.nabble.com>
	<1401873798566-8079.post@n5.nabble.com>
Message-ID: <1401874337203-8080.post@n5.nabble.com>

Ticket for Fabric8 proxy issue:
https://github.com/fabric8io/fabric8/issues/1600



--
View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-contacts-mobile-basic-quick-start-tp7534p8080.html
Sent from the aerogear-dev mailing list archive at Nabble.com.

From kpiwko at redhat.com  Wed Jun  4 05:56:00 2014
From: kpiwko at redhat.com (Karel Piwko)
Date: Wed, 4 Jun 2014 11:56:00 +0200
Subject: [aerogear-dev] UPS admin-ui distribution compiled by
 frontend-maven-plugin
In-Reply-To: <CAAg5f2QMxEwbMK3MFXPhdahq2yP15=GkLbc3BSD+k8kHEuCTOg@mail.gmail.com>
References: <CAEroY35YqT=B6G4a4YAHS5t0hgdA=gtjXjvbfUrHVHJuAF+g9Q@mail.gmail.com>
	<20140602164035.03c2060e@kapy-ntb-x220>
	<CAAg5f2Srvm9DoWcY9MP451xqOw7B__9MMa0vNdE+pTNYgkTePQ@mail.gmail.com>
	<20140602173402.3896e648@kapy-ntb-x220>
	<CAAg5f2QMxEwbMK3MFXPhdahq2yP15=GkLbc3BSD+k8kHEuCTOg@mail.gmail.com>
Message-ID: <20140604115600.03437480@kapy-ntb-x220>

On Mon, 2 Jun 2014 17:55:43 +0200
Matthias Wessendorf <matzew at apache.org> wrote:
> >
> > Correct but the plugin would hide the fact there are two masters involved.> 
> 
> two masters? master in terms of git?

Exactly. Recently, I've noticed that UI has been merged to UPS repository, so
this would not be an issue any more. Two masters no more.

https://github.com/aerogear/aerogear-unifiedpush-server/tree/master/admin-ui

> 
> 
> > If
> > we had UI as <dependency> with version -SNAPSHOT in pom.xml, that's a
> > different
> > thing.
> >
> 
> as said earlier, I think Keycloak does that. But I am not sure on the
> details of the UI bundling
> 

KC has Angular as a part of regular Maven module:

https://github.com/keycloak/keycloak/tree/master/forms/common-themes

The problem here I'm presuming is a need to produce jar
of admin-ui, which means bringing Ant/Maven/Gradle/Grunt task
(maybe grunt-sync-jar) into current UI build.

From matzew at apache.org  Wed Jun  4 07:50:27 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Wed, 4 Jun 2014 13:50:27 +0200
Subject: [aerogear-dev] First go at stats/activity wireframes
In-Reply-To: <CAD_dpu3i3O7hXdLb=F-Q=NNiWRMJp2m7ffOLcc6qz1295UHU9A@mail.gmail.com>
References: <5374DB1B.9020405@redhat.com> <53888A9D.8020308@redhat.com>
	<CAD_dpu2P3nW2pVPDd8HhJiBofDjqrmQ_W-6D1TC8H-WoaGQZFQ@mail.gmail.com>
	<CAAg5f2Rne99mhV8p4Ux0mvvA2Fvir8EZe4aWkhDs_xwObyXw8Q@mail.gmail.com>
	<CAD_dpu3i3O7hXdLb=F-Q=NNiWRMJp2m7ffOLcc6qz1295UHU9A@mail.gmail.com>
Message-ID: <CAAg5f2TbvfDFMQuSwuMo3dA8WkPoxzegNhaH13nRdOuWjkW0Jw@mail.gmail.com>

On Wed, Jun 4, 2014 at 9:47 AM, Sebastien Blanc <scm.blanc at gmail.com> wrote:

>
>
>
> On Sat, May 31, 2014 at 7:28 AM, Matthias Wessendorf <matzew at apache.org>
> wrote:
>
>> Awesome!
>>
>> Hylke, I marked your two tickets as resolved:
>> https://issues.jboss.org/browse/AGPUSH-579
>> https://issues.jboss.org/browse/AGPUSH-580
>>
>> @Sebi: I assigned this to you:
>> https://issues.jboss.org/browse/AGPUSH-636
>>
>
> Finally, Erik will be starting on this and I will jump in later , here is
> the branch he started to see the progress :
> https://github.com/edewit/aerogear-unifiedpush-server/tree/stats
>

Ah, ok. Since we also got talked into some sort of Dashboard, I have
assigned AGPUSH-648 to Erik as well. Some parts of the server are already
there:
https://issues.jboss.org/browse/AGPUSH-650 (already merged)

And some more server-side work that is still open:
https://issues.jboss.org/browse/AGPUSH-651


>
>
>>
>>
>>
>> On Fri, May 30, 2014 at 4:00 PM, Sebastien Blanc <scm.blanc at gmail.com>
>> wrote:
>>
>>>  Hey !
>>>
>>> Looks nice !
>>> I will probably start integrating this on Monday.
>>>
>>> Sebi
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> sessions: http://www.slideshare.net/mwessendorf
>> twitter: http://twitter.com/mwessendorf
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140604/acfce72a/attachment-0001.html 

From daniel.bevenius at gmail.com  Wed Jun  4 11:06:26 2014
From: daniel.bevenius at gmail.com (danielbevenius)
Date: Wed, 4 Jun 2014 08:06:26 -0700 (PDT)
Subject: [aerogear-dev] contacts-mobile-basic quick start
In-Reply-To: <1401874337203-8080.post@n5.nabble.com>
References: <CAAg5f2Q536Zi1A=OvhFEmdcN_8jzd3uALJ4sbfUom89d3p5Pzw@mail.gmail.com>
	<CAFJm-3ES4VQL8=rBT22jKuo+6T-18AB4Oh=XP4p172o4fSLR1g@mail.gmail.com>
	<CAFJm-3H9-t1E--T+_ctZ7+YVpw2XVwByoHFm-hFSBZWTxMiQag@mail.gmail.com>
	<CAFJm-3Fxd8LR8eqhGTBzutpc_Tu+LsQ5VW+ANzrKaq0QnbBmZw@mail.gmail.com>
	<682680FC-677F-4566-8E2C-9392CEC4FC83@gmail.com>
	<1401776740005-8059.post@n5.nabble.com>
	<20140603103948.GD88786@abstractj.org>
	<1401798729477-8072.post@n5.nabble.com>
	<1401873798566-8079.post@n5.nabble.com>
	<1401874337203-8080.post@n5.nabble.com>
Message-ID: <1401894386127-8083.post@n5.nabble.com>

I've got the proxy working on OpenShift now:
http://proxiedwebapp-dbevenius.rhcloud.com/jboss-contacts-mobile-webapp/#signin-page

This might not require the fix to Fabric8 but I'll go through this more
closely tomorrow and sort it out. 



--
View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-contacts-mobile-basic-quick-start-tp7534p8083.html
Sent from the aerogear-dev mailing list archive at Nabble.com.

From tkriz at redhat.com  Wed Jun  4 12:18:35 2014
From: tkriz at redhat.com (Tadeas Kriz)
Date: Wed, 4 Jun 2014 18:18:35 +0200
Subject: [aerogear-dev] Direct access to UnifiedPush Server's REST without
	OAuth
Message-ID: <619DEA09-3D50-4EF8-8D91-99A8E076E597@redhat.com>

Hey guys,

as you might know, in the integration tests we only test the REST backend, making sure it works as intended. Before Keycloak, every action was achievable using the REST, that included login, logout and user management. We don?t need the user management for sure, but login and logout is an another story. Now with Keycloak anyone who wants to just use REST calls, still need to login using the Keycloak.

My question is, do we want users to be able to access the REST without OAuth? If we do, it would probably mean we need to have two Keycloak applications, one for the UI which would still use OAuth and second one for REST calls which would use Bearer only. This would also mean that when someone makes a REST call to an endpoint without being authorized, he would receive 401 response, instead of 302 redirect (before Keycloak, the response was 401 in case of unauthorized access).

What do you think?

?
Tadeas Kriz



From matzew at apache.org  Wed Jun  4 15:19:30 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Wed, 4 Jun 2014 21:19:30 +0200
Subject: [aerogear-dev] Java Sender 0.7.0 has been staged (was: Re:
 Java-Sender release?)
In-Reply-To: <CAAg5f2TUssYY=tD-xnjZQmN1eJP3-nBL+MCGXXbSqupqgRvF3A@mail.gmail.com>
References: <CAAg5f2TUssYY=tD-xnjZQmN1eJP3-nBL+MCGXXbSqupqgRvF3A@mail.gmail.com>
Message-ID: <CAAg5f2R9fHMnnKUGrJvwOvn-2L4hL1eT82p1FB8qUDEuL3M94A@mail.gmail.com>

released to maven central - should be available by tomorrow


On Tue, Jun 3, 2014 at 9:15 AM, Matthias Wessendorf <matzew at apache.org>
wrote:

> Hello,
>
> the version 0.7.0 of the Java Sender has been staged. The staging
> repository is located here:
>
> http://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3338/
>
> Changes since the last release:
> * BOM and AeroGear-Parent update
> * Java client: submit request header on sending (AGPUSH-682)
> * Switching to com.fasterxml.jackson
> * Refactoring of SenderClient and JavaSender
>
> If nothing bad has been reported, I will release the bits by Thursday
> afternoon (EU time)
>
> Cheers!
> Matthias
>
>
> On Tue, Jun 3, 2014 at 8:57 AM, Matthias Wessendorf <matzew at apache.org>
> wrote:
>
>> that's already in :-)
>>
>>
>> On Tue, Jun 3, 2014 at 8:50 AM, Sebastien Blanc <scm.blanc at gmail.com>
>> wrote:
>>
>>> I was thinking the same, I would like to include
>>> https://github.com/aerogear/aerogear-unifiedpush-java-client/pull/39
>>> and https://github.com/aerogear/aerogear-unifiedpush-java-client/pull/40
>>>
>>>
>>> On Tue, Jun 3, 2014 at 8:49 AM, Matthias Wessendorf <matzew at apache.org>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> based on recent changes, I think it's good time to release the client
>>>> version 0.7.0.
>>>>
>>>> Any concerns against such a release ?
>>>>
>>>> --
>>>> Matthias Wessendorf
>>>>
>>>> blog: http://matthiaswessendorf.wordpress.com/
>>>> sessions: http://www.slideshare.net/mwessendorf
>>>> twitter: http://twitter.com/mwessendorf
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> sessions: http://www.slideshare.net/mwessendorf
>> twitter: http://twitter.com/mwessendorf
>>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140604/0d8e2fe4/attachment.html 

From matzew at apache.org  Wed Jun  4 15:19:55 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Wed, 4 Jun 2014 21:19:55 +0200
Subject: [aerogear-dev] UnifiedPush 0.10.4 - release coming soon (Maven
	Central and OpenShift)
In-Reply-To: <CAAg5f2T5rc+_TV4pcpFXh2M+SLsywL22SB1XpJGjHMbaHF22CA@mail.gmail.com>
References: <CAAg5f2T5rc+_TV4pcpFXh2M+SLsywL22SB1XpJGjHMbaHF22CA@mail.gmail.com>
Message-ID: <CAAg5f2R2stDaAsF-2GOKb0r_XFXvx9u7=9xbN_9Pe1uam9foqA@mail.gmail.com>

released to maven central - should be available by tomorrow
OpenShift merge will follow once the bits are on maven central


On Tue, Jun 3, 2014 at 10:36 AM, Matthias Wessendorf <matzew at apache.org>
wrote:

> Hello,
>
> as disscussed in our IRC meeting yesterday, I ran the release for the
> 0.10.4 version of UPS.
>
> The staging repository is located here:
>
> http://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3340/
>
> I sent a PR for our OpenShift offerings:
>
> https://github.com/aerogear/openshift-origin-cartridge-aerogear-push/pull/15
>
>
> If you want to test it - it's simple! Just go ahead and use my fork of the
> repo:
> rhc app create --no-git <YOUR COOL APP NAME>
> https://cartreflect-claytondev.rhcloud.com/reflect?github=matzew/openshift-origin-cartridge-aerogear-push
>  mysql-5.5
>
> The change log of the server:
>
> * AGPUSH-642
> * AGPUSH-643
> * AGPUSH-687
>
> Let me know the results of your testing;
> If I hear nothing bad by Wednesday evening, the merges (and release to
> maven central) will happen on Thursday;
>
>
> Cheers,
> Matthias
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140604/490940f1/attachment.html 

From keith at kdmooreconsulting.com  Wed Jun  4 16:40:07 2014
From: keith at kdmooreconsulting.com (keithdmoore94)
Date: Wed, 4 Jun 2014 13:40:07 -0700 (PDT)
Subject: [aerogear-dev] UnifiedPush 0.10.4 - release coming soon (Maven
 Central and OpenShift)
In-Reply-To: <CAAg5f2T5rc+_TV4pcpFXh2M+SLsywL22SB1XpJGjHMbaHF22CA@mail.gmail.com>
References: <CAAg5f2T5rc+_TV4pcpFXh2M+SLsywL22SB1XpJGjHMbaHF22CA@mail.gmail.com>
Message-ID: <1401914407646-8087.post@n5.nabble.com>

FYI...I'm sure its just an accounting thing but AGPUSH-643 still has a status
of unresolved.



--
View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-UnifiedPush-0-10-4-release-coming-soon-Maven-Central-and-OpenShift-tp8066p8087.html
Sent from the aerogear-dev mailing list archive at Nabble.com.

From matzew at apache.org  Wed Jun  4 16:57:35 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Wed, 4 Jun 2014 22:57:35 +0200
Subject: [aerogear-dev] UnifiedPush 0.10.4 - release coming soon (Maven
 Central and OpenShift)
In-Reply-To: <1401914407646-8087.post@n5.nabble.com>
References: <CAAg5f2T5rc+_TV4pcpFXh2M+SLsywL22SB1XpJGjHMbaHF22CA@mail.gmail.com>
	<1401914407646-8087.post@n5.nabble.com>
Message-ID: <CAAg5f2T1pmfYpD_dFTh5JdDxZGj3+3563mb6v7ynqscpzX9arw@mail.gmail.com>

Oh, :-)

I forgot to click the button - fixed :)

thanks for the heads-up!


On Wed, Jun 4, 2014 at 10:40 PM, keithdmoore94 <keith at kdmooreconsulting.com>
wrote:

> FYI...I'm sure its just an accounting thing but AGPUSH-643 still has a
> status
> of unresolved.
>
>
>
> --
> View this message in context:
> http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-UnifiedPush-0-10-4-release-coming-soon-Maven-Central-and-OpenShift-tp8066p8087.html
> Sent from the aerogear-dev mailing list archive at Nabble.com.
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140604/46054e64/attachment.html 

From matzew at apache.org  Thu Jun  5 04:47:21 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Thu, 5 Jun 2014 10:47:21 +0200
Subject: [aerogear-dev] Direct access to UnifiedPush Server's REST
	without OAuth
In-Reply-To: <619DEA09-3D50-4EF8-8D91-99A8E076E597@redhat.com>
References: <619DEA09-3D50-4EF8-8D91-99A8E076E597@redhat.com>
Message-ID: <CAAg5f2QxJVUa-Y76VKoPm=NnYZqx1TJxNCXWGc+G9ugcrjH1NA@mail.gmail.com>

On Wed, Jun 4, 2014 at 6:18 PM, Tadeas Kriz <tkriz at redhat.com> wrote:

> Hey guys,
>
> as you might know, in the integration tests we only test the REST backend,
> making sure it works as intended. Before Keycloak, every action was
> achievable using the REST, that included login, logout and user management.
> We don?t need the user management for sure, but login and logout is an
> another story. Now with Keycloak anyone who wants to just use REST calls,
> still need to login using the Keycloak.
>
> My question is, do we want users to be able to access the REST without
> OAuth? If we do, it would probably mean we need to have two Keycloak
> applications,


What do you mean here? Are you suggestion two WAR files (for each 'keycloak
application') ? Or just more a declarative setup?


> one for the UI which would still use OAuth and second one for REST calls
> which would use Bearer only. This would also mean that when someone makes a
> REST call to an endpoint without being authorized, he would receive 401
> response, instead of 302 redirect (before Keycloak, the response was 401 in
> case of unauthorized access).
>

yeah, I think the RESTful APIs behind the 'AdminUI' for the
'application/variant management' should continue to work. (I doubt there is
much usage of those outside of the AdminUI)


> What do you think?
>
> ?
> Tadeas Kriz
>
>


-- 
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-dev/attachments/20140605/a61621c3/attachment-0001.html 

From daniel.bevenius at gmail.com  Thu Jun  5 05:40:19 2014
From: daniel.bevenius at gmail.com (danielbevenius)
Date: Thu, 5 Jun 2014 02:40:19 -0700 (PDT)
Subject: [aerogear-dev] contacts-mobile-basic quick start
In-Reply-To: <1401894386127-8083.post@n5.nabble.com>
References: <CAFJm-3ES4VQL8=rBT22jKuo+6T-18AB4Oh=XP4p172o4fSLR1g@mail.gmail.com>
	<CAFJm-3H9-t1E--T+_ctZ7+YVpw2XVwByoHFm-hFSBZWTxMiQag@mail.gmail.com>
	<CAFJm-3Fxd8LR8eqhGTBzutpc_Tu+LsQ5VW+ANzrKaq0QnbBmZw@mail.gmail.com>
	<682680FC-677F-4566-8E2C-9392CEC4FC83@gmail.com>
	<1401776740005-8059.post@n5.nabble.com>
	<20140603103948.GD88786@abstractj.org>
	<1401798729477-8072.post@n5.nabble.com>
	<1401873798566-8079.post@n5.nabble.com>
	<1401874337203-8080.post@n5.nabble.com>
	<1401894386127-8083.post@n5.nabble.com>
Message-ID: <1401961219970-8090.post@n5.nabble.com>

The previous Fabric8 issue was deleted as it was not what we needed in the
end. This one was filed instead:
https://github.com/fabric8io/fabric8/issues/1631

Erik reported an issue yesterday regarding the error "Multiple
Access-Control-Allow-Origin headers are not allowed for CORS response" when
accessing:
http://webapp-dbevenius.rhcloud.com/jboss-contacts-mobile-webapp

I've added a workaround for this with the following commit:
https://github.com/danbev/jboss-wfk-quickstarts/commit/24f03ca626aa302ad16efeae5d8a3621b6f351ab
This has been deployed and I also believe that this might have caused the
navigation to the signin-page to malfunction before. At least I'm not seeing
this error anymore. Please let me know if do see that issue and I'll take a
closer look at it. 







--
View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-contacts-mobile-basic-quick-start-tp7534p8090.html
Sent from the aerogear-dev mailing list archive at Nabble.com.

From kpiwko at redhat.com  Thu Jun  5 07:47:34 2014
From: kpiwko at redhat.com (Karel Piwko)
Date: Thu, 5 Jun 2014 13:47:34 +0200
Subject: [aerogear-dev] UnifiedPush 0.10.4 - release coming soon (Maven
 Central and OpenShift)
In-Reply-To: <CAAg5f2R2stDaAsF-2GOKb0r_XFXvx9u7=9xbN_9Pe1uam9foqA@mail.gmail.com>
References: <CAAg5f2T5rc+_TV4pcpFXh2M+SLsywL22SB1XpJGjHMbaHF22CA@mail.gmail.com>
	<CAAg5f2R2stDaAsF-2GOKb0r_XFXvx9u7=9xbN_9Pe1uam9foqA@mail.gmail.com>
Message-ID: <20140605134734.56e21c95@kapy-ntb-x220>

I bit too late to the party but:

* integration tests are passing
* admin UI tests are passing
* cartridge tests are passing

Happy sync to Maven Central ;-)

Karel

On Wed, 4 Jun 2014 21:19:55 +0200
Matthias Wessendorf <matzew at apache.org> wrote:

> released to maven central - should be available by tomorrow
> OpenShift merge will follow once the bits are on maven central
> 
> 
> On Tue, Jun 3, 2014 at 10:36 AM, Matthias Wessendorf <matzew at apache.org>
> wrote:
> 
> > Hello,
> >
> > as disscussed in our IRC meeting yesterday, I ran the release for the
> > 0.10.4 version of UPS.
> >
> > The staging repository is located here:
> >
> > http://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3340/
> >
> > I sent a PR for our OpenShift offerings:
> >
> > https://github.com/aerogear/openshift-origin-cartridge-aerogear-push/pull/15
> >
> >
> > If you want to test it - it's simple! Just go ahead and use my fork of the
> > repo:
> > rhc app create --no-git <YOUR COOL APP NAME>
> > https://cartreflect-claytondev.rhcloud.com/reflect?github=matzew/openshift-origin-cartridge-aerogear-push
> >  mysql-5.5
> >
> > The change log of the server:
> >
> > * AGPUSH-642
> > * AGPUSH-643
> > * AGPUSH-687
> >
> > Let me know the results of your testing;
> > If I hear nothing bad by Wednesday evening, the merges (and release to
> > maven central) will happen on Thursday;
> >
> >
> > Cheers,
> > Matthias
> >
> >
> > --
> > Matthias Wessendorf
> >
> > blog: http://matthiaswessendorf.wordpress.com/
> > sessions: http://www.slideshare.net/mwessendorf
> > twitter: http://twitter.com/mwessendorf
> >
> 
> 
> 


From bruno at abstractj.org  Thu Jun  5 08:08:46 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Thu, 5 Jun 2014 09:08:46 -0300
Subject: [aerogear-dev] Direct access to UnifiedPush Server's REST
 without OAuth
In-Reply-To: <CAAg5f2QxJVUa-Y76VKoPm=NnYZqx1TJxNCXWGc+G9ugcrjH1NA@mail.gmail.com>
References: <619DEA09-3D50-4EF8-8D91-99A8E076E597@redhat.com>
	<CAAg5f2QxJVUa-Y76VKoPm=NnYZqx1TJxNCXWGc+G9ugcrjH1NA@mail.gmail.com>
Message-ID: <20140605120846.GA59625@abstractj.org>

On 2014-06-05, Matthias Wessendorf wrote:
> On Wed, Jun 4, 2014 at 6:18 PM, Tadeas Kriz <tkriz at redhat.com> wrote:
>
> > Hey guys,
> >
> > as you might know, in the integration tests we only test the REST backend,
> > making sure it works as intended. Before Keycloak, every action was
> > achievable using the REST, that included login, logout and user management.
> > We don?t need the user management for sure, but login and logout is an
> > another story. Now with Keycloak anyone who wants to just use REST calls,
> > still need to login using the Keycloak.
> >
> > My question is, do we want users to be able to access the REST without
> > OAuth? If we do, it would probably mean we need to have two Keycloak
> > applications,
>
>
> What do you mean here? Are you suggestion two WAR files (for each 'keycloak
> application') ? Or just more a declarative setup?

I think what Tadeas means is pretty much in the context of KC
configuration file
https://github.com/keycloak/keycloak/blob/master/examples/demo-template/testrealm.json#L90

>
>
> > one for the UI which would still use OAuth and second one for REST calls
> > which would use Bearer only. This would also mean that when someone makes a
> > REST call to an endpoint without being authorized, he would receive 401
> > response, instead of 302 redirect (before Keycloak, the response was 401 in
> > case of unauthorized access).
> >
>
> yeah, I think the RESTful APIs behind the 'AdminUI' for the
> 'application/variant management' should continue to work. (I doubt there is
> much usage of those outside of the AdminUI)

As far as I can tell if that is really required, we need to include a
public client for REST.

>
>
> > What do you think?
> >
> > ?
> > Tadeas Kriz
> >
> >
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf

> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


--

abstractj

From stian at redhat.com  Thu Jun  5 08:14:05 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 5 Jun 2014 08:14:05 -0400 (EDT)
Subject: [aerogear-dev] Direct access to UnifiedPush Server's
	REST	without OAuth
In-Reply-To: <CAAg5f2QxJVUa-Y76VKoPm=NnYZqx1TJxNCXWGc+G9ugcrjH1NA@mail.gmail.com>
References: <619DEA09-3D50-4EF8-8D91-99A8E076E597@redhat.com>
	<CAAg5f2QxJVUa-Y76VKoPm=NnYZqx1TJxNCXWGc+G9ugcrjH1NA@mail.gmail.com>
Message-ID: <691192050.20885964.1401970445848.JavaMail.zimbra@redhat.com>

As I suggested this, I'll add a bit more information.

It makes sense to have two applications for UPS in Keycloak:

1) A bearer-only application for the REST endpoints - this application does not allow logins and hence won't redirect to login screens, but return 401/403. It will authenticate through the bearer token passed in the headers. Any roles for UPS should be created for this application. Also, the KC adapter (BootstrapListener) is configured for this application, as that secures the REST endpoints
2) A public application for the Admin Console - this applications allows logins. This should have scope mappings on roles in the application above. This is used for the JS console, and I would recommend using keycloak.js.

----- Original Message -----
> From: "Matthias Wessendorf" <matzew at apache.org>
> To: "Tadeas Kriz" <tkriz at redhat.com>
> Cc: "AeroGear Developer Mailing List" <aerogear-dev at lists.jboss.org>
> Sent: Thursday, 5 June, 2014 9:47:21 AM
> Subject: Re: [aerogear-dev] Direct access to UnifiedPush Server's REST	without OAuth
> 
> 
> 
> 
> On Wed, Jun 4, 2014 at 6:18 PM, Tadeas Kriz < tkriz at redhat.com > wrote:
> 
> 
> Hey guys,
> 
> as you might know, in the integration tests we only test the REST backend,
> making sure it works as intended. Before Keycloak, every action was
> achievable using the REST, that included login, logout and user management.
> We don?t need the user management for sure, but login and logout is an
> another story. Now with Keycloak anyone who wants to just use REST calls,
> still need to login using the Keycloak.
> 
> My question is, do we want users to be able to access the REST without OAuth?
> If we do, it would probably mean we need to have two Keycloak applications,
> 
> What do you mean here? Are you suggestion two WAR files (for each 'keycloak
> application') ? Or just more a declarative setup?
> 
> 
> one for the UI which would still use OAuth and second one for REST calls
> which would use Bearer only. This would also mean that when someone makes a
> REST call to an endpoint without being authorized, he would receive 401
> response, instead of 302 redirect (before Keycloak, the response was 401 in
> case of unauthorized access).
> 
> yeah, I think the RESTful APIs behind the 'AdminUI' for the
> 'application/variant management' should continue to work. (I doubt there is
> much usage of those outside of the AdminUI)
> 
> 
> 
> 
> What do you think?
> 
> ?
> Tadeas Kriz
> 
> 
> 
> 
> --
> Matthias Wessendorf
> 
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
> 
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


From bruno at abstractj.org  Thu Jun  5 09:07:25 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Thu, 5 Jun 2014 10:07:25 -0300
Subject: [aerogear-dev] Direct access to UnifiedPush Server's REST
 without OAuth
In-Reply-To: <691192050.20885964.1401970445848.JavaMail.zimbra@redhat.com>
References: <619DEA09-3D50-4EF8-8D91-99A8E076E597@redhat.com>
	<CAAg5f2QxJVUa-Y76VKoPm=NnYZqx1TJxNCXWGc+G9ugcrjH1NA@mail.gmail.com>
	<691192050.20885964.1401970445848.JavaMail.zimbra@redhat.com>
Message-ID: <20140605130725.GA61581@abstractj.org>


Thank you Stian.

@tkriz @matzew Atm I'm working on the item 2 from Stian's comments, as
soon as I get admin-ui integrated with keycloak.js. Once the integration
is finished I can look at item 1 ? IMO not a top priority ATM, because
it only affects cURL.

Correct me if I'm wrong.

On 2014-06-05, Stian Thorgersen wrote:
> As I suggested this, I'll add a bit more information.
>
> It makes sense to have two applications for UPS in Keycloak:
>
> 1) A bearer-only application for the REST endpoints - this application does not allow logins and hence won't redirect to login screens, but return 401/403. It will authenticate through the bearer token passed in the headers. Any roles for UPS should be created for this application. Also, the KC adapter (BootstrapListener) is configured for this application, as that secures the REST endpoints
> 2) A public application for the Admin Console - this applications allows logins. This should have scope mappings on roles in the application above. This is used for the JS console, and I would recommend using keycloak.js.
>
> ----- Original Message -----
> > From: "Matthias Wessendorf" <matzew at apache.org>
> > To: "Tadeas Kriz" <tkriz at redhat.com>
> > Cc: "AeroGear Developer Mailing List" <aerogear-dev at lists.jboss.org>
> > Sent: Thursday, 5 June, 2014 9:47:21 AM
> > Subject: Re: [aerogear-dev] Direct access to UnifiedPush Server's REST	without OAuth
> >
> >
> >
> >
> > On Wed, Jun 4, 2014 at 6:18 PM, Tadeas Kriz < tkriz at redhat.com > wrote:
> >
> >
> > Hey guys,
> >
> > as you might know, in the integration tests we only test the REST backend,
> > making sure it works as intended. Before Keycloak, every action was
> > achievable using the REST, that included login, logout and user management.
> > We don?t need the user management for sure, but login and logout is an
> > another story. Now with Keycloak anyone who wants to just use REST calls,
> > still need to login using the Keycloak.
> >
> > My question is, do we want users to be able to access the REST without OAuth?
> > If we do, it would probably mean we need to have two Keycloak applications,
> >
> > What do you mean here? Are you suggestion two WAR files (for each 'keycloak
> > application') ? Or just more a declarative setup?
> >
> >
> > one for the UI which would still use OAuth and second one for REST calls
> > which would use Bearer only. This would also mean that when someone makes a
> > REST call to an endpoint without being authorized, he would receive 401
> > response, instead of 302 redirect (before Keycloak, the response was 401 in
> > case of unauthorized access).
> >
> > yeah, I think the RESTful APIs behind the 'AdminUI' for the
> > 'application/variant management' should continue to work. (I doubt there is
> > much usage of those outside of the AdminUI)
> >
> >
> >
> >
> > What do you think?
> >
> > ?
> > Tadeas Kriz
> >
> >
> >
> >
> > --
> > Matthias Wessendorf
> >
> > blog: http://matthiaswessendorf.wordpress.com/
> > sessions: http://www.slideshare.net/mwessendorf
> > twitter: http://twitter.com/mwessendorf
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev

--

abstractj

From matzew at apache.org  Thu Jun  5 09:08:57 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Thu, 5 Jun 2014 15:08:57 +0200
Subject: [aerogear-dev] Direct access to UnifiedPush Server's REST
	without OAuth
In-Reply-To: <691192050.20885964.1401970445848.JavaMail.zimbra@redhat.com>
References: <619DEA09-3D50-4EF8-8D91-99A8E076E597@redhat.com>
	<CAAg5f2QxJVUa-Y76VKoPm=NnYZqx1TJxNCXWGc+G9ugcrjH1NA@mail.gmail.com>
	<691192050.20885964.1401970445848.JavaMail.zimbra@redhat.com>
Message-ID: <CAAg5f2S00K0=GX-dZcEGr6_9V0jUbeo17uz2UVtcR8qQHBCvtg@mail.gmail.com>

On Thu, Jun 5, 2014 at 2:14 PM, Stian Thorgersen <stian at redhat.com> wrote:

> As I suggested this, I'll add a bit more information.
>
> It makes sense to have two applications for UPS in Keycloak:
>
> 1) A bearer-only application for the REST endpoints - this application
> does not allow logins and hence won't redirect to login screens, but return
> 401/403. It will authenticate through the bearer token passed in the
> headers.


that would work just fine w/ curl, I think



> Any roles for UPS should be created for this application. Also, the KC
> adapter (BootstrapListener) is configured for this application, as that
> secures the REST endpoints
>

makes sense


> 2) A public application for the Admin Console - this applications allows
> logins. This should have scope mappings on roles in the application above.
> This is used for the JS console, and I would recommend using keycloak.js.
>

abstractj is already on kc.js :-)


>
> ----- Original Message -----
> > From: "Matthias Wessendorf" <matzew at apache.org>
> > To: "Tadeas Kriz" <tkriz at redhat.com>
> > Cc: "AeroGear Developer Mailing List" <aerogear-dev at lists.jboss.org>
> > Sent: Thursday, 5 June, 2014 9:47:21 AM
> > Subject: Re: [aerogear-dev] Direct access to UnifiedPush Server's REST
>      without OAuth
> >
> >
> >
> >
> > On Wed, Jun 4, 2014 at 6:18 PM, Tadeas Kriz < tkriz at redhat.com > wrote:
> >
> >
> > Hey guys,
> >
> > as you might know, in the integration tests we only test the REST
> backend,
> > making sure it works as intended. Before Keycloak, every action was
> > achievable using the REST, that included login, logout and user
> management.
> > We don?t need the user management for sure, but login and logout is an
> > another story. Now with Keycloak anyone who wants to just use REST calls,
> > still need to login using the Keycloak.
> >
> > My question is, do we want users to be able to access the REST without
> OAuth?
> > If we do, it would probably mean we need to have two Keycloak
> applications,
> >
> > What do you mean here? Are you suggestion two WAR files (for each
> 'keycloak
> > application') ? Or just more a declarative setup?
> >
> >
> > one for the UI which would still use OAuth and second one for REST calls
> > which would use Bearer only. This would also mean that when someone
> makes a
> > REST call to an endpoint without being authorized, he would receive 401
> > response, instead of 302 redirect (before Keycloak, the response was 401
> in
> > case of unauthorized access).
> >
> > yeah, I think the RESTful APIs behind the 'AdminUI' for the
> > 'application/variant management' should continue to work. (I doubt there
> is
> > much usage of those outside of the AdminUI)
> >
> >
> >
> >
> > What do you think?
> >
> > ?
> > Tadeas Kriz
> >
> >
> >
> >
> > --
> > Matthias Wessendorf
> >
> > blog: http://matthiaswessendorf.wordpress.com/
> > sessions: http://www.slideshare.net/mwessendorf
> > twitter: http://twitter.com/mwessendorf
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140605/64dcc64b/attachment-0001.html 

From matzew at apache.org  Thu Jun  5 09:09:56 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Thu, 5 Jun 2014 15:09:56 +0200
Subject: [aerogear-dev] Direct access to UnifiedPush Server's REST
	without OAuth
In-Reply-To: <20140605130725.GA61581@abstractj.org>
References: <619DEA09-3D50-4EF8-8D91-99A8E076E597@redhat.com>
	<CAAg5f2QxJVUa-Y76VKoPm=NnYZqx1TJxNCXWGc+G9ugcrjH1NA@mail.gmail.com>
	<691192050.20885964.1401970445848.JavaMail.zimbra@redhat.com>
	<20140605130725.GA61581@abstractj.org>
Message-ID: <CAAg5f2Rs+72531GxCWwzvgBLO1pRz=6mT8xPYROygYEnWSqS8w@mail.gmail.com>

On Thu, Jun 5, 2014 at 3:07 PM, Bruno Oliveira <bruno at abstractj.org> wrote:

>
> Thank you Stian.
>
> @tkriz @matzew Atm I'm working on the item 2 from Stian's comments, as
> soon as I get admin-ui integrated with keycloak.js. Once the integration
> is finished I can look at item 1 ? IMO not a top priority ATM, because
> it only affects cURL.
>
> Correct me if I'm wrong.
>

correct - and the QE test-suite.

I am fine in doing that close to 1.0.0 or even for 1.0.1 (depending on how
busy the July will be)

Makes sense ?





>
> On 2014-06-05, Stian Thorgersen wrote:
> > As I suggested this, I'll add a bit more information.
> >
> > It makes sense to have two applications for UPS in Keycloak:
> >
> > 1) A bearer-only application for the REST endpoints - this application
> does not allow logins and hence won't redirect to login screens, but return
> 401/403. It will authenticate through the bearer token passed in the
> headers. Any roles for UPS should be created for this application. Also,
> the KC adapter (BootstrapListener) is configured for this application, as
> that secures the REST endpoints
> > 2) A public application for the Admin Console - this applications allows
> logins. This should have scope mappings on roles in the application above.
> This is used for the JS console, and I would recommend using keycloak.js.
> >
> > ----- Original Message -----
> > > From: "Matthias Wessendorf" <matzew at apache.org>
> > > To: "Tadeas Kriz" <tkriz at redhat.com>
> > > Cc: "AeroGear Developer Mailing List" <aerogear-dev at lists.jboss.org>
> > > Sent: Thursday, 5 June, 2014 9:47:21 AM
> > > Subject: Re: [aerogear-dev] Direct access to UnifiedPush Server's REST
>      without OAuth
> > >
> > >
> > >
> > >
> > > On Wed, Jun 4, 2014 at 6:18 PM, Tadeas Kriz < tkriz at redhat.com >
> wrote:
> > >
> > >
> > > Hey guys,
> > >
> > > as you might know, in the integration tests we only test the REST
> backend,
> > > making sure it works as intended. Before Keycloak, every action was
> > > achievable using the REST, that included login, logout and user
> management.
> > > We don?t need the user management for sure, but login and logout is an
> > > another story. Now with Keycloak anyone who wants to just use REST
> calls,
> > > still need to login using the Keycloak.
> > >
> > > My question is, do we want users to be able to access the REST without
> OAuth?
> > > If we do, it would probably mean we need to have two Keycloak
> applications,
> > >
> > > What do you mean here? Are you suggestion two WAR files (for each
> 'keycloak
> > > application') ? Or just more a declarative setup?
> > >
> > >
> > > one for the UI which would still use OAuth and second one for REST
> calls
> > > which would use Bearer only. This would also mean that when someone
> makes a
> > > REST call to an endpoint without being authorized, he would receive 401
> > > response, instead of 302 redirect (before Keycloak, the response was
> 401 in
> > > case of unauthorized access).
> > >
> > > yeah, I think the RESTful APIs behind the 'AdminUI' for the
> > > 'application/variant management' should continue to work. (I doubt
> there is
> > > much usage of those outside of the AdminUI)
> > >
> > >
> > >
> > >
> > > What do you think?
> > >
> > > ?
> > > Tadeas Kriz
> > >
> > >
> > >
> > >
> > > --
> > > Matthias Wessendorf
> > >
> > > blog: http://matthiaswessendorf.wordpress.com/
> > > sessions: http://www.slideshare.net/mwessendorf
> > > twitter: http://twitter.com/mwessendorf
> > >
> > > _______________________________________________
> > > aerogear-dev mailing list
> > > aerogear-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
> --
>
> abstractj
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140605/fccb4a28/attachment.html 

From tkriz at redhat.com  Thu Jun  5 09:16:36 2014
From: tkriz at redhat.com (Tadeas Kriz)
Date: Thu, 5 Jun 2014 15:16:36 +0200
Subject: [aerogear-dev] Direct access to UnifiedPush Server's REST
	without OAuth
In-Reply-To: <CAAg5f2Rs+72531GxCWwzvgBLO1pRz=6mT8xPYROygYEnWSqS8w@mail.gmail.com>
References: <619DEA09-3D50-4EF8-8D91-99A8E076E597@redhat.com>
	<CAAg5f2QxJVUa-Y76VKoPm=NnYZqx1TJxNCXWGc+G9ugcrjH1NA@mail.gmail.com>
	<691192050.20885964.1401970445848.JavaMail.zimbra@redhat.com>
	<20140605130725.GA61581@abstractj.org>
	<CAAg5f2Rs+72531GxCWwzvgBLO1pRz=6mT8xPYROygYEnWSqS8w@mail.gmail.com>
Message-ID: <1F52E76B-53FE-4B0A-9978-401E4A4D943C@redhat.com>


?
Tadeas Kriz

On 05 Jun 2014, at 15:09, Matthias Wessendorf <matzew at apache.org> wrote:

> 
> 
> 
> On Thu, Jun 5, 2014 at 3:07 PM, Bruno Oliveira <bruno at abstractj.org> wrote:
> 
> Thank you Stian.
> 
> @tkriz @matzew Atm I'm working on the item 2 from Stian's comments, as
> soon as I get admin-ui integrated with keycloak.js. Once the integration
> is finished I can look at item 1 ? IMO not a top priority ATM, because
> it only affects cURL.
> 
> Correct me if I'm wrong.
> 
> correct - and the QE test-suite.
> 
> I am fine in doing that close to 1.0.0 or even for 1.0.1 (depending on how busy the July will be)
> 
> Makes sense ? 
> 
> 

I think it does make sense for the 1.0.0. In the integration tests we are able to replace the configuration required for the tests to work and authorize so we don?t have to rewrite it to check for 302 now and then rewrite it back to check for 401 when it?s fixed. I?ll just add some comments about this into the integration tests so it?s documented.

> 
>  
> 
> On 2014-06-05, Stian Thorgersen wrote:
> > As I suggested this, I'll add a bit more information.
> >
> > It makes sense to have two applications for UPS in Keycloak:
> >
> > 1) A bearer-only application for the REST endpoints - this application does not allow logins and hence won't redirect to login screens, but return 401/403. It will authenticate through the bearer token passed in the headers. Any roles for UPS should be created for this application. Also, the KC adapter (BootstrapListener) is configured for this application, as that secures the REST endpoints
> > 2) A public application for the Admin Console - this applications allows logins. This should have scope mappings on roles in the application above. This is used for the JS console, and I would recommend using keycloak.js.
> >
> > ----- Original Message -----
> > > From: "Matthias Wessendorf" <matzew at apache.org>
> > > To: "Tadeas Kriz" <tkriz at redhat.com>
> > > Cc: "AeroGear Developer Mailing List" <aerogear-dev at lists.jboss.org>
> > > Sent: Thursday, 5 June, 2014 9:47:21 AM
> > > Subject: Re: [aerogear-dev] Direct access to UnifiedPush Server's REST      without OAuth
> > >
> > >
> > >
> > >
> > > On Wed, Jun 4, 2014 at 6:18 PM, Tadeas Kriz < tkriz at redhat.com > wrote:
> > >
> > >
> > > Hey guys,
> > >
> > > as you might know, in the integration tests we only test the REST backend,
> > > making sure it works as intended. Before Keycloak, every action was
> > > achievable using the REST, that included login, logout and user management.
> > > We don?t need the user management for sure, but login and logout is an
> > > another story. Now with Keycloak anyone who wants to just use REST calls,
> > > still need to login using the Keycloak.
> > >
> > > My question is, do we want users to be able to access the REST without OAuth?
> > > If we do, it would probably mean we need to have two Keycloak applications,
> > >
> > > What do you mean here? Are you suggestion two WAR files (for each 'keycloak
> > > application') ? Or just more a declarative setup?
> > >
> > >
> > > one for the UI which would still use OAuth and second one for REST calls
> > > which would use Bearer only. This would also mean that when someone makes a
> > > REST call to an endpoint without being authorized, he would receive 401
> > > response, instead of 302 redirect (before Keycloak, the response was 401 in
> > > case of unauthorized access).
> > >
> > > yeah, I think the RESTful APIs behind the 'AdminUI' for the
> > > 'application/variant management' should continue to work. (I doubt there is
> > > much usage of those outside of the AdminUI)
> > >
> > >
> > >
> > >
> > > What do you think?
> > >
> > > ?
> > > Tadeas Kriz
> > >
> > >
> > >
> > >
> > > --
> > > Matthias Wessendorf
> > >
> > > blog: http://matthiaswessendorf.wordpress.com/
> > > sessions: http://www.slideshare.net/mwessendorf
> > > twitter: http://twitter.com/mwessendorf
> > >
> > > _______________________________________________
> > > aerogear-dev mailing list
> > > aerogear-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> 
> --
> 
> abstractj
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> 
> 
> 
> -- 
> Matthias Wessendorf 
> 
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140605/de9c2ef0/attachment-0001.html 

From matzew at apache.org  Thu Jun  5 09:18:37 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Thu, 5 Jun 2014 15:18:37 +0200
Subject: [aerogear-dev] Direct access to UnifiedPush Server's REST
	without OAuth
In-Reply-To: <1F52E76B-53FE-4B0A-9978-401E4A4D943C@redhat.com>
References: <619DEA09-3D50-4EF8-8D91-99A8E076E597@redhat.com>
	<CAAg5f2QxJVUa-Y76VKoPm=NnYZqx1TJxNCXWGc+G9ugcrjH1NA@mail.gmail.com>
	<691192050.20885964.1401970445848.JavaMail.zimbra@redhat.com>
	<20140605130725.GA61581@abstractj.org>
	<CAAg5f2Rs+72531GxCWwzvgBLO1pRz=6mT8xPYROygYEnWSqS8w@mail.gmail.com>
	<1F52E76B-53FE-4B0A-9978-401E4A4D943C@redhat.com>
Message-ID: <CAAg5f2Tbfn4fAp2CSfipAoXBTpYRHgeiNXHZmcTHC4Er_gy_8A@mail.gmail.com>

On Thu, Jun 5, 2014 at 3:16 PM, Tadeas Kriz <tkriz at redhat.com> wrote:

>
> ?
> Tadeas Kriz
>
> On 05 Jun 2014, at 15:09, Matthias Wessendorf <matzew at apache.org> wrote:
>
>
>
>
> On Thu, Jun 5, 2014 at 3:07 PM, Bruno Oliveira <bruno at abstractj.org>
> wrote:
>
>>
>> Thank you Stian.
>>
>> @tkriz @matzew Atm I'm working on the item 2 from Stian's comments, as
>> soon as I get admin-ui integrated with keycloak.js. Once the integration
>> is finished I can look at item 1 ? IMO not a top priority ATM, because
>> it only affects cURL.
>>
>> Correct me if I'm wrong.
>>
>
> correct - and the QE test-suite.
>
> I am fine in doing that close to 1.0.0 or even for 1.0.1 (depending on how
> busy the July will be)
>
> Makes sense ?
>
>
>
> I think it does make sense for the 1.0.0. In the integration tests we are
> able to replace the configuration required for the tests to work and
> authorize so we don?t have to rewrite it to check for 302 now and then
> rewrite it back to check for 401 when it?s fixed. I?ll just add some
> comments about this into the integration tests so it?s documented.
>

ok - let's aim for 1.0.0 ?
but not for 0.11 ?

-M



>
>
>
>
>>
>> On 2014-06-05, Stian Thorgersen wrote:
>> > As I suggested this, I'll add a bit more information.
>> >
>> > It makes sense to have two applications for UPS in Keycloak:
>> >
>> > 1) A bearer-only application for the REST endpoints - this application
>> does not allow logins and hence won't redirect to login screens, but return
>> 401/403. It will authenticate through the bearer token passed in the
>> headers. Any roles for UPS should be created for this application. Also,
>> the KC adapter (BootstrapListener) is configured for this application, as
>> that secures the REST endpoints
>> > 2) A public application for the Admin Console - this applications
>> allows logins. This should have scope mappings on roles in the application
>> above. This is used for the JS console, and I would recommend using
>> keycloak.js.
>> >
>> > ----- Original Message -----
>> > > From: "Matthias Wessendorf" <matzew at apache.org>
>> > > To: "Tadeas Kriz" <tkriz at redhat.com>
>> > > Cc: "AeroGear Developer Mailing List" <aerogear-dev at lists.jboss.org>
>> > > Sent: Thursday, 5 June, 2014 9:47:21 AM
>> > > Subject: Re: [aerogear-dev] Direct access to UnifiedPush Server's
>> REST      without OAuth
>> > >
>> > >
>> > >
>> > >
>> > > On Wed, Jun 4, 2014 at 6:18 PM, Tadeas Kriz < tkriz at redhat.com >
>> wrote:
>> > >
>> > >
>> > > Hey guys,
>> > >
>> > > as you might know, in the integration tests we only test the REST
>> backend,
>> > > making sure it works as intended. Before Keycloak, every action was
>> > > achievable using the REST, that included login, logout and user
>> management.
>> > > We don?t need the user management for sure, but login and logout is an
>> > > another story. Now with Keycloak anyone who wants to just use REST
>> calls,
>> > > still need to login using the Keycloak.
>> > >
>> > > My question is, do we want users to be able to access the REST
>> without OAuth?
>> > > If we do, it would probably mean we need to have two Keycloak
>> applications,
>> > >
>> > > What do you mean here? Are you suggestion two WAR files (for each
>> 'keycloak
>> > > application') ? Or just more a declarative setup?
>> > >
>> > >
>> > > one for the UI which would still use OAuth and second one for REST
>> calls
>> > > which would use Bearer only. This would also mean that when someone
>> makes a
>> > > REST call to an endpoint without being authorized, he would receive
>> 401
>> > > response, instead of 302 redirect (before Keycloak, the response was
>> 401 in
>> > > case of unauthorized access).
>> > >
>> > > yeah, I think the RESTful APIs behind the 'AdminUI' for the
>> > > 'application/variant management' should continue to work. (I doubt
>> there is
>> > > much usage of those outside of the AdminUI)
>> > >
>> > >
>> > >
>> > >
>> > > What do you think?
>> > >
>> > > ?
>> > > Tadeas Kriz
>> > >
>> > >
>> > >
>> > >
>> > > --
>> > > Matthias Wessendorf
>> > >
>> > > blog: http://matthiaswessendorf.wordpress.com/
>> > > sessions: http://www.slideshare.net/mwessendorf
>> > > twitter: http://twitter.com/mwessendorf
>> > >
>> > > _______________________________________________
>> > > aerogear-dev mailing list
>> > > aerogear-dev at lists.jboss.org
>> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> >
>> > _______________________________________________
>> > aerogear-dev mailing list
>> > aerogear-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>> --
>>
>> abstractj
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140605/e0185801/attachment.html 

From kpiwko at redhat.com  Thu Jun  5 10:41:27 2014
From: kpiwko at redhat.com (Karel Piwko)
Date: Thu, 5 Jun 2014 16:41:27 +0200
Subject: [aerogear-dev] [QUICKSTART] Information for the mobile clients
In-Reply-To: <20140602140544.GB51012@abstractj.org>
References: <CAD_dpu0q0X76hZj61FgDsqLB5D3MShknP7UXQDF0FJV+bJ7c=A@mail.gmail.com>
	<53502FF3.8010809@abstractj.org>
	<CAD_dpu0uKAwHh2vcXf3mr00O-2Za1dPG3wMdvZd4NbjfGiZQVw@mail.gmail.com>
	<CAKjsGbs1vusKkMBKFmjuqe3tC_H_ERtyaNhRxFP_9Qq1sdVaMg@mail.gmail.com>
	<CAD_dpu3v5yutnmAzwaHs5r3fRfBhHd4oY-CvqP-C5yhnD13ReA@mail.gmail.com>
	<CAKjsGbtZfJ1vSJfSz5pH4_UpwgJskyf+tdg2VQ8UctQduT3zGg@mail.gmail.com>
	<CAD_dpu0eZ7uaHHZzQq8pTLHKi3Y0_eyB82H8qwKrC3Db_wGh2A@mail.gmail.com>
	<CAKjsGbtCzXkk7tNjrKot=5zUDoH+ECtfhLEyj-56pwp8ph-oxw@mail.gmail.com>
	<CAD_dpu2s77Nm439S3gfWV37ZXFrJDMnp2R9VDNH4qCUirdve4A@mail.gmail.com>
	<65F33CC6-9BC7-4D2D-9451-D075CC0238A3@redhat.com>
	<20140602140544.GB51012@abstractj.org>
Message-ID: <20140605164127.6f4575a8@kapy-ntb-x220>

Correct JIRA for WFK would be:

https://issues.jboss.org/browse/JBWFK2

However, I'd rather target upstream first:

https://issues.jboss.org/browse/JDF/component/12315845/

Karel

On Mon, 2 Jun 2014 11:05:45 -0300
Bruno Oliveira <bruno at abstractj.org> wrote:

> Would make sense to file a Jira to:
> https://issues.jboss.org/browse/JBWFK ?
> 
> On 2014-06-02, Erik Jan de Wit wrote:
> > Seems to be a NullPointer:
> >
> > Caused by: java.lang.NullPointerException
> > 	at
> > org.jboss.quickstarts.wfk.contacts.customer.ContactRESTService.updateContact(ContactRESTService.java:192)
> > [classes:] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > [rt.jar:1.7.0_55] at
> > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> > [rt.jar:1.7.0_55] at
> > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > [rt.jar:1.7.0_55] at java.lang.reflect.Method.invoke(Method.java:606)
> > [rt.jar:1.7.0_55] at
> > org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> > at
> > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> > at
> > org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
> > at
> > org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> > at
> > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> > at
> > org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:407)
> > at
> > org.jboss.as.weld.ejb.DelegatingInterceptorInvocationContext.proceed(DelegatingInterceptorInvocationContext.java:87)
> > [wildfly-weld-8.1.0.CR1.jar:8.1.0.CR1] at
> > org.apache.deltaspike.security.impl.extension.DefaultSecurityStrategy.execute(DefaultSecurityStrategy.java:61)
> > [deltaspike-security-module-impl-0.5.jar:0.5] at
> > org.apache.deltaspike.security.impl.extension.SecurityInterceptor.filterDeniedInvocations(SecurityInterceptor.java:44)
> > [deltaspike-security-module-impl-0.5.jar:0.5] at
> > sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > [rt.jar:1.7.0_55] at
> > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> > [rt.jar:1.7.0_55] at
> > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > [rt.jar:1.7.0_55] at java.lang.reflect.Method.invoke(Method.java:606)
> > [rt.jar:1.7.0_55] at
> > org.jboss.weld.interceptor.proxy.SimpleMethodInvocation.invoke(SimpleMethodInvocation.java:30)
> > [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23] at
> > org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNext(AbstractInterceptionChain.java:103)
> > [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23] at
> > org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNextInterceptor(AbstractInterceptionChain.java:81)
> > [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23] at
> > org.jboss.weld.bean.InterceptorImpl.intercept(InterceptorImpl.java:105)
> > [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23] at
> > org.jboss.as.weld.ejb.DelegatingInterceptorInvocationContext.proceed(DelegatingInterceptorInvocationContext.java:77)
> > [wildfly-weld-8.1.0.CR1.jar:8.1.0.CR1] at
> > org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.delegateInterception(Jsr299BindingsInterceptor.java:68)
> > [wildfly-weld-8.1.0.CR1.jar:8.1.0.CR1] at
> > org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:80)
> > [wildfly-weld-8.1.0.CR1.jar:8.1.0.CR1] at
> > org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> > [wildfly-weld-8.1.0.CR1.jar:8.1.0.CR1] at
> > org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> > at
> > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> > at
> > org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
> > at
> > org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> > at
> > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> > at
> > org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> > [wildfly-ejb3-8.1.0.CR1.jar:8.1.0.CR1] at
> > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> > at
> > org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> > [wildfly-jpa-8.1.0.CR1.jar:8.1.0.CR1] at
> > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> > at
> > org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:407)
> > at
> > org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46)
> > [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23] at
> > org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> > [wildfly-weld-8.1.0.CR1.jar:8.1.0.CR1] at
> > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> > at
> > org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> > [wildfly-ee-8.1.0.CR1.jar:8.1.0.CR1] at
> > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> > at
> > org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> > at
> > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> > at
> > org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> > at
> > org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53)
> > at
> > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> > at
> > org.jboss.as.ejb3.component.interceptors.NonPooledEJBComponentInstanceAssociatingInterceptor.processInvocation(NonPooledEJBComponentInstanceAssociatingInterceptor.java:59)
> > [wildfly-ejb3-8.1.0.CR1.jar:8.1.0.CR1] at
> > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> > at
> > org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:273)
> > [wildfly-ejb3-8.1.0.CR1.jar:8.1.0.CR1] ... 81 more
> >
> > And that means the contact Id is null:
> >
> > https://github.com/edewit/jboss-wfk-quickstarts/blob/push/contacts-mobile-picketlink-secured/src/main/java/org/jboss/quickstarts/wfk/contacts/customer/ContactRESTService.java#L192
> >
> > So your data should also contain the same id as the id in the url
> >
> >  -d
> > '{"firstName":"Davey","lastName":"Jones","phoneNumber":"1(212)555-3333","email":"davey.jones at locker.com","birthDate":"1996-08-07","id?:"7"}'
> >
> >
> > On 2 Jun,2014, at 14:10 , Sebastien Blanc <scm.blanc at gmail.com> wrote:
> >
> > > Your request look good but without having the application server log it's
> > > hard to tell what is going on exactly. You could ask Erik to check the
> > > log or deploy the backend locally.
> > >
> > >
> > >
> > > On Mon, Jun 2, 2014 at 2:07 PM, Daniel Passos <daniel at passos.me> wrote:
> > > Sorry,
> > >
> > > Yes, I am try updating a contact and the server responded w/ status code
> > > 500
> > >
> > >
> > > * Adding handle: conn: 0x7ff159003000
> > > * Adding handle: send: 0
> > > * Adding handle: recv: 0
> > > * Curl_addHandleToPipeline: length: 1
> > > * - Conn 0 (0x7ff159003000) send_pipe: 1, recv_pipe: 0
> > > * About to connect() to quickstarts-edewit.rhcloud.com port 80 (#0)
> > > *   Trying 50.16.176.239...
> > > * Connected to quickstarts-edewit.rhcloud.com (50.16.176.239) port 80 (#0)
> > > > PUT /rest/contacts/7 HTTP/1.1
> > > > User-Agent: curl/7.30.0
> > > > Host: quickstarts-edewit.rhcloud.com
> > > > Cookie:
> > > > JSESSIONID=zugucP2LNHLbCNNOwBrD3mx6.quickstarts-edewit.rhcloud.com
> > > > Accept: application/json Content-type: application/json
> > > > Content-Length: 120
> > > >
> > > * upload completely sent off: 120 out of 120 bytes
> > > < HTTP/1.1 500 Internal Server Error
> > > < Date: Mon, 02 Jun 2014 12:04:59 GMT
> > > < Content-Type: text/html;charset=ISO-8859-1
> > > < Content-Length: 80
> > > < Connection: close
> > > <
> > > * Closing connection 0
> > > <html><head><title>Error</title></head><body>Internal Server
> > > Error</body></html> ?
> > >
> > >
> > > On Mon, Jun 2, 2014 at 4:39 AM, Sebastien Blanc <scm.blanc at gmail.com>
> > > wrote: What is the issue you are having and what are you trying to do
> > > (issue just with the update?) ?
> > >
> > >
> > >
> > > On Fri, May 30, 2014 at 8:48 PM, Daniel Passos <daniel at passos.me> wrote:
> > > Someone know that I am doing wrong?
> > >
> > > Login
> > >
> > > curl -v -b cookies.txt -c cookies.txt \
> > >      -H "Accept: application/json" \
> > >      -H "Content-type: application/json" \
> > >      -u "myuser:mypass" \
> > >      -X GET http://quickstarts-edewit.rhcloud.com/rest/security/user/info
> > > Update Contact
> > >
> > > curl -v -b cookies.txt -c cookies.txt \
> > >      -H "Accept: application/json" \
> > >      -H "Content-type: application/json" \
> > >      -X PUT \
> > >      -d
> > > '{"firstName":"fname","lastName":"lname","phoneNumber":"1234567","email":"example at example.com",
> > > "birthDate":"2001-03-24"}' \
> > > http://quickstarts-edewit.rhcloud.com/rest/contacts/7 ? Passos
> > >
> > > ?
> > >
> > >
> > > On Tue, May 20, 2014 at 3:13 PM, Sebastien Blanc <scm.blanc at gmail.com>
> > > wrote: Since we changed the use case for the Push part (now we
> > > broadcast) , passing a alias to UPS is not relevant anymore. For the
> > > login it's indeed "loginName" to be passed in the auth header along with
> > > the password.
> > >
> > >
> > >
> > > On Tue, May 20, 2014 at 7:34 PM, Daniel Passos <daniel at passos.me> wrote:
> > > To register I send "userName" and the login response "loginName"?
> > > -- Passos
> > >
> > >
> > >
> > > On Thu, Apr 17, 2014 at 6:07 PM, Sebastien Blanc <scm.blanc at gmail.com>
> > > wrote: Sure !
> > > This is just a version to ease the client development.
> > > I will ask PL team and Joshua their plans around HSTS and HTTPS.
> > > In the mean time we can track all of this with
> > > https://issues.jboss.org/browse/AGPUSH-596
> > >
> > > Thx for the comment !
> > > Sebi
> > >
> > >
> > > On Thu, Apr 17, 2014 at 9:48 PM, Bruno Oliveira <bruno at abstractj.org>
> > > wrote: If your idea is to be secure, please make sure to use HTTPS and
> > > enforce users to be redirected. We did it in the past with HSTS on AG
> > > Security, might not be hard to copy & paste.
> > >
> > > Sebastien Blanc wrote:
> > > > And because I love you, I deployed on OpenShift a version of this
> > > > secured backend to ease the development of the clients !
> > > >
> > > > If you browse to http://contacts-sblanc.rhcloud.com/ you will even see
> > > > the mobile web client. This deployed version contains also the Push
> > > > Message endpoint.
> > >
> > > _______________________________________________
> > > aerogear-dev mailing list
> > > aerogear-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > >
> > >
> > > _______________________________________________
> > > aerogear-dev mailing list
> > > aerogear-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > >
> > >
> > > _______________________________________________
> > > aerogear-dev mailing list
> > > aerogear-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > >
> > >
> > > _______________________________________________
> > > aerogear-dev mailing list
> > > aerogear-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > >
> > >
> > > _______________________________________________
> > > aerogear-dev mailing list
> > > aerogear-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > >
> > > _______________________________________________
> > > aerogear-dev mailing list
> > > aerogear-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> 
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> 
> 
> --
> 
> abstractj
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


From pmuir at redhat.com  Thu Jun  5 10:43:38 2014
From: pmuir at redhat.com (Pete Muir)
Date: Thu, 5 Jun 2014 15:43:38 +0100
Subject: [aerogear-dev] [QUICKSTART] Information for the mobile clients
In-Reply-To: <20140605164127.6f4575a8@kapy-ntb-x220>
References: <CAD_dpu0q0X76hZj61FgDsqLB5D3MShknP7UXQDF0FJV+bJ7c=A@mail.gmail.com>
	<53502FF3.8010809@abstractj.org>
	<CAD_dpu0uKAwHh2vcXf3mr00O-2Za1dPG3wMdvZd4NbjfGiZQVw@mail.gmail.com>
	<CAKjsGbs1vusKkMBKFmjuqe3tC_H_ERtyaNhRxFP_9Qq1sdVaMg@mail.gmail.com>
	<CAD_dpu3v5yutnmAzwaHs5r3fRfBhHd4oY-CvqP-C5yhnD13ReA@mail.gmail.com>
	<CAKjsGbtZfJ1vSJfSz5pH4_UpwgJskyf+tdg2VQ8UctQduT3zGg@mail.gmail.com>
	<CAD_dpu0eZ7uaHHZzQq8pTLHKi3Y0_eyB82H8qwKrC3Db_wGh2A@mail.gmail.com>
	<CAKjsGbtCzXkk7tNjrKot=5zUDoH+ECtfhLEyj-56pwp8ph-oxw@mail.gmail.com>
	<CAD_dpu2s77Nm439S3gfWV37ZXFrJDMnp2R9VDNH4qCUirdve4A@mail.gmail.com>
	<65F33CC6-9BC7-4D2D-9451-D075CC0238A3@redhat.com>
	<20140602140544.GB51012@abstractj.org>
	<20140605164127.6f4575a8@kapy-ntb-x220>
Message-ID: <88297D44-D13F-4D2F-99DE-C733A3270405@redhat.com>


On 5 Jun 2014, at 15:41, Karel Piwko <kpiwko at redhat.com> wrote:

> Correct JIRA for WFK would be:
> 
> https://issues.jboss.org/browse/JBWFK2

https://issues.jboss.org/browse/WFK2

> 
> However, I'd rather target upstream first:
> 
> https://issues.jboss.org/browse/JDF/component/12315845/
> 
> Karel
> 
> On Mon, 2 Jun 2014 11:05:45 -0300
> Bruno Oliveira <bruno at abstractj.org> wrote:
> 
>> Would make sense to file a Jira to:
>> https://issues.jboss.org/browse/JBWFK ?
>> 
>> On 2014-06-02, Erik Jan de Wit wrote:
>>> Seems to be a NullPointer:
>>> 
>>> Caused by: java.lang.NullPointerException
>>> 	at
>>> org.jboss.quickstarts.wfk.contacts.customer.ContactRESTService.updateContact(ContactRESTService.java:192)
>>> [classes:] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>> [rt.jar:1.7.0_55] at
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>>> [rt.jar:1.7.0_55] at
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>> [rt.jar:1.7.0_55] at java.lang.reflect.Method.invoke(Method.java:606)
>>> [rt.jar:1.7.0_55] at
>>> org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
>>> at
>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>>> at
>>> org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
>>> at
>>> org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>>> at
>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>>> at
>>> org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:407)
>>> at
>>> org.jboss.as.weld.ejb.DelegatingInterceptorInvocationContext.proceed(DelegatingInterceptorInvocationContext.java:87)
>>> [wildfly-weld-8.1.0.CR1.jar:8.1.0.CR1] at
>>> org.apache.deltaspike.security.impl.extension.DefaultSecurityStrategy.execute(DefaultSecurityStrategy.java:61)
>>> [deltaspike-security-module-impl-0.5.jar:0.5] at
>>> org.apache.deltaspike.security.impl.extension.SecurityInterceptor.filterDeniedInvocations(SecurityInterceptor.java:44)
>>> [deltaspike-security-module-impl-0.5.jar:0.5] at
>>> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>> [rt.jar:1.7.0_55] at
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>>> [rt.jar:1.7.0_55] at
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>> [rt.jar:1.7.0_55] at java.lang.reflect.Method.invoke(Method.java:606)
>>> [rt.jar:1.7.0_55] at
>>> org.jboss.weld.interceptor.proxy.SimpleMethodInvocation.invoke(SimpleMethodInvocation.java:30)
>>> [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23] at
>>> org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNext(AbstractInterceptionChain.java:103)
>>> [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23] at
>>> org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNextInterceptor(AbstractInterceptionChain.java:81)
>>> [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23] at
>>> org.jboss.weld.bean.InterceptorImpl.intercept(InterceptorImpl.java:105)
>>> [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23] at
>>> org.jboss.as.weld.ejb.DelegatingInterceptorInvocationContext.proceed(DelegatingInterceptorInvocationContext.java:77)
>>> [wildfly-weld-8.1.0.CR1.jar:8.1.0.CR1] at
>>> org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.delegateInterception(Jsr299BindingsInterceptor.java:68)
>>> [wildfly-weld-8.1.0.CR1.jar:8.1.0.CR1] at
>>> org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:80)
>>> [wildfly-weld-8.1.0.CR1.jar:8.1.0.CR1] at
>>> org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
>>> [wildfly-weld-8.1.0.CR1.jar:8.1.0.CR1] at
>>> org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>>> at
>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>>> at
>>> org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
>>> at
>>> org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>>> at
>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>>> at
>>> org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
>>> [wildfly-ejb3-8.1.0.CR1.jar:8.1.0.CR1] at
>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>>> at
>>> org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
>>> [wildfly-jpa-8.1.0.CR1.jar:8.1.0.CR1] at
>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>>> at
>>> org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:407)
>>> at
>>> org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46)
>>> [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23] at
>>> org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
>>> [wildfly-weld-8.1.0.CR1.jar:8.1.0.CR1] at
>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>>> at
>>> org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
>>> [wildfly-ee-8.1.0.CR1.jar:8.1.0.CR1] at
>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>>> at
>>> org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
>>> at
>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>>> at
>>> org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>>> at
>>> org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53)
>>> at
>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>>> at
>>> org.jboss.as.ejb3.component.interceptors.NonPooledEJBComponentInstanceAssociatingInterceptor.processInvocation(NonPooledEJBComponentInstanceAssociatingInterceptor.java:59)
>>> [wildfly-ejb3-8.1.0.CR1.jar:8.1.0.CR1] at
>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>>> at
>>> org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:273)
>>> [wildfly-ejb3-8.1.0.CR1.jar:8.1.0.CR1] ... 81 more
>>> 
>>> And that means the contact Id is null:
>>> 
>>> https://github.com/edewit/jboss-wfk-quickstarts/blob/push/contacts-mobile-picketlink-secured/src/main/java/org/jboss/quickstarts/wfk/contacts/customer/ContactRESTService.java#L192
>>> 
>>> So your data should also contain the same id as the id in the url
>>> 
>>> -d
>>> '{"firstName":"Davey","lastName":"Jones","phoneNumber":"1(212)555-3333","email":"davey.jones at locker.com","birthDate":"1996-08-07","id?:"7"}'
>>> 
>>> 
>>> On 2 Jun,2014, at 14:10 , Sebastien Blanc <scm.blanc at gmail.com> wrote:
>>> 
>>>> Your request look good but without having the application server log it's
>>>> hard to tell what is going on exactly. You could ask Erik to check the
>>>> log or deploy the backend locally.
>>>> 
>>>> 
>>>> 
>>>> On Mon, Jun 2, 2014 at 2:07 PM, Daniel Passos <daniel at passos.me> wrote:
>>>> Sorry,
>>>> 
>>>> Yes, I am try updating a contact and the server responded w/ status code
>>>> 500
>>>> 
>>>> 
>>>> * Adding handle: conn: 0x7ff159003000
>>>> * Adding handle: send: 0
>>>> * Adding handle: recv: 0
>>>> * Curl_addHandleToPipeline: length: 1
>>>> * - Conn 0 (0x7ff159003000) send_pipe: 1, recv_pipe: 0
>>>> * About to connect() to quickstarts-edewit.rhcloud.com port 80 (#0)
>>>> *   Trying 50.16.176.239...
>>>> * Connected to quickstarts-edewit.rhcloud.com (50.16.176.239) port 80 (#0)
>>>>> PUT /rest/contacts/7 HTTP/1.1
>>>>> User-Agent: curl/7.30.0
>>>>> Host: quickstarts-edewit.rhcloud.com
>>>>> Cookie:
>>>>> JSESSIONID=zugucP2LNHLbCNNOwBrD3mx6.quickstarts-edewit.rhcloud.com
>>>>> Accept: application/json Content-type: application/json
>>>>> Content-Length: 120
>>>>> 
>>>> * upload completely sent off: 120 out of 120 bytes
>>>> < HTTP/1.1 500 Internal Server Error
>>>> < Date: Mon, 02 Jun 2014 12:04:59 GMT
>>>> < Content-Type: text/html;charset=ISO-8859-1
>>>> < Content-Length: 80
>>>> < Connection: close
>>>> <
>>>> * Closing connection 0
>>>> <html><head><title>Error</title></head><body>Internal Server
>>>> Error</body></html> ?
>>>> 
>>>> 
>>>> On Mon, Jun 2, 2014 at 4:39 AM, Sebastien Blanc <scm.blanc at gmail.com>
>>>> wrote: What is the issue you are having and what are you trying to do
>>>> (issue just with the update?) ?
>>>> 
>>>> 
>>>> 
>>>> On Fri, May 30, 2014 at 8:48 PM, Daniel Passos <daniel at passos.me> wrote:
>>>> Someone know that I am doing wrong?
>>>> 
>>>> Login
>>>> 
>>>> curl -v -b cookies.txt -c cookies.txt \
>>>>     -H "Accept: application/json" \
>>>>     -H "Content-type: application/json" \
>>>>     -u "myuser:mypass" \
>>>>     -X GET http://quickstarts-edewit.rhcloud.com/rest/security/user/info
>>>> Update Contact
>>>> 
>>>> curl -v -b cookies.txt -c cookies.txt \
>>>>     -H "Accept: application/json" \
>>>>     -H "Content-type: application/json" \
>>>>     -X PUT \
>>>>     -d
>>>> '{"firstName":"fname","lastName":"lname","phoneNumber":"1234567","email":"example at example.com",
>>>> "birthDate":"2001-03-24"}' \
>>>> http://quickstarts-edewit.rhcloud.com/rest/contacts/7 ? Passos
>>>> 
>>>> ?
>>>> 
>>>> 
>>>> On Tue, May 20, 2014 at 3:13 PM, Sebastien Blanc <scm.blanc at gmail.com>
>>>> wrote: Since we changed the use case for the Push part (now we
>>>> broadcast) , passing a alias to UPS is not relevant anymore. For the
>>>> login it's indeed "loginName" to be passed in the auth header along with
>>>> the password.
>>>> 
>>>> 
>>>> 
>>>> On Tue, May 20, 2014 at 7:34 PM, Daniel Passos <daniel at passos.me> wrote:
>>>> To register I send "userName" and the login response "loginName"?
>>>> -- Passos
>>>> 
>>>> 
>>>> 
>>>> On Thu, Apr 17, 2014 at 6:07 PM, Sebastien Blanc <scm.blanc at gmail.com>
>>>> wrote: Sure !
>>>> This is just a version to ease the client development.
>>>> I will ask PL team and Joshua their plans around HSTS and HTTPS.
>>>> In the mean time we can track all of this with
>>>> https://issues.jboss.org/browse/AGPUSH-596
>>>> 
>>>> Thx for the comment !
>>>> Sebi
>>>> 
>>>> 
>>>> On Thu, Apr 17, 2014 at 9:48 PM, Bruno Oliveira <bruno at abstractj.org>
>>>> wrote: If your idea is to be secure, please make sure to use HTTPS and
>>>> enforce users to be redirected. We did it in the past with HSTS on AG
>>>> Security, might not be hard to copy & paste.
>>>> 
>>>> Sebastien Blanc wrote:
>>>>> And because I love you, I deployed on OpenShift a version of this
>>>>> secured backend to ease the development of the clients !
>>>>> 
>>>>> If you browse to http://contacts-sblanc.rhcloud.com/ you will even see
>>>>> the mobile web client. This deployed version contains also the Push
>>>>> Message endpoint.
>>>> 
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>> 
>>>> 
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>> 
>>>> 
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>> 
>>>> 
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>> 
>>>> 
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>> 
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>> 
>> 
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> 
>> 
>> --
>> 
>> abstractj
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> 
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev



From kpiwko at redhat.com  Thu Jun  5 10:47:17 2014
From: kpiwko at redhat.com (Karel Piwko)
Date: Thu, 5 Jun 2014 16:47:17 +0200
Subject: [aerogear-dev] Direct access to UnifiedPush Server's REST
 without OAuth
In-Reply-To: <CAAg5f2Rs+72531GxCWwzvgBLO1pRz=6mT8xPYROygYEnWSqS8w@mail.gmail.com>
References: <619DEA09-3D50-4EF8-8D91-99A8E076E597@redhat.com>
	<CAAg5f2QxJVUa-Y76VKoPm=NnYZqx1TJxNCXWGc+G9ugcrjH1NA@mail.gmail.com>
	<691192050.20885964.1401970445848.JavaMail.zimbra@redhat.com>
	<20140605130725.GA61581@abstractj.org>
	<CAAg5f2Rs+72531GxCWwzvgBLO1pRz=6mT8xPYROygYEnWSqS8w@mail.gmail.com>
Message-ID: <20140605164717.00fbdd56@kapy-ntb-x220>

On Thu, 5 Jun 2014 15:09:56 +0200
Matthias Wessendorf <matzew at apache.org> wrote:

> On Thu, Jun 5, 2014 at 3:07 PM, Bruno Oliveira <bruno at abstractj.org> wrote:
> 
> >
> > Thank you Stian.
> >
> > @tkriz @matzew Atm I'm working on the item 2 from Stian's comments, as
> > soon as I get admin-ui integrated with keycloak.js. Once the integration
> > is finished I can look at item 1 ? IMO not a top priority ATM, because
> > it only affects cURL.
> >
> > Correct me if I'm wrong.
> >
> 
> correct - and the QE test-suite.
> 
> I am fine in doing that close to 1.0.0 or even for 1.0.1 (depending on how
> busy the July will be)
> 
> Makes sense ?
> 

cURL, QE testsuite and any app (e.g. an app with your business logic) willing to
communicate with UPS via REST.

That said, I believe it is fine to keep this behavior (documented) for 0.11.0
and fix in 1.0.0. I'd consider that a critical feature for 1.0.0 though.

> 
> 
> 
> 
> >
> > On 2014-06-05, Stian Thorgersen wrote:
> > > As I suggested this, I'll add a bit more information.
> > >
> > > It makes sense to have two applications for UPS in Keycloak:
> > >
> > > 1) A bearer-only application for the REST endpoints - this application
> > does not allow logins and hence won't redirect to login screens, but return
> > 401/403. It will authenticate through the bearer token passed in the
> > headers. Any roles for UPS should be created for this application. Also,
> > the KC adapter (BootstrapListener) is configured for this application, as
> > that secures the REST endpoints
> > > 2) A public application for the Admin Console - this applications allows
> > logins. This should have scope mappings on roles in the application above.
> > This is used for the JS console, and I would recommend using keycloak.js.
> > >
> > > ----- Original Message -----
> > > > From: "Matthias Wessendorf" <matzew at apache.org>
> > > > To: "Tadeas Kriz" <tkriz at redhat.com>
> > > > Cc: "AeroGear Developer Mailing List" <aerogear-dev at lists.jboss.org>
> > > > Sent: Thursday, 5 June, 2014 9:47:21 AM
> > > > Subject: Re: [aerogear-dev] Direct access to UnifiedPush Server's REST
> >      without OAuth
> > > >
> > > >
> > > >
> > > >
> > > > On Wed, Jun 4, 2014 at 6:18 PM, Tadeas Kriz < tkriz at redhat.com >
> > wrote:
> > > >
> > > >
> > > > Hey guys,
> > > >
> > > > as you might know, in the integration tests we only test the REST
> > backend,
> > > > making sure it works as intended. Before Keycloak, every action was
> > > > achievable using the REST, that included login, logout and user
> > management.
> > > > We don?t need the user management for sure, but login and logout is an
> > > > another story. Now with Keycloak anyone who wants to just use REST
> > calls,
> > > > still need to login using the Keycloak.
> > > >
> > > > My question is, do we want users to be able to access the REST without
> > OAuth?
> > > > If we do, it would probably mean we need to have two Keycloak
> > applications,
> > > >
> > > > What do you mean here? Are you suggestion two WAR files (for each
> > 'keycloak
> > > > application') ? Or just more a declarative setup?
> > > >
> > > >
> > > > one for the UI which would still use OAuth and second one for REST
> > calls
> > > > which would use Bearer only. This would also mean that when someone
> > makes a
> > > > REST call to an endpoint without being authorized, he would receive 401
> > > > response, instead of 302 redirect (before Keycloak, the response was
> > 401 in
> > > > case of unauthorized access).
> > > >
> > > > yeah, I think the RESTful APIs behind the 'AdminUI' for the
> > > > 'application/variant management' should continue to work. (I doubt
> > there is
> > > > much usage of those outside of the AdminUI)
> > > >
> > > >
> > > >
> > > >
> > > > What do you think?
> > > >
> > > > ?
> > > > Tadeas Kriz
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Matthias Wessendorf
> > > >
> > > > blog: http://matthiaswessendorf.wordpress.com/
> > > > sessions: http://www.slideshare.net/mwessendorf
> > > > twitter: http://twitter.com/mwessendorf
> > > >
> > > > _______________________________________________
> > > > aerogear-dev mailing list
> > > > aerogear-dev at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > >
> > > _______________________________________________
> > > aerogear-dev mailing list
> > > aerogear-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> > --
> >
> > abstractj
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> 
> 
> 



From matzew at apache.org  Thu Jun  5 11:28:35 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Thu, 5 Jun 2014 17:28:35 +0200
Subject: [aerogear-dev] UnifiedPush 0.10.4 - release coming soon (Maven
 Central and OpenShift)
In-Reply-To: <20140605134734.56e21c95@kapy-ntb-x220>
References: <CAAg5f2T5rc+_TV4pcpFXh2M+SLsywL22SB1XpJGjHMbaHF22CA@mail.gmail.com>
	<CAAg5f2R2stDaAsF-2GOKb0r_XFXvx9u7=9xbN_9Pe1uam9foqA@mail.gmail.com>
	<20140605134734.56e21c95@kapy-ntb-x220>
Message-ID: <CAAg5f2T+TJBY_bKyhqeatWmuH2Cv+OfOJS6+QGR+zwvxfkdvyA@mail.gmail.com>

it's on Maven Central now

-Matthias


On Thu, Jun 5, 2014 at 1:47 PM, Karel Piwko <kpiwko at redhat.com> wrote:

> I bit too late to the party but:
>
> * integration tests are passing
> * admin UI tests are passing
> * cartridge tests are passing
>
> Happy sync to Maven Central ;-)
>
> Karel
>
> On Wed, 4 Jun 2014 21:19:55 +0200
> Matthias Wessendorf <matzew at apache.org> wrote:
>
> > released to maven central - should be available by tomorrow
> > OpenShift merge will follow once the bits are on maven central
> >
> >
> > On Tue, Jun 3, 2014 at 10:36 AM, Matthias Wessendorf <matzew at apache.org>
> > wrote:
> >
> > > Hello,
> > >
> > > as disscussed in our IRC meeting yesterday, I ran the release for the
> > > 0.10.4 version of UPS.
> > >
> > > The staging repository is located here:
> > >
> > >
> http://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3340/
> > >
> > > I sent a PR for our OpenShift offerings:
> > >
> > >
> https://github.com/aerogear/openshift-origin-cartridge-aerogear-push/pull/15
> > >
> > >
> > > If you want to test it - it's simple! Just go ahead and use my fork of
> the
> > > repo:
> > > rhc app create --no-git <YOUR COOL APP NAME>
> > >
> https://cartreflect-claytondev.rhcloud.com/reflect?github=matzew/openshift-origin-cartridge-aerogear-push
> > >  mysql-5.5
> > >
> > > The change log of the server:
> > >
> > > * AGPUSH-642
> > > * AGPUSH-643
> > > * AGPUSH-687
> > >
> > > Let me know the results of your testing;
> > > If I hear nothing bad by Wednesday evening, the merges (and release to
> > > maven central) will happen on Thursday;
> > >
> > >
> > > Cheers,
> > > Matthias
> > >
> > >
> > > --
> > > Matthias Wessendorf
> > >
> > > blog: http://matthiaswessendorf.wordpress.com/
> > > sessions: http://www.slideshare.net/mwessendorf
> > > twitter: http://twitter.com/mwessendorf
> > >
> >
> >
> >
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140605/7f6577e8/attachment-0001.html 

From kpiwko at redhat.com  Fri Jun  6 06:05:28 2014
From: kpiwko at redhat.com (Karel Piwko)
Date: Fri, 6 Jun 2014 12:05:28 +0200
Subject: [aerogear-dev] Improving Android HelloPush demo experience in
	Eclipse - PR
Message-ID: <20140606120528.57300bc3@kapy-ntb-x220>

Hi All,

I went through Android demo (and JBDS) and created following PR:

https://github.com/aerogear/aerogear-push-helloworld/pull/18

Let me know if you want to have separate PRs per commit. Goal was to have
example working in Eclipse/JBDS + ADT. There is still manual steps to do and
an error I was not able to fix it completely, investigating.

As per commit:

1/ Fixes Eclipse error marker for maven-android-plugin. AAR is not used, so it
is fine.

2/ Quickstart/demos should not have any parent, Maven best practice. Check JDF
quickstarts. Quickstart is an example and it is used to by user to scaffold
their own apps. We don't want them to use ag-parent but just ag-bom.

3/ If project.properties is missing, Eclipse is not able to add Android SDK to
build path. I've set it to API 19. This means that user has to point ADT to
Android SDK with API 19 installed. This is also version Eclipse will use for
code suggestion/autocompletion/build in IDE. Should have been API 10, I'm not
sure here.

4/ Dependencies in <dependencyManagement> should not define any scope with
exception of *import*. Maven best practice.

5/ If user don't provide UNIFIED_PUSH_URL, application fails due to
RuntimeException. I've added catch for IAE and Toast, however I believe there
should be a better way how to indicate that to user. IAE is quite generic and
fired from URLUtils in GCM registar. I'll file an issue to improve that.

6/ /bin directory is used by default by Eclipse to host temporary build

After these steps, I needed to follow these manual steps:

a/ Import android-support-v7-appcompat from Android SDK into workspace as
Android project
b/ Import hellopush/android as Maven project
c/ Add android-support-v7-appcompat as library in Android tab of project
properties

Now, I can edit the code. However, I can't use Run As/Android
Application still, likely due to http://tinypic.com/r/260ejpl/8

I'd appreciate if somebody could verify it is still working with AndroidStudio.

Thanks,

Karel

From matzew at apache.org  Fri Jun  6 07:23:44 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Fri, 6 Jun 2014 13:23:44 +0200
Subject: [aerogear-dev] Roadmap Update (was: Re: [planing] AeroGear Mobile
	Push 1.0.0 release)
Message-ID: <CAAg5f2QbrNjvWYb5GOGEw+uYW7sDfi9aDWnimE8jpL23hQuEzw@mail.gmail.com>

Hello,


I have updated the roadmap towards our Mobile Push 1.0.0 community release
this summer!
https://github.com/aerogear/aerogear.org/pull/307


-Matthias




On Mon, May 12, 2014 at 11:10 AM, Matthias Wessendorf <matzew at apache.org>
wrote:

> Hello folks!
>
> This summer we will release the AeroGear Mobile Push 1.0.0 to the
> community. This 'logical' release will contain a few items (that are all on
> their own versioning):
>
>    - UnifiedPush Server
>       - including Keycloak integration
>       - including statistics around Push messages sent out
>    - Client SDKs (for Android, Cordova and iOS)
>    - Examples/Quickstarts
>       - Simple HelloWorld examples (for Android, Cordova and iOS)
>       - more advanced Quickstart (different server integration options
>       (E.g. JAvaEE and Spring) + Clients for Android, Cordova and iOS)
>    - Openshift Cartridge
>    - Documentation
>
> To track these items, I have created a JIRA label "MobilePush-1.0", see
> [1]. For new JIRAs that are relevant for this initial community release,
> please use that label so that tracking of the items is much easier ;-)
>
> I will update the existing roadmap (yes, the 1.0.0 is already in there)
> based on current changes and delay's
>
> Thanks!
> Matthias
>
> [1] https://issues.jboss.org/issues/?jql=labels%20%3D%20MobilePush-1.0
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140606/b3354e77/attachment.html 

From bruno at abstractj.org  Fri Jun  6 08:33:30 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Fri, 6 Jun 2014 09:33:30 -0300
Subject: [aerogear-dev] Direct access to UnifiedPush Server's REST
 without OAuth
In-Reply-To: <CAAg5f2Tbfn4fAp2CSfipAoXBTpYRHgeiNXHZmcTHC4Er_gy_8A@mail.gmail.com>
References: <619DEA09-3D50-4EF8-8D91-99A8E076E597@redhat.com>
	<CAAg5f2QxJVUa-Y76VKoPm=NnYZqx1TJxNCXWGc+G9ugcrjH1NA@mail.gmail.com>
	<691192050.20885964.1401970445848.JavaMail.zimbra@redhat.com>
	<20140605130725.GA61581@abstractj.org>
	<CAAg5f2Rs+72531GxCWwzvgBLO1pRz=6mT8xPYROygYEnWSqS8w@mail.gmail.com>
	<1F52E76B-53FE-4B0A-9978-401E4A4D943C@redhat.com>
	<CAAg5f2Tbfn4fAp2CSfipAoXBTpYRHgeiNXHZmcTHC4Er_gy_8A@mail.gmail.com>
Message-ID: <20140606123330.GA97234@abstractj.org>

On 2014-06-05, Matthias Wessendorf wrote:
> On Thu, Jun 5, 2014 at 3:16 PM, Tadeas Kriz <tkriz at redhat.com> wrote:
>
> >
> > ?
> > Tadeas Kriz
> >
> > On 05 Jun 2014, at 15:09, Matthias Wessendorf <matzew at apache.org> wrote:
> >
> >
> >
> >
> > On Thu, Jun 5, 2014 at 3:07 PM, Bruno Oliveira <bruno at abstractj.org>
> > wrote:
> >
> >>
> >> Thank you Stian.
> >>
> >> @tkriz @matzew Atm I'm working on the item 2 from Stian's comments, as
> >> soon as I get admin-ui integrated with keycloak.js. Once the integration
> >> is finished I can look at item 1 ? IMO not a top priority ATM, because
> >> it only affects cURL.
> >>
> >> Correct me if I'm wrong.
> >>
> >
> > correct - and the QE test-suite.
> >
> > I am fine in doing that close to 1.0.0 or even for 1.0.1 (depending on how
> > busy the July will be)
> >
> > Makes sense ?
> >
> >
> >
> > I think it does make sense for the 1.0.0. In the integration tests we are
> > able to replace the configuration required for the tests to work and
> > authorize so we don?t have to rewrite it to check for 302 now and then
> > rewrite it back to check for 401 when it?s fixed. I?ll just add some
> > comments about this into the integration tests so it?s documented.
> >
>
> ok - let's aim for 1.0.0 ?

+1

> but not for 0.11 ?
>
> -M
>
>
>
> >
> >
> >
> >
> >>
> >> On 2014-06-05, Stian Thorgersen wrote:
> >> > As I suggested this, I'll add a bit more information.
> >> >
> >> > It makes sense to have two applications for UPS in Keycloak:
> >> >
> >> > 1) A bearer-only application for the REST endpoints - this application
> >> does not allow logins and hence won't redirect to login screens, but return
> >> 401/403. It will authenticate through the bearer token passed in the
> >> headers. Any roles for UPS should be created for this application. Also,
> >> the KC adapter (BootstrapListener) is configured for this application, as
> >> that secures the REST endpoints
> >> > 2) A public application for the Admin Console - this applications
> >> allows logins. This should have scope mappings on roles in the application
> >> above. This is used for the JS console, and I would recommend using
> >> keycloak.js.
> >> >
> >> > ----- Original Message -----
> >> > > From: "Matthias Wessendorf" <matzew at apache.org>
> >> > > To: "Tadeas Kriz" <tkriz at redhat.com>
> >> > > Cc: "AeroGear Developer Mailing List" <aerogear-dev at lists.jboss.org>
> >> > > Sent: Thursday, 5 June, 2014 9:47:21 AM
> >> > > Subject: Re: [aerogear-dev] Direct access to UnifiedPush Server's
> >> REST      without OAuth
> >> > >
> >> > >
> >> > >
> >> > >
> >> > > On Wed, Jun 4, 2014 at 6:18 PM, Tadeas Kriz < tkriz at redhat.com >
> >> wrote:
> >> > >
> >> > >
> >> > > Hey guys,
> >> > >
> >> > > as you might know, in the integration tests we only test the REST
> >> backend,
> >> > > making sure it works as intended. Before Keycloak, every action was
> >> > > achievable using the REST, that included login, logout and user
> >> management.
> >> > > We don?t need the user management for sure, but login and logout is an
> >> > > another story. Now with Keycloak anyone who wants to just use REST
> >> calls,
> >> > > still need to login using the Keycloak.
> >> > >
> >> > > My question is, do we want users to be able to access the REST
> >> without OAuth?
> >> > > If we do, it would probably mean we need to have two Keycloak
> >> applications,
> >> > >
> >> > > What do you mean here? Are you suggestion two WAR files (for each
> >> 'keycloak
> >> > > application') ? Or just more a declarative setup?
> >> > >
> >> > >
> >> > > one for the UI which would still use OAuth and second one for REST
> >> calls
> >> > > which would use Bearer only. This would also mean that when someone
> >> makes a
> >> > > REST call to an endpoint without being authorized, he would receive
> >> 401
> >> > > response, instead of 302 redirect (before Keycloak, the response was
> >> 401 in
> >> > > case of unauthorized access).
> >> > >
> >> > > yeah, I think the RESTful APIs behind the 'AdminUI' for the
> >> > > 'application/variant management' should continue to work. (I doubt
> >> there is
> >> > > much usage of those outside of the AdminUI)
> >> > >
> >> > >
> >> > >
> >> > >
> >> > > What do you think?
> >> > >
> >> > > ?
> >> > > Tadeas Kriz
> >> > >
> >> > >
> >> > >
> >> > >
> >> > > --
> >> > > Matthias Wessendorf
> >> > >
> >> > > blog: http://matthiaswessendorf.wordpress.com/
> >> > > sessions: http://www.slideshare.net/mwessendorf
> >> > > twitter: http://twitter.com/mwessendorf
> >> > >
> >> > > _______________________________________________
> >> > > aerogear-dev mailing list
> >> > > aerogear-dev at lists.jboss.org
> >> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >> >
> >> > _______________________________________________
> >> > aerogear-dev mailing list
> >> > aerogear-dev at lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>
> >> --
> >>
> >> abstractj
> >> _______________________________________________
> >> aerogear-dev mailing list
> >> aerogear-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>
> >
> >
> >
> > --
> > Matthias Wessendorf
> >
> > blog: http://matthiaswessendorf.wordpress.com/
> > sessions: http://www.slideshare.net/mwessendorf
> > twitter: http://twitter.com/mwessendorf
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> >
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf

> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


--

abstractj

From daniel at passos.me  Fri Jun  6 09:51:22 2014
From: daniel at passos.me (Daniel Passos)
Date: Fri, 6 Jun 2014 10:51:22 -0300
Subject: [aerogear-dev] contacts-mobile-basic quick start
In-Reply-To: <1401961219970-8090.post@n5.nabble.com>
References: <CAFJm-3ES4VQL8=rBT22jKuo+6T-18AB4Oh=XP4p172o4fSLR1g@mail.gmail.com>
	<CAFJm-3H9-t1E--T+_ctZ7+YVpw2XVwByoHFm-hFSBZWTxMiQag@mail.gmail.com>
	<CAFJm-3Fxd8LR8eqhGTBzutpc_Tu+LsQ5VW+ANzrKaq0QnbBmZw@mail.gmail.com>
	<682680FC-677F-4566-8E2C-9392CEC4FC83@gmail.com>
	<1401776740005-8059.post@n5.nabble.com>
	<20140603103948.GD88786@abstractj.org>
	<1401798729477-8072.post@n5.nabble.com>
	<1401873798566-8079.post@n5.nabble.com>
	<1401874337203-8080.post@n5.nabble.com>
	<1401894386127-8083.post@n5.nabble.com>
	<1401961219970-8090.post@n5.nabble.com>
Message-ID: <CAKjsGbsQp77GgUrTL87fkHMUpERgdNMf5FBwFtJqX2pox5=-zg@mail.gmail.com>

Hi folks,

I uploaded a android quickstarts video[1] like iOS[2] and cordova[3] :)

[1] https://vimeo.com/97464515
[2] https://vimeo.com/93471554
[3] https://www.youtube.com/watch?v=BOy4s-HrYNY

-- Passos


On Thu, Jun 5, 2014 at 6:40 AM, danielbevenius <daniel.bevenius at gmail.com>
wrote:

> The previous Fabric8 issue was deleted as it was not what we needed in the
> end. This one was filed instead:
> https://github.com/fabric8io/fabric8/issues/1631
>
> Erik reported an issue yesterday regarding the error "Multiple
> Access-Control-Allow-Origin headers are not allowed for CORS response" when
> accessing:
> http://webapp-dbevenius.rhcloud.com/jboss-contacts-mobile-webapp
>
> I've added a workaround for this with the following commit:
>
> https://github.com/danbev/jboss-wfk-quickstarts/commit/24f03ca626aa302ad16efeae5d8a3621b6f351ab
> This has been deployed and I also believe that this might have caused the
> navigation to the signin-page to malfunction before. At least I'm not
> seeing
> this error anymore. Please let me know if do see that issue and I'll take a
> closer look at it.
>
>
>
>
>
>
>
> --
> View this message in context:
> http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-contacts-mobile-basic-quick-start-tp7534p8090.html
> Sent from the aerogear-dev mailing list archive at Nabble.com.
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140606/f4d4fc5b/attachment.html 

From daniel at passos.me  Fri Jun  6 11:22:43 2014
From: daniel at passos.me (Daniel Passos)
Date: Fri, 6 Jun 2014 12:22:43 -0300
Subject: [aerogear-dev] Improving Android HelloPush demo experience in
 Eclipse - PR
In-Reply-To: <20140606120528.57300bc3@kapy-ntb-x220>
References: <20140606120528.57300bc3@kapy-ntb-x220>
Message-ID: <CAKjsGbvBb=FqrLyA7eC6-=wQ85HZZ39340mxoWEnv93Z9cBuFA@mail.gmail.com>

Answer inline

On Fri, Jun 6, 2014 at 7:05 AM, Karel Piwko <kpiwko at redhat.com> wrote:

> Hi All,
>
> I went through Android demo (and JBDS) and created following PR:
>
> https://github.com/aerogear/aerogear-push-helloworld/pull/18
>
> Let me know if you want to have separate PRs per commit. Goal was to have
> example working in Eclipse/JBDS + ADT. There is still manual steps to do
> and
> an error I was not able to fix it completely, investigating.
>
> As per commit:
>
> 1/ Fixes Eclipse error marker for maven-android-plugin. AAR is not used,
> so it
> is fine.
>
> 2/ Quickstart/demos should not have any parent, Maven best practice. Check
> JDF
> quickstarts. Quickstart is an example and it is used to by user to scaffold
> their own apps. We don't want them to use ag-parent but just ag-bom.
>

Not sure why it's so bad. parent-pom is releases in maven central so, the
community can use it. I think a notice in the README explaining why we are
using it is good.

parent-pom has some nice plugins like formatter, license header, etc...
Should we do it manually or put this plugins in the project pom?


> 3/ If project.properties is missing, Eclipse is not able to add Android
> SDK to
> build path. I've set it to API 19. This means that user has to point ADT to
> Android SDK with API 19 installed. This is also version Eclipse will use
> for
> code suggestion/autocompletion/build in IDE. Should have been API 10, I'm
> not
> sure here.
>

Always use the same of targetSdkVersion. So, it's correctly ;)


> 4/ Dependencies in <dependencyManagement> should not define any scope with
> exception of *import*. Maven best practice.
>

+1 Good catch.


> 5/ If user don't provide UNIFIED_PUSH_URL, application fails due to
> RuntimeException. I've added catch for IAE and Toast, however I believe
> there
> should be a better way how to indicate that to user. IAE is quite generic
> and
> fired from URLUtils in GCM registar. I'll file an issue to improve that.
>

+1


> 6/ /bin directory is used by default by Eclipse to host temporary build
>

+1 Maybe is a good ideia copy the cookbook .gitignore
https://github.com/aerogear/aerogear-android-cookbook/blob/master/.gitignore

After these steps, I needed to follow these manual steps:
>
> a/ Import android-support-v7-appcompat from Android SDK into workspace as
> Android project
> b/ Import hellopush/android as Maven project
> c/ Add android-support-v7-appcompat as library in Android tab of project
> properties
>
> Now, I can edit the code. However, I can't use Run As/Android
> Application still, likely due to http://tinypic.com/r/260ejpl/8


Not sure what is going on, but I'll take a look at it next week. Could you
fire a jira for me?


> I'd appreciate if somebody could verify it is still working with
> AndroidStudio.
>

I just run it in Android Studio and IntelliJ. I don't know how, but all
still working :P

Thanks,
>
> Karel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140606/f12c6757/attachment-0001.html 

From bruno at abstractj.org  Fri Jun  6 12:05:13 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Fri, 6 Jun 2014 13:05:13 -0300
Subject: [aerogear-dev] admin-ui and Keycloak.js integration
Message-ID: <20140606160512.GA1854@abstractj.org>

Good morning,

I'm struggling to integrate Keycloak.js with our admin-ui. Everything
works perfectly well out of admin-ui with UPS and Angular.js as you
might notice here:
https://github.com/abstractj/aerogear-unifiedpush-server/tree/keycloak-angular

The issue lies when I enable the routes related with redirect and
MainController:
https://github.com/abstractj/aerogear-unifiedpush-server/tree/keycloak_angular_integration.
Just open http://localhost:8080/ag-push and watch your browser reload
like crazy. When the main route and redirect are disable, everything goes
well:
https://github.com/abstractj/aerogear-unifiedpush-server/commit/dd9438c6503061fba8aa0e0d77973971888e9379


At first glance it doesn't sound to be a problem on KC.js, once already works with Angular.js:
https://github.com/keycloak/keycloak/tree/master/examples/demo-template/angular-product-app.

If you have any idea, help is appreciated.

--

abstractj

From scm.blanc at gmail.com  Sat Jun  7 05:29:29 2014
From: scm.blanc at gmail.com (Sebastien Blanc)
Date: Sat, 7 Jun 2014 11:29:29 +0200
Subject: [aerogear-dev] admin-ui and Keycloak.js integration
In-Reply-To: <20140606160512.GA1854@abstractj.org>
References: <20140606160512.GA1854@abstractj.org>
Message-ID: <CAD_dpu0PN6qfSajHW-qV24EG-CPNQNYCmW8tsi1L6tGStGgjqg@mail.gmail.com>

Hi my friend !

Just to let you know I started to look at your branch and indeed you better
not be epileptic to survive the crazy reloads ;)
I have nothing to push right now but I have some ideas :

* Like you mention, the redirect and main route broke the stuff. So, I
think we should remove that and do the initial redirect in the success
callback of the keycloakAuth.init call. I have a local branch where I
manage to do that, but it's really hacky and I face another issue , the
first next REST call fails because there are not auth info. But ! This is
there where we have to introduce the Auth interceptor like here
https://github.com/keycloak/keycloak/blob/master/examples/demo-template/angular-product-app/src/main/webapp/js/app.js#L43-L60

I think based on this, we should be able to find a solution. I will try to
push my work ASAP and maybe some dudes for KC could give us some hints as
well.

Have a good weekend !

sebi



On Fri, Jun 6, 2014 at 6:05 PM, Bruno Oliveira <bruno at abstractj.org> wrote:

> Good morning,
>
> I'm struggling to integrate Keycloak.js with our admin-ui. Everything
> works perfectly well out of admin-ui with UPS and Angular.js as you
> might notice here:
>
> https://github.com/abstractj/aerogear-unifiedpush-server/tree/keycloak-angular
>
> The issue lies when I enable the routes related with redirect and
> MainController:
>
> https://github.com/abstractj/aerogear-unifiedpush-server/tree/keycloak_angular_integration
> .
> Just open http://localhost:8080/ag-push and watch your browser reload
> like crazy. When the main route and redirect are disable, everything goes
> well:
>
> https://github.com/abstractj/aerogear-unifiedpush-server/commit/dd9438c6503061fba8aa0e0d77973971888e9379
>
>
> At first glance it doesn't sound to be a problem on KC.js, once already
> works with Angular.js:
>
> https://github.com/keycloak/keycloak/tree/master/examples/demo-template/angular-product-app
> .
>
> If you have any idea, help is appreciated.
>
> --
>
> abstractj
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140607/5e7d8cf0/attachment.html 

From keith at kdmooreconsulting.com  Sun Jun  8 02:26:08 2014
From: keith at kdmooreconsulting.com (keithdmoore94)
Date: Sat, 7 Jun 2014 23:26:08 -0700 (PDT)
Subject: [aerogear-dev] Errors building contacts-mobile-basic - Please help
Message-ID: <1402208768808-8110.post@n5.nabble.com>

When trying to build the contacts-mobile-basic app in
https://github.com/sebastienblanc/jboss-wfk-quickstarts.git

Below is the stacktrace.  Anybody have a clue as to what the problem is?  I
am using maven 3.2.1.

jboss-wfk-quickstarts/contacts-mobile-basic$ mvn clean install -U -e
[INFO] Error stacktraces are turned on.
[INFO] Scanning for projects...
Downloading:
http://repo.maven.apache.org/maven2/org/jboss/bom/wfk/jboss-javaee-6.0-with-tools/2.5.0-build-2/jboss-javaee-6.0-with-tools-2.5.0-build-2.pom
Downloading:
http://repo.maven.apache.org/maven2/org/jboss/bom/eap/jboss-javaee-6.0-with-hibernate/6.2.0.GA/jboss-javaee-6.0-with-hibernate-6.2.0.GA.pom
[ERROR] The build could not read 1 project -> [Help 1]
org.apache.maven.project.ProjectBuildingException: Some problems were
encountered while processing the POMs:
[ERROR] Non-resolvable import POM: Could not find artifact
org.jboss.bom.wfk:jboss-javaee-6.0-with-tools:pom:2.5.0-build-2 in central
(http://repo.maven.apache.org/maven2) @ line 72, column 25
[ERROR] Non-resolvable import POM: Could not find artifact
org.jboss.bom.eap:jboss-javaee-6.0-with-hibernate:pom:6.2.0.GA in central
(http://repo.maven.apache.org/maven2) @ line 79, column 25
[ERROR] 'dependencies.dependency.version' for javax.enterprise:cdi-api:jar
is missing. @ line 92, column 21
[ERROR] 'dependencies.dependency.version' for
org.jboss.spec.javax.annotation:jboss-annotations-api_1.1_spec:jar is
missing. @ line 99, column 21
[ERROR] 'dependencies.dependency.version' for
org.jboss.spec.javax.ws.rs:jboss-jaxrs-api_1.1_spec:jar is missing. @ line
106, column 21
[ERROR] 'dependencies.dependency.version' for
org.hibernate.javax.persistence:hibernate-jpa-2.0-api:jar is missing. @ line
113, column 21
[ERROR] 'dependencies.dependency.version' for
org.jboss.spec.javax.ejb:jboss-ejb-api_3.1_spec:jar is missing. @ line 120,
column 21
[ERROR] 'dependencies.dependency.version' for
org.jboss.spec.javax.servlet:jboss-servlet-api_3.0_spec:jar is missing. @
line 127, column 21
[ERROR] 'dependencies.dependency.version' for
org.hibernate:hibernate-validator:jar is missing. @ line 136, column 21
[ERROR] 'dependencies.dependency.version' for
org.hibernate:hibernate-jpamodelgen:jar is missing. @ line 151, column 21
[ERROR] 'dependencies.dependency.version' for junit:junit:jar is missing. @
line 158, column 21
[ERROR] 'dependencies.dependency.version' for
org.jboss.arquillian.junit:arquillian-junit-container:jar is missing. @ line
166, column 21
[ERROR] 'dependencies.dependency.version' for
org.jboss.arquillian.protocol:arquillian-protocol-servlet:jar is missing. @
line 172, column 21



--
View this message in context: http://aerogear-dev.1069024.n5.nabble.com/Errors-building-contacts-mobile-basic-Please-help-tp8110.html
Sent from the aerogear-dev mailing list archive at Nabble.com.

From scm.blanc at gmail.com  Sun Jun  8 03:00:12 2014
From: scm.blanc at gmail.com (=?utf-8?Q?S=C3=A9bastien_Blanc?=)
Date: Sun, 8 Jun 2014 09:00:12 +0200
Subject: [aerogear-dev] Errors building contacts-mobile-basic - Please
	help
In-Reply-To: <1402208768808-8110.post@n5.nabble.com>
References: <1402208768808-8110.post@n5.nabble.com>
Message-ID: <F3AC052D-0647-4B4A-8713-0B1D04C5B74B@gmail.com>

Hi,
Have you changed your maven settings.xml as explained in the readme (section "configure maven")? 
Btw, I see that you are trying to build my fork , I haven't updated it since a long time and depending on what you are trying to do it would be better to to take a more recent one.
Envoy? de mon iPhone

> Le 8 juin 2014 ? 08:26, keithdmoore94 <keith at kdmooreconsulting.com> a ?crit :
> 
> When trying to build the contacts-mobile-basic app in
> https://github.com/sebastienblanc/jboss-wfk-quickstarts.git
> 
> Below is the stacktrace.  Anybody have a clue as to what the problem is?  I
> am using maven 3.2.1.
> 
> jboss-wfk-quickstarts/contacts-mobile-basic$ mvn clean install -U -e
> [INFO] Error stacktraces are turned on.
> [INFO] Scanning for projects...
> Downloading:
> http://repo.maven.apache.org/maven2/org/jboss/bom/wfk/jboss-javaee-6.0-with-tools/2.5.0-build-2/jboss-javaee-6.0-with-tools-2.5.0-build-2.pom
> Downloading:
> http://repo.maven.apache.org/maven2/org/jboss/bom/eap/jboss-javaee-6.0-with-hibernate/6.2.0.GA/jboss-javaee-6.0-with-hibernate-6.2.0.GA.pom
> [ERROR] The build could not read 1 project -> [Help 1]
> org.apache.maven.project.ProjectBuildingException: Some problems were
> encountered while processing the POMs:
> [ERROR] Non-resolvable import POM: Could not find artifact
> org.jboss.bom.wfk:jboss-javaee-6.0-with-tools:pom:2.5.0-build-2 in central
> (http://repo.maven.apache.org/maven2) @ line 72, column 25
> [ERROR] Non-resolvable import POM: Could not find artifact
> org.jboss.bom.eap:jboss-javaee-6.0-with-hibernate:pom:6.2.0.GA in central
> (http://repo.maven.apache.org/maven2) @ line 79, column 25
> [ERROR] 'dependencies.dependency.version' for javax.enterprise:cdi-api:jar
> is missing. @ line 92, column 21
> [ERROR] 'dependencies.dependency.version' for
> org.jboss.spec.javax.annotation:jboss-annotations-api_1.1_spec:jar is
> missing. @ line 99, column 21
> [ERROR] 'dependencies.dependency.version' for
> org.jboss.spec.javax.ws.rs:jboss-jaxrs-api_1.1_spec:jar is missing. @ line
> 106, column 21
> [ERROR] 'dependencies.dependency.version' for
> org.hibernate.javax.persistence:hibernate-jpa-2.0-api:jar is missing. @ line
> 113, column 21
> [ERROR] 'dependencies.dependency.version' for
> org.jboss.spec.javax.ejb:jboss-ejb-api_3.1_spec:jar is missing. @ line 120,
> column 21
> [ERROR] 'dependencies.dependency.version' for
> org.jboss.spec.javax.servlet:jboss-servlet-api_3.0_spec:jar is missing. @
> line 127, column 21
> [ERROR] 'dependencies.dependency.version' for
> org.hibernate:hibernate-validator:jar is missing. @ line 136, column 21
> [ERROR] 'dependencies.dependency.version' for
> org.hibernate:hibernate-jpamodelgen:jar is missing. @ line 151, column 21
> [ERROR] 'dependencies.dependency.version' for junit:junit:jar is missing. @
> line 158, column 21
> [ERROR] 'dependencies.dependency.version' for
> org.jboss.arquillian.junit:arquillian-junit-container:jar is missing. @ line
> 166, column 21
> [ERROR] 'dependencies.dependency.version' for
> org.jboss.arquillian.protocol:arquillian-protocol-servlet:jar is missing. @
> line 172, column 21
> 
> 
> 
> --
> View this message in context: http://aerogear-dev.1069024.n5.nabble.com/Errors-building-contacts-mobile-basic-Please-help-tp8110.html
> Sent from the aerogear-dev mailing list archive at Nabble.com.
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


From scm.blanc at gmail.com  Sun Jun  8 05:34:56 2014
From: scm.blanc at gmail.com (Sebastien Blanc)
Date: Sun, 8 Jun 2014 11:34:56 +0200
Subject: [aerogear-dev] admin-ui and Keycloak.js integration
In-Reply-To: <CAD_dpu0PN6qfSajHW-qV24EG-CPNQNYCmW8tsi1L6tGStGgjqg@mail.gmail.com>
References: <20140606160512.GA1854@abstractj.org>
	<CAD_dpu0PN6qfSajHW-qV24EG-CPNQNYCmW8tsi1L6tGStGgjqg@mail.gmail.com>
Message-ID: <CAD_dpu0krGZ383BOiiuXhTE49OSaYDzBDZ6MxWapRLgiKUANEw@mail.gmail.com>

So here is my branch with some changes (but - disclaimer-  it's still not
working but will maybe help to make progress) :
https://github.com/sebastienblanc/aerogear-unified-push-server/tree/keycloak_angular_integration

The problem is now on the server side,   this give a NPE :
https://github.com/sebastienblanc/aerogear-unified-push-server/blob/keycloak_angular_integration/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/applications/PushApplicationEndpoint.java#L78

So basically, in the request we don't have the UserPrincipal but from the
client I can see an Authorization header :


   1. GET /ag-push/rest/applications HTTP/1.1 Host: localhost:8080
   Connection: keep-alive Cache-Control: max-age=0 Accept: application/json,
   text/plain, */* User-Agent: Mozilla/5.0 (X11; Linux x86_64)
   AppleWebKit/537.36 (KHTML, like Gecko) Chrome/33.0.1750.152 Safari/537.36
   Authorization: Bearer
   eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiIxNTk5MzBmNi05NDI4LTQxM2EtYTExZi00MjA3MzY5ZTMyOGYiLCJleHAiOjE0MDIyMjI2MDEsIm5iZiI6MCwiaWF0IjoxNDAyMjE5NjAxLCJpc3MiOiJhZXJvZ2VhciIsImF1ZCI6ImFlcm9nZWFyIiwic3ViIjoiOWFlOTE3ZTItMTViZi00MzhmLThlYzctMGE5YzBkM2RkNzlhIiwiYXpwIjoidW5pZmllZC1wdXNoLXNlcnZlciIsInByZWZlcnJlZF91c2VybmFtZSI6ImFkbWluIiwic2Vzc2lvbl9zdGF0ZSI6IjJmNzkzNjQ2LWFmYjUtNDdkOC1hMmNmLWM1MDJjNThmMTQzMiIsImFsbG93ZWQtb3JpZ2lucyI6W10sInJlYWxtX2FjY2VzcyI6eyJyb2xlcyI6WyJhZG1pbiJdfSwicmVzb3VyY2VfYWNjZXNzIjp7fX0.Vk8_RJOnzh1tvWxHCLu5WTyOdy84LU1QwclCq4NRTqDL-82B-X1CuJVVnxr3abqgdRZbtvVIgEDeQvnYXLKYmLSCsT-PtJl54AQc72GRRDplyVkaGlw1Vcg-eNGwnyy6jnYusmumuf_24H0DaxXWITXi-GKRoW4cVn7lEwqgF_k
   Referer: http://localhost:8080/ag-push/?redirect_fragment=/main&code=eyJhbGciOiJSUzI1NiJ9.ZGE3ZTYzNWEtZTYxYi00Y2ViLTg1OWMtMDBkMDU2YjlkMjdmMTQwMjIxOTYwMTAzMg.aQ9hBljDqFchGzkblFrYQ2E_Ax8kh-P4r7Ctz8oPx4dCKVpRM0zmxYkpC_0ALEzPHXS6AKv58MQTXM55_8yUxk15AC9-foCvrYZvPrFqNL4c_GQm5P4KivP6t-RNS0pg63zziM3QNLq9aOVeoFnm5fZU5i0ZGvzT8edzFHmYlds&state=e2918ebe-e5b8-46d5-823e-e727b2ea18bd
   Accept-Encoding: gzip,deflate,sdch Accept-Language:
   en-US,en;q=0.8,fr;q=0.6 Cookie:
   JSESSIONID=nBxjj-qL3YRjCtxKKyMutHPQ.undefined





On Sat, Jun 7, 2014 at 11:29 AM, Sebastien Blanc <scm.blanc at gmail.com>
wrote:

> Hi my friend !
>
> Just to let you know I started to look at your branch and indeed you
> better not be epileptic to survive the crazy reloads ;)
> I have nothing to push right now but I have some ideas :
>
> * Like you mention, the redirect and main route broke the stuff. So, I
> think we should remove that and do the initial redirect in the success
> callback of the keycloakAuth.init call. I have a local branch where I
> manage to do that, but it's really hacky and I face another issue , the
> first next REST call fails because there are not auth info. But ! This is
> there where we have to introduce the Auth interceptor like here
> https://github.com/keycloak/keycloak/blob/master/examples/demo-template/angular-product-app/src/main/webapp/js/app.js#L43-L60
>
> I think based on this, we should be able to find a solution. I will try to
> push my work ASAP and maybe some dudes for KC could give us some hints as
> well.
>
> Have a good weekend !
>
> sebi
>
>
>
> On Fri, Jun 6, 2014 at 6:05 PM, Bruno Oliveira <bruno at abstractj.org>
> wrote:
>
>> Good morning,
>>
>> I'm struggling to integrate Keycloak.js with our admin-ui. Everything
>> works perfectly well out of admin-ui with UPS and Angular.js as you
>> might notice here:
>>
>> https://github.com/abstractj/aerogear-unifiedpush-server/tree/keycloak-angular
>>
>> The issue lies when I enable the routes related with redirect and
>> MainController:
>>
>> https://github.com/abstractj/aerogear-unifiedpush-server/tree/keycloak_angular_integration
>> .
>> Just open http://localhost:8080/ag-push and watch your browser reload
>> like crazy. When the main route and redirect are disable, everything goes
>> well:
>>
>> https://github.com/abstractj/aerogear-unifiedpush-server/commit/dd9438c6503061fba8aa0e0d77973971888e9379
>>
>>
>> At first glance it doesn't sound to be a problem on KC.js, once already
>> works with Angular.js:
>>
>> https://github.com/keycloak/keycloak/tree/master/examples/demo-template/angular-product-app
>> .
>>
>> If you have any idea, help is appreciated.
>>
>> --
>>
>> abstractj
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140608/7f64e10d/attachment-0001.html 

From daniel.bevenius at gmail.com  Sun Jun  8 11:37:14 2014
From: daniel.bevenius at gmail.com (Daniel Bevenius)
Date: Sun, 8 Jun 2014 17:37:14 +0200
Subject: [aerogear-dev] Team meeting
Message-ID: <CAFJm-3HZWXpoMXFUKHLcfGNpTYr76R17dd_SxSS8-Ek=nqcxWA@mail.gmail.com>

Agenda:
http://oksoclap.com/p/aerogear-team-mgt-20140609
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140608/ccaa25f3/attachment.html 

From jowilson at redhat.com  Sun Jun  8 19:59:55 2014
From: jowilson at redhat.com (joshuaw)
Date: Sun, 8 Jun 2014 16:59:55 -0700 (PDT)
Subject: [aerogear-dev] Errors building contacts-mobile-basic - Please
 help
In-Reply-To: <F3AC052D-0647-4B4A-8713-0B1D04C5B74B@gmail.com>
References: <1402208768808-8110.post@n5.nabble.com>
	<F3AC052D-0647-4B4A-8713-0B1D04C5B74B@gmail.com>
Message-ID: <a62c2ede.00001be8.00000077@AMENTRAR978LMH>

I agree, you should be using the latest from 
https://github.com/jboss-developer/jboss-wfk-quickstarts/tree/2.6.x-develop/contacts-mobile-basic 
and make sure your settings.xml is pointing to the correct repo.



If you still have problems after that please let me know.



Joshua



From: Sebastien Blanc [via aerogear-dev] 
[mailto:ml-node+s1069024n8111h56 at n5.nabble.com]
Sent: Sunday, June 08, 2014 3:01 AM
To: joshuaw
Subject: Re: [aerogear-dev] Errors building contacts-mobile-basic - Please 
help



Hi,
Have you changed your maven settings.xml as explained in the readme (section 
"configure maven")?
Btw, I see that you are trying to build my fork , I haven't updated it since 
a long time and depending on what you are trying to do it would be better to 
to take a more recent one.
Envoy? de mon iPhone


> Le 8 juin 2014 ? 08:26, keithdmoore94 <[hidden email]> a ?crit :
>
> When trying to build the contacts-mobile-basic app in
> https://github.com/sebastienblanc/jboss-wfk-quickstarts.git
>
> Below is the stacktrace.  Anybody have a clue as to what the problem is? 
> I
> am using maven 3.2.1.
>
> jboss-wfk-quickstarts/contacts-mobile-basic$ mvn clean install -U -e
> [INFO] Error stacktraces are turned on.
> [INFO] Scanning for projects...
> Downloading:
> http://repo.maven.apache.org/maven2/org/jboss/bom/wfk/jboss-javaee-6.0-with-tools/2.5.0-build-2/jboss-javaee-6.0-with-tools-2.5.0-build-2.pom
> Downloading:
> http://repo.maven.apache.org/maven2/org/jboss/bom/eap/jboss-javaee-6.0-with-hibernate/6.2.0.GA/jboss-javaee-6.0-with-hibernate-6.2.0.GA.pom
> [ERROR] The build could not read 1 project -> [Help 1]
> org.apache.maven.project.ProjectBuildingException: Some problems were
> encountered while processing the POMs:
> [ERROR] Non-resolvable import POM: Could not find artifact
> org.jboss.bom.wfk:jboss-javaee-6.0-with-tools:pom:2.5.0-build-2 in central
> (http://repo.maven.apache.org/maven2) @ line 72, column 25
> [ERROR] Non-resolvable import POM: Could not find artifact
> org.jboss.bom.eap:jboss-javaee-6.0-with-hibernate:pom:6.2.0.GA in central
> (http://repo.maven.apache.org/maven2) @ line 79, column 25
> [ERROR] 'dependencies.dependency.version' for javax.enterprise:cdi-api:jar
> is missing. @ line 92, column 21
> [ERROR] 'dependencies.dependency.version' for
> org.jboss.spec.javax.annotation:jboss-annotations-api_1.1_spec:jar is
> missing. @ line 99, column 21
> [ERROR] 'dependencies.dependency.version' for
> org.jboss.spec.javax.ws.rs:jboss-jaxrs-api_1.1_spec:jar is missing. @ line
> 106, column 21
> [ERROR] 'dependencies.dependency.version' for
> org.hibernate.javax.persistence:hibernate-jpa-2.0-api:jar is missing. @ 
> line
> 113, column 21
> [ERROR] 'dependencies.dependency.version' for
> org.jboss.spec.javax.ejb:jboss-ejb-api_3.1_spec:jar is missing. @ line 
> 120,
> column 21
> [ERROR] 'dependencies.dependency.version' for
> org.jboss.spec.javax.servlet:jboss-servlet-api_3.0_spec:jar is missing. @
> line 127, column 21
> [ERROR] 'dependencies.dependency.version' for
> org.hibernate:hibernate-validator:jar is missing. @ line 136, column 21
> [ERROR] 'dependencies.dependency.version' for
> org.hibernate:hibernate-jpamodelgen:jar is missing. @ line 151, column 21
> [ERROR] 'dependencies.dependency.version' for junit:junit:jar is missing. 
> @
> line 158, column 21
> [ERROR] 'dependencies.dependency.version' for
> org.jboss.arquillian.junit:arquillian-junit-container:jar is missing. @ 
> line
> 166, column 21
> [ERROR] 'dependencies.dependency.version' for
> org.jboss.arquillian.protocol:arquillian-protocol-servlet:jar is missing. 
> @
> line 172, column 21
>
>
>
> -- 
> View this message in context: 
> http://aerogear-dev.1069024.n5.nabble.com/Errors-building-contacts-mobile-basic-Please-help-tp8110.html
> Sent from the aerogear-dev mailing list archive at Nabble.com.
> _______________________________________________
> aerogear-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

  _____

If you reply to this email, your message will be added to the discussion 
below:

http://aerogear-dev.1069024.n5.nabble.com/Errors-building-contacts-mobile-basic-Please-help-tp8110p8111.html

To start a new topic under aerogear-dev, email 
ml-node+s1069024n1h46 at n5.nabble.com
To unsubscribe from aerogear-dev, click here 
<http://aerogear-dev.1069024.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=1&code=am93aWxzb25AcmVkaGF0LmNvbXwxfC0xNTQxNTU0OTE2> 
.
 <http://aerogear-dev.1069024.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>NAML



--
View this message in context: http://aerogear-dev.1069024.n5.nabble.com/Errors-building-contacts-mobile-basic-Please-help-tp8110p8114.html
Sent from the aerogear-dev mailing list archive at Nabble.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140608/3be075d5/attachment.html 

From keith at kdmooreconsulting.com  Sun Jun  8 23:29:59 2014
From: keith at kdmooreconsulting.com (keithdmoore94)
Date: Sun, 8 Jun 2014 20:29:59 -0700 (PDT)
Subject: [aerogear-dev] Errors building contacts-mobile-basic - Please
 help
In-Reply-To: <a62c2ede.00001be8.00000077@AMENTRAR978LMH>
References: <1402208768808-8110.post@n5.nabble.com>
	<F3AC052D-0647-4B4A-8713-0B1D04C5B74B@gmail.com>
	<a62c2ede.00001be8.00000077@AMENTRAR978LMH>
Message-ID: <1402284599918-8115.post@n5.nabble.com>

I was able to build the contacts-mobile-basic app in 
https://github.com/jboss-developer/jboss-wfk-quickstarts

The problem was that I needed to use the contributor-settings.xml instead of
the settings.xml in the root of the quickstart_home directory.  Thanks for
your help.



--
View this message in context: http://aerogear-dev.1069024.n5.nabble.com/Errors-building-contacts-mobile-basic-Please-help-tp8110p8115.html
Sent from the aerogear-dev mailing list archive at Nabble.com.

From yagyesh.agrawal at itpeoplecorp.com  Mon Jun  9 02:40:49 2014
From: yagyesh.agrawal at itpeoplecorp.com (Yagyesh)
Date: Sun, 8 Jun 2014 23:40:49 -0700 (PDT)
Subject: [aerogear-dev] Possible error in oauth2Type method in AGAuthorizer.m
Message-ID: <1402296049496-8116.post@n5.nabble.com>

I'm working on an example using auth functionality of AeroGear. The method
oauth2Type is currently implemented as follows:

- (NSString*)oauth2Type:(AGAuthzConfiguration*)config {
    if ([*config.authzEndpoint* rangeOfString:@"facebook"].location !=
NSNotFound) {
        return @"AG_OAUTH2_FACEBOOK";
    }
    return @"AG_OAUTH2";
}

Now, config.authzEndpoint will have values like "/o/oauth2/auth" or maybe
"/dialog/oauth" in case of facebook. Thus the check above will always result
in false & the return type will always be "AG_OAUTH2". 

Shouldnt the method be instead checking *config.baseURL.host* ? 



--
View this message in context: http://aerogear-dev.1069024.n5.nabble.com/Possible-error-in-oauth2Type-method-in-AGAuthorizer-m-tp8116.html
Sent from the aerogear-dev mailing list archive at Nabble.com.

From matzew at apache.org  Mon Jun  9 04:11:08 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Mon, 9 Jun 2014 10:11:08 +0200
Subject: [aerogear-dev] Errors building contacts-mobile-basic - Please
	help
In-Reply-To: <F3AC052D-0647-4B4A-8713-0B1D04C5B74B@gmail.com>
References: <1402208768808-8110.post@n5.nabble.com>
	<F3AC052D-0647-4B4A-8713-0B1D04C5B74B@gmail.com>
Message-ID: <CAAg5f2RrnO9rqWKZTyyErhRqdHjEXyUxw9+87AP79OeiqxuO+w@mail.gmail.com>

On Sunday, June 8, 2014, S?bastien Blanc <scm.blanc at gmail.com> wrote:

> Hi,
> Have you changed your maven settings.xml as explained in the readme
> (section "configure maven")?
> Btw, I see that you are trying to build my fork ,


Sebi,
shouldn't we promote our own repo instead of private forks (unless they
contain relevant fixes)?

https://github.com/aerogear/aerogear-push-quickstarts/tree/master/server





> I haven't updated it since a long time and depending on what you are
> trying to do it would be better to to take a more recent one.
> Envoy? de mon iPhone
>
> > Le 8 juin 2014 ? 08:26, keithdmoore94 <keith at kdmooreconsulting.com
> <javascript:;>> a ?crit :
> >
> > When trying to build the contacts-mobile-basic app in
> > https://github.com/sebastienblanc/jboss-wfk-quickstarts.git
> >
> > Below is the stacktrace.  Anybody have a clue as to what the problem is?
>  I
> > am using maven 3.2.1.
> >
> > jboss-wfk-quickstarts/contacts-mobile-basic$ mvn clean install -U -e
> > [INFO] Error stacktraces are turned on.
> > [INFO] Scanning for projects...
> > Downloading:
> >
> http://repo.maven.apache.org/maven2/org/jboss/bom/wfk/jboss-javaee-6.0-with-tools/2.5.0-build-2/jboss-javaee-6.0-with-tools-2.5.0-build-2.pom
> > Downloading:
> >
> http://repo.maven.apache.org/maven2/org/jboss/bom/eap/jboss-javaee-6.0-with-hibernate/6.2.0.GA/jboss-javaee-6.0-with-hibernate-6.2.0.GA.pom
> > [ERROR] The build could not read 1 project -> [Help 1]
> > org.apache.maven.project.ProjectBuildingException: Some problems were
> > encountered while processing the POMs:
> > [ERROR] Non-resolvable import POM: Could not find artifact
> > org.jboss.bom.wfk:jboss-javaee-6.0-with-tools:pom:2.5.0-build-2 in
> central
> > (http://repo.maven.apache.org/maven2) @ line 72, column 25
> > [ERROR] Non-resolvable import POM: Could not find artifact
> > org.jboss.bom.eap:jboss-javaee-6.0-with-hibernate:pom:6.2.0.GA in
> central
> > (http://repo.maven.apache.org/maven2) @ line 79, column 25
> > [ERROR] 'dependencies.dependency.version' for
> javax.enterprise:cdi-api:jar
> > is missing. @ line 92, column 21
> > [ERROR] 'dependencies.dependency.version' for
> > org.jboss.spec.javax.annotation:jboss-annotations-api_1.1_spec:jar is
> > missing. @ line 99, column 21
> > [ERROR] 'dependencies.dependency.version' for
> > org.jboss.spec.javax.ws.rs:jboss-jaxrs-api_1.1_spec:jar is missing. @
> line
> > 106, column 21
> > [ERROR] 'dependencies.dependency.version' for
> > org.hibernate.javax.persistence:hibernate-jpa-2.0-api:jar is missing. @
> line
> > 113, column 21
> > [ERROR] 'dependencies.dependency.version' for
> > org.jboss.spec.javax.ejb:jboss-ejb-api_3.1_spec:jar is missing. @ line
> 120,
> > column 21
> > [ERROR] 'dependencies.dependency.version' for
> > org.jboss.spec.javax.servlet:jboss-servlet-api_3.0_spec:jar is missing. @
> > line 127, column 21
> > [ERROR] 'dependencies.dependency.version' for
> > org.hibernate:hibernate-validator:jar is missing. @ line 136, column 21
> > [ERROR] 'dependencies.dependency.version' for
> > org.hibernate:hibernate-jpamodelgen:jar is missing. @ line 151, column 21
> > [ERROR] 'dependencies.dependency.version' for junit:junit:jar is
> missing. @
> > line 158, column 21
> > [ERROR] 'dependencies.dependency.version' for
> > org.jboss.arquillian.junit:arquillian-junit-container:jar is missing. @
> line
> > 166, column 21
> > [ERROR] 'dependencies.dependency.version' for
> > org.jboss.arquillian.protocol:arquillian-protocol-servlet:jar is
> missing. @
> > line 172, column 21
> >
> >
> >
> > --
> > View this message in context:
> http://aerogear-dev.1069024.n5.nabble.com/Errors-building-contacts-mobile-basic-Please-help-tp8110.html
> > Sent from the aerogear-dev mailing list archive at Nabble.com.
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at list



-- 
Sent from Gmail Mobile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140609/59518570/attachment-0001.html 

From scm.blanc at gmail.com  Mon Jun  9 04:57:46 2014
From: scm.blanc at gmail.com (Sebastien Blanc)
Date: Mon, 9 Jun 2014 10:57:46 +0200
Subject: [aerogear-dev] Errors building contacts-mobile-basic - Please
	help
In-Reply-To: <CAAg5f2RrnO9rqWKZTyyErhRqdHjEXyUxw9+87AP79OeiqxuO+w@mail.gmail.com>
References: <1402208768808-8110.post@n5.nabble.com>
	<F3AC052D-0647-4B4A-8713-0B1D04C5B74B@gmail.com>
	<CAAg5f2RrnO9rqWKZTyyErhRqdHjEXyUxw9+87AP79OeiqxuO+w@mail.gmail.com>
Message-ID: <CAD_dpu39aiw+7J0AXe7E6YzxEMr_0OZ2OfoKOd5DjKs23KDyvw@mail.gmail.com>

On Mon, Jun 9, 2014 at 10:11 AM, Matthias Wessendorf <matzew at apache.org>
wrote:

>
>
> On Sunday, June 8, 2014, S?bastien Blanc <scm.blanc at gmail.com> wrote:
>
>> Hi,
>> Have you changed your maven settings.xml as explained in the readme
>> (section "configure maven")?
>> Btw, I see that you are trying to build my fork ,
>
>
> Sebi,
> shouldn't we promote our own repo instead of private forks (unless they
> contain relevant fixes)?
>
> https://github.com/aerogear/aerogear-push-quickstarts/tree/master/server
>
+1 My first answer was supposed to point to our official repo but for some
reasons I forgot (probably because answering a Sunday morning ;) )


>
>
>
>
>
>> I haven't updated it since a long time and depending on what you are
>> trying to do it would be better to to take a more recent one.
>> Envoy? de mon iPhone
>>
>> > Le 8 juin 2014 ? 08:26, keithdmoore94 <keith at kdmooreconsulting.com> a
>> ?crit :
>> >
>> > When trying to build the contacts-mobile-basic app in
>> > https://github.com/sebastienblanc/jboss-wfk-quickstarts.git
>> >
>> > Below is the stacktrace.  Anybody have a clue as to what the problem
>> is?  I
>> > am using maven 3.2.1.
>> >
>> > jboss-wfk-quickstarts/contacts-mobile-basic$ mvn clean install -U -e
>> > [INFO] Error stacktraces are turned on.
>> > [INFO] Scanning for projects...
>> > Downloading:
>> >
>> http://repo.maven.apache.org/maven2/org/jboss/bom/wfk/jboss-javaee-6.0-with-tools/2.5.0-build-2/jboss-javaee-6.0-with-tools-2.5.0-build-2.pom
>> > Downloading:
>> >
>> http://repo.maven.apache.org/maven2/org/jboss/bom/eap/jboss-javaee-6.0-with-hibernate/6.2.0.GA/jboss-javaee-6.0-with-hibernate-6.2.0.GA.pom
>> > [ERROR] The build could not read 1 project -> [Help 1]
>> > org.apache.maven.project.ProjectBuildingException: Some problems were
>> > encountered while processing the POMs:
>> > [ERROR] Non-resolvable import POM: Could not find artifact
>> > org.jboss.bom.wfk:jboss-javaee-6.0-with-tools:pom:2.5.0-build-2 in
>> central
>> > (http://repo.maven.apache.org/maven2) @ line 72, column 25
>> > [ERROR] Non-resolvable import POM: Could not find artifact
>> > org.jboss.bom.eap:jboss-javaee-6.0-with-hibernate:pom:6.2.0.GA in
>> central
>> > (http://repo.maven.apache.org/maven2) @ line 79, column 25
>> > [ERROR] 'dependencies.dependency.version' for
>> javax.enterprise:cdi-api:jar
>> > is missing. @ line 92, column 21
>> > [ERROR] 'dependencies.dependency.version' for
>> > org.jboss.spec.javax.annotation:jboss-annotations-api_1.1_spec:jar is
>> > missing. @ line 99, column 21
>> > [ERROR] 'dependencies.dependency.version' for
>> > org.jboss.spec.javax.ws.rs:jboss-jaxrs-api_1.1_spec:jar is missing. @
>> line
>> > 106, column 21
>> > [ERROR] 'dependencies.dependency.version' for
>> > org.hibernate.javax.persistence:hibernate-jpa-2.0-api:jar is missing. @
>> line
>> > 113, column 21
>> > [ERROR] 'dependencies.dependency.version' for
>> > org.jboss.spec.javax.ejb:jboss-ejb-api_3.1_spec:jar is missing. @ line
>> 120,
>> > column 21
>> > [ERROR] 'dependencies.dependency.version' for
>> > org.jboss.spec.javax.servlet:jboss-servlet-api_3.0_spec:jar is missing.
>> @
>> > line 127, column 21
>> > [ERROR] 'dependencies.dependency.version' for
>> > org.hibernate:hibernate-validator:jar is missing. @ line 136, column 21
>> > [ERROR] 'dependencies.dependency.version' for
>> > org.hibernate:hibernate-jpamodelgen:jar is missing. @ line 151, column
>> 21
>> > [ERROR] 'dependencies.dependency.version' for junit:junit:jar is
>> missing. @
>> > line 158, column 21
>> > [ERROR] 'dependencies.dependency.version' for
>> > org.jboss.arquillian.junit:arquillian-junit-container:jar is missing. @
>> line
>> > 166, column 21
>> > [ERROR] 'dependencies.dependency.version' for
>> > org.jboss.arquillian.protocol:arquillian-protocol-servlet:jar is
>> missing. @
>> > line 172, column 21
>> >
>> >
>> >
>> > --
>> > View this message in context:
>> http://aerogear-dev.1069024.n5.nabble.com/Errors-building-contacts-mobile-basic-Please-help-tp8110.html
>> > Sent from the aerogear-dev mailing list archive at Nabble.com.
>> > _______________________________________________
>> > aerogear-dev mailing list
>> > aerogear-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at list
>
>
>
> --
> Sent from Gmail Mobile
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140609/7a6ea284/attachment.html 

From lukas.fryc at gmail.com  Mon Jun  9 05:38:47 2014
From: lukas.fryc at gmail.com (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=)
Date: Mon, 9 Jun 2014 11:38:47 +0200
Subject: [aerogear-dev] aerogear-js CouchDB data-manager adapter
In-Reply-To: <CAN5SbcYYKjc962J6M4rFpK5N0OBeoW=qvVwKYDHnjoYpei9ByQ@mail.gmail.com>
References: <CAN5SbcaXr8hv=36Vb-yMGYgAE+O1W8F3_+d9_oOufFVwuQGCyw@mail.gmail.com>
	<CAEroY34ms4KWzV8uKh9AK_iuBxtO6xgQ8xFjBf3=DP0+Mij2Ag@mail.gmail.com>
	<17E821F0-B658-4AD2-B770-D204232D95C7@redhat.com>
	<CAN5SbcYYKjc962J6M4rFpK5N0OBeoW=qvVwKYDHnjoYpei9ByQ@mail.gmail.com>
Message-ID: <CAEroY34t1MhfcqrH1xahrBMuL417HTUth4f5s=P50MGrtH_whA@mail.gmail.com>

He guys,

resurrecting this topic,

I wonder whether it would make sense to do PouchDB adapter,
which is client-side API-compatible version of CouchDB,
that can be synchronized against CouchDB (due to REST API compatibility).

Wdyt?

~ Lukas


On Wed, May 28, 2014 at 9:19 AM, tolis emmanouilidis <tolisemm at gmail.com>
wrote:

> Thank you both.
>
> I agree to freeze the adapter's development until datasync is discussed.
>
> comments inline
>
> 2014-05-27 16:12 GMT+03:00 Lucas Holmquist <lholmqui at redhat.com>:
>
> Cool Stuff,  i will take a look
>>
>> On May 26, 2014, at 7:55 AM, Luk?? Fry? <lukas.fryc at gmail.com> wrote:
>>
>> Hey Tolis,
>>
>> great job with the adapter!
>>
>>
>> a) remove()
>>
>> since there are obviously many ways how to achieve "delete all docs",
>> I believe it's up to user to choose the way he wants the docs deleted
>> i.e. it could be up to Data Manager configuration whether data will be
>> deleted with or without a history loss (aka wipe out). wdyt?
>>
>> +1
>
> investigation is needed to find out if there are any best practices
>
>
>>
>> b) Filtering
>>
>> It would be pretty overwhelming for a user to create a view per
>> particular use of the filter() method, since it can have pretty arbitrary
>> form.
>> We are also able to create temporary views, but that requires you to
>> perform one additional POST request and it is costly.
>>
>> I think it's not overwelming for a user to create the view manually.
> CouchDB filtering is based on the key (simple or complex). IMO the ability
> to search/filter different fields (which are not part of a complex key) and
> create a view in each request, has no meaning in CouchDB. If a user has a
> such requirement and data-queries are changing very often, then he should
> consider using a different NoSQL db. CouchDB serves specific purposes and a
> possible AeroGear JS CouchDB adapter should not offer functionality which
> CouchDB is not designed to serve.
>
> Temporary views are not a solution, for sure. They are one-off queries,
> meaning that they are computed in each call (expensive and slow). CouchDB
> docs suggest to use them for development purposes.
>
>
>> Are we able to come up with a common view definition that would cover all
>> the filtering capabilities - i.e. generic aerogear-filter view?
>> Something that user would define once and all cases would be covered.
>> I have not practically played with CouchDB, but according the docs it
>> could be somehow possible.
>>
>>
>>
>> Btw as I think about it, there might be lack of function for limiting
>> what data to transfer.
>> i.e. Filtering API allows you to select just particular docs, but it does
>> not help you to avoid what will be transferred.
>>
>> All the Data Managers so far are local ones, CouchDB is a first one that
>> actually transfers data from the wire.
>>
>>
>> This is a concern i had when created the JIRA,   This ?adapter? might be
>> more appropriate for DataSync( or whatever we are calling it ).  I know we
>> were looking at couchDB as a possible backend.
>>
>> I?m wondering if we should hold off for now,  and just keep DataManager
>> client side storage only for the moment.  I think the fallback
>> functionality will be non-trivial
>>
>> agreed
>
>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140609/1cc72740/attachment.html 

From yagyesh.agrawal at itpeoplecorp.com  Mon Jun  9 06:18:47 2014
From: yagyesh.agrawal at itpeoplecorp.com (Yagyesh)
Date: Mon, 9 Jun 2014 03:18:47 -0700 (PDT)
Subject: [aerogear-dev] Possible error in oauth2Type method in
	AGAuthorizer.m
In-Reply-To: <1402296049496-8116.post@n5.nabble.com>
References: <1402296049496-8116.post@n5.nabble.com>
Message-ID: <1402309127048-8120.post@n5.nabble.com>

I was following the GoogleDrive example & trying to replicate the same for
Facebook. However, it seems like for Facebook authentication, trick is to
not have base url and instead give complete path for authzEndpoint,
accessTokenEndpoint etc. 

Btw, Is there any AeroGear Facebook example for newbie's like me?



--
View this message in context: http://aerogear-dev.1069024.n5.nabble.com/Possible-error-in-oauth2Type-method-in-AGAuthorizer-m-tp8116p8120.html
Sent from the aerogear-dev mailing list archive at Nabble.com.

From daniel at passos.me  Mon Jun  9 09:55:43 2014
From: daniel at passos.me (Daniel Passos)
Date: Mon, 9 Jun 2014 10:55:43 -0300
Subject: [aerogear-dev] Possible error in oauth2Type method in
	AGAuthorizer.m
In-Reply-To: <1402309127048-8120.post@n5.nabble.com>
References: <1402296049496-8116.post@n5.nabble.com>
	<1402309127048-8120.post@n5.nabble.com>
Message-ID: <CAKjsGbuREKMfm-MZDroZddw6EDeQ632nUdzzRjvq+fwFSt+BbQ@mail.gmail.com>

I suppose are you talking about AGIOS, Right?

So, Corrine wrote a awesome post[1] about OAuth2 in Facebook

[1]
http://corinnekrych.blogspot.com.br/2014/06/different-ways-to-manage-facebook.html

-- Passos


On Mon, Jun 9, 2014 at 7:18 AM, Yagyesh <yagyesh.agrawal at itpeoplecorp.com>
wrote:

> I was following the GoogleDrive example & trying to replicate the same for
> Facebook. However, it seems like for Facebook authentication, trick is to
> not have base url and instead give complete path for authzEndpoint,
> accessTokenEndpoint etc.
>
> Btw, Is there any AeroGear Facebook example for newbie's like me?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140609/00aaa7b4/attachment-0001.html 

From kpiwko at redhat.com  Mon Jun  9 10:41:13 2014
From: kpiwko at redhat.com (Karel Piwko)
Date: Mon, 9 Jun 2014 16:41:13 +0200
Subject: [aerogear-dev] Improving Android HelloPush demo experience in
 Eclipse - PR
In-Reply-To: <CAKjsGbvBb=FqrLyA7eC6-=wQ85HZZ39340mxoWEnv93Z9cBuFA@mail.gmail.com>
References: <20140606120528.57300bc3@kapy-ntb-x220>
	<CAKjsGbvBb=FqrLyA7eC6-=wQ85HZZ39340mxoWEnv93Z9cBuFA@mail.gmail.com>
Message-ID: <20140609164113.37827987@kapy-ntb-x220>

On Fri, 6 Jun 2014 12:22:43 -0300
Daniel Passos <daniel at passos.me> wrote:

> Answer inline
> 
> On Fri, Jun 6, 2014 at 7:05 AM, Karel Piwko <kpiwko at redhat.com> wrote:
> 
> > Hi All,
> >
> > I went through Android demo (and JBDS) and created following PR:
> >
> > https://github.com/aerogear/aerogear-push-helloworld/pull/18
> >
> > Let me know if you want to have separate PRs per commit. Goal was to have
> > example working in Eclipse/JBDS + ADT. There is still manual steps to do
> > and
> > an error I was not able to fix it completely, investigating.
> >
> > As per commit:
> >
> > 1/ Fixes Eclipse error marker for maven-android-plugin. AAR is not used,
> > so it
> > is fine.
> >
> > 2/ Quickstart/demos should not have any parent, Maven best practice. Check
> > JDF
> > quickstarts. Quickstart is an example and it is used to by user to scaffold
> > their own apps. We don't want them to use ag-parent but just ag-bom.
> >
> 
> Not sure why it's so bad. parent-pom is releases in maven central so, the
> community can use it. I think a notice in the README explaining why we are
> using it is good.

Well, official documentation I was able to find is here:

https://github.com/jboss-developer/jboss-eap-quickstarts/blob/6.3.x-develop/CONTRIBUTING.md

Reasons would be:
* Example/Quickstart should be standalone
** Any change in parent might break a quickstart 
** If user does not add parent his app might get broken without obvious reason
* Single inheritance issue
** Users might have they own parents
* Aligning with JDF experience

> 
> parent-pom has some nice plugins like formatter, license header, etc...
> Should we do it manually or put this plugins in the project pom?

That's the downside. I believe that only plugins that are relevant for users
should be there. JDF has tooling to check QS stuff -
http://www.jboss.org/jdf/quickstarts/qstools/. CC'ed Rafael, I can help
with creating a CI job to validate quickstarts. Hopefully we'll be able to run
QS tooling in Travis.

> 
> 
> > 3/ If project.properties is missing, Eclipse is not able to add Android
> > SDK to
> > build path. I've set it to API 19. This means that user has to point ADT to
> > Android SDK with API 19 installed. This is also version Eclipse will use
> > for
> > code suggestion/autocompletion/build in IDE. Should have been API 10, I'm
> > not
> > sure here.
> >
> 
> Always use the same of targetSdkVersion. So, it's correctly ;)

I was just lucky then, odds were 1:2 ;-)

> 
> 
> > 4/ Dependencies in <dependencyManagement> should not define any scope with
> > exception of *import*. Maven best practice.
> >
> 
> +1 Good catch.
> 
> 
> > 5/ If user don't provide UNIFIED_PUSH_URL, application fails due to
> > RuntimeException. I've added catch for IAE and Toast, however I believe
> > there
> > should be a better way how to indicate that to user. IAE is quite generic
> > and
> > fired from URLUtils in GCM registar. I'll file an issue to improve that.
> >
> 
> +1
> 
> 
> > 6/ /bin directory is used by default by Eclipse to host temporary build
> >
> 
> +1 Maybe is a good ideia copy the cookbook .gitignore
> https://github.com/aerogear/aerogear-android-cookbook/blob/master/.gitignore
> 
+1

> After these steps, I needed to follow these manual steps:
> >
> > a/ Import android-support-v7-appcompat from Android SDK into workspace as
> > Android project
> > b/ Import hellopush/android as Maven project
> > c/ Add android-support-v7-appcompat as library in Android tab of project
> > properties
> >
> > Now, I can edit the code. However, I can't use Run As/Android
> > Application still, likely due to http://tinypic.com/r/260ejpl/8
> 
> 
> Not sure what is going on, but I'll take a look at it next week. Could you
> fire a jira for me?

Here you are: https://issues.jboss.org/browse/AGPUSH-708

> 
> 
> > I'd appreciate if somebody could verify it is still working with
> > AndroidStudio.
> >
> 
> I just run it in Android Studio and IntelliJ. I don't know how, but all
> still working :P

Great. This explains why IntelliJ is so popular, at least to me ;-)

> 
> Thanks,
> >
> > Karel


From daniel at passos.me  Mon Jun  9 11:27:32 2014
From: daniel at passos.me (Daniel Passos)
Date: Mon, 9 Jun 2014 12:27:32 -0300
Subject: [aerogear-dev] Team meeting
In-Reply-To: <CAFJm-3HZWXpoMXFUKHLcfGNpTYr76R17dd_SxSS8-Ek=nqcxWA@mail.gmail.com>
References: <CAFJm-3HZWXpoMXFUKHLcfGNpTYr76R17dd_SxSS8-Ek=nqcxWA@mail.gmail.com>
Message-ID: <CAKjsGbtGrFXwrEDSDaxpboOcrhdi=mHjd9G7Th5QpD70cbGCjw@mail.gmail.com>

Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-06-09-13.43.html
Minutes (text):
http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-06-09-13.43.txt
[Log:
http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-06-09-13.43.log.html


On Sun, Jun 8, 2014 at 12:37 PM, Daniel Bevenius <daniel.bevenius at gmail.com>
wrote:

> Agenda:
> http://oksoclap.com/p/aerogear-team-mgt-20140609
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140609/533ab41d/attachment.html 

From bruno at abstractj.org  Mon Jun  9 12:05:09 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Mon, 9 Jun 2014 13:05:09 -0300
Subject: [aerogear-dev] admin-ui and Keycloak.js integration
In-Reply-To: <CAD_dpu0PN6qfSajHW-qV24EG-CPNQNYCmW8tsi1L6tGStGgjqg@mail.gmail.com>
References: <20140606160512.GA1854@abstractj.org>
	<CAD_dpu0PN6qfSajHW-qV24EG-CPNQNYCmW8tsi1L6tGStGgjqg@mail.gmail.com>
Message-ID: <20140609160509.GA14823@abstractj.org>

Ahoy and thank you.

I was looking and testing your latest changes, in the very beginning of
this integration I also tried to include Angular.js' interceptors and
all the Angular-isms available.

The problem is the fact of hiding the probable bug. If you change the
endpoint to something like:

@GET
@Produces(MediaType.APPLICATION_JSON)
public Response listAllPushApplications(@Context
  HttpServletRequest request) {
    return Response.ok(pushAppService.findAllPushApplicationsForDeveloper("admin")).build();
}

or

@GET
@Produces(MediaType.APPLICATION_JSON)
public Response listAllPushApplications(@Context
  HttpServletRequest request) {
    return Response.ok("guacamole").build();
}

The issue still persists. I'll keep investigating.


On 2014-06-07, Sebastien Blanc wrote:
> Hi my friend !
>
> Just to let you know I started to look at your branch and indeed you better
> not be epileptic to survive the crazy reloads ;)
> I have nothing to push right now but I have some ideas :
>
> * Like you mention, the redirect and main route broke the stuff. So, I
> think we should remove that and do the initial redirect in the success
> callback of the keycloakAuth.init call. I have a local branch where I
> manage to do that, but it's really hacky and I face another issue , the
> first next REST call fails because there are not auth info. But ! This is
> there where we have to introduce the Auth interceptor like here
> https://github.com/keycloak/keycloak/blob/master/examples/demo-template/angular-product-app/src/main/webapp/js/app.js#L43-L60
>
> I think based on this, we should be able to find a solution. I will try to
> push my work ASAP and maybe some dudes for KC could give us some hints as
> well.
>
> Have a good weekend !
>
> sebi
>
>
>
> On Fri, Jun 6, 2014 at 6:05 PM, Bruno Oliveira <bruno at abstractj.org> wrote:
>
> > Good morning,
> >
> > I'm struggling to integrate Keycloak.js with our admin-ui. Everything
> > works perfectly well out of admin-ui with UPS and Angular.js as you
> > might notice here:
> >
> > https://github.com/abstractj/aerogear-unifiedpush-server/tree/keycloak-angular
> >
> > The issue lies when I enable the routes related with redirect and
> > MainController:
> >
> > https://github.com/abstractj/aerogear-unifiedpush-server/tree/keycloak_angular_integration
> > .
> > Just open http://localhost:8080/ag-push and watch your browser reload
> > like crazy. When the main route and redirect are disable, everything goes
> > well:
> >
> > https://github.com/abstractj/aerogear-unifiedpush-server/commit/dd9438c6503061fba8aa0e0d77973971888e9379
> >
> >
> > At first glance it doesn't sound to be a problem on KC.js, once already
> > works with Angular.js:
> >
> > https://github.com/keycloak/keycloak/tree/master/examples/demo-template/angular-product-app
> > .
> >
> > If you have any idea, help is appreciated.
> >
> > --
> >
> > abstractj
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >

> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


--

abstractj

From bruno at abstractj.org  Mon Jun  9 12:27:02 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Mon, 9 Jun 2014 13:27:02 -0300
Subject: [aerogear-dev] UnifiedPush server - Staging dates
Message-ID: <20140609162702.GB14823@abstractj.org>

Good morning,

I would like to stage the Push server on Friday (13 Jun) or Monday (16
Jun). What do you think?

--

abstractj

From bruno at abstractj.org  Mon Jun  9 12:31:37 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Mon, 9 Jun 2014 13:31:37 -0300
Subject: [aerogear-dev] Unified Push responds with 404 if no installations
 exist for a variant
Message-ID: <20140609163137.GC14823@abstractj.org>

Good morning, any feedback on it?
https://issues.jboss.org/browse/AGPUSH-680

--

abstractj

From yagyesh.agrawal at itpeoplecorp.com  Tue Jun 10 02:06:58 2014
From: yagyesh.agrawal at itpeoplecorp.com (Yagyesh)
Date: Mon, 9 Jun 2014 23:06:58 -0700 (PDT)
Subject: [aerogear-dev] Possible error in oauth2Type method in
 AGAuthorizer.m
In-Reply-To: <CAKjsGbuREKMfm-MZDroZddw6EDeQ632nUdzzRjvq+fwFSt+BbQ@mail.gmail.com>
References: <CAKjsGbuREKMfm-MZDroZddw6EDeQ632nUdzzRjvq+fwFSt+BbQ@mail.gmail.com>
Message-ID: <1402380418714-8127.post@n5.nabble.com>

The link really helped... Thanks.



--
View this message in context: http://aerogear-dev.1069024.n5.nabble.com/Re-aerogear-dev-Possible-error-in-oauth2Type-method-in-AGAuthorizer-m-tp8121p8127.html
Sent from the aerogear-dev mailing list archive at Nabble.com.

From corinnekrych at gmail.com  Tue Jun 10 02:46:19 2014
From: corinnekrych at gmail.com (Corinne Krych)
Date: Tue, 10 Jun 2014 08:46:19 +0200
Subject: [aerogear-dev] Possible error in oauth2Type method in
	AGAuthorizer.m
In-Reply-To: <1402380418714-8127.post@n5.nabble.com>
References: <CAKjsGbuREKMfm-MZDroZddw6EDeQ632nUdzzRjvq+fwFSt+BbQ@mail.gmail.com>
	<1402380418714-8127.post@n5.nabble.com>
Message-ID: <EAD63BE4-F6C9-4004-9612-A6F412940010@gmail.com>

Hello

Actually Facebook OAuth2 adapter is a bright new feature that is found on master (plus some PR to be merged this week), it will be part of 1.6 release coming out very soon.

I will update cookbook as we added automatic facebook adapter recognition [1]. As you notice because fb is using 2 different base URL, you have to use full path in endpoint at least for one of the url. See not yet merged PR [2]

Thanks for the feedback, stay tuned for trying out our 1.6 release.
++
Corinne
[1] https://github.com/aerogear/aerogear-ios/blob/master/AeroGear-iOS/security/Authorizer/AGAuthorizer.m#L79
[2] https://github.com/cvasilak/aerogear-ios-cookbook/blob/AGIOS-190.account/Shoot/Shoot/AGShootViewController.m#L105

On 10 Jun 2014, at 08:06, Yagyesh <yagyesh.agrawal at itpeoplecorp.com> wrote:

> The link really helped... Thanks.
> 
> 
> 
> --
> View this message in context: http://aerogear-dev.1069024.n5.nabble.com/Re-aerogear-dev-Possible-error-in-oauth2Type-method-in-AGAuthorizer-m-tp8121p8127.html
> Sent from the aerogear-dev mailing list archive at Nabble.com.
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev



From scm.blanc at gmail.com  Tue Jun 10 06:02:17 2014
From: scm.blanc at gmail.com (Sebastien Blanc)
Date: Tue, 10 Jun 2014 12:02:17 +0200
Subject: [aerogear-dev] UnifiedPush server - Staging dates
In-Reply-To: <20140609162702.GB14823@abstractj.org>
References: <20140609162702.GB14823@abstractj.org>
Message-ID: <CAD_dpu1ynXMURMK2__Q107q_VofmcA+aMzOcxJ_863m5y3yJ3g@mail.gmail.com>

TBH I think Friday is not really realistic, looking at what is still open ,
wdyt ?



On Mon, Jun 9, 2014 at 6:27 PM, Bruno Oliveira <bruno at abstractj.org> wrote:

> Good morning,
>
> I would like to stage the Push server on Friday (13 Jun) or Monday (16
> Jun). What do you think?
>
> --
>
> abstractj
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140610/2507a583/attachment-0001.html 

From bruno at abstractj.org  Tue Jun 10 06:09:03 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Tue, 10 Jun 2014 07:09:03 -0300
Subject: [aerogear-dev] UnifiedPush server - Staging dates
In-Reply-To: <CAD_dpu1ynXMURMK2__Q107q_VofmcA+aMzOcxJ_863m5y3yJ3g@mail.gmail.com>
References: <20140609162702.GB14823@abstractj.org>
	<CAD_dpu1ynXMURMK2__Q107q_VofmcA+aMzOcxJ_863m5y3yJ3g@mail.gmail.com>
Message-ID: <20140610100903.GA33338@abstractj.org>

Let's schedule to Monday (16 Jun). Does it make sense?

On 2014-06-10, Sebastien Blanc wrote:
> TBH I think Friday is not really realistic, looking at what is still open ,
> wdyt ?
>
>
>
> On Mon, Jun 9, 2014 at 6:27 PM, Bruno Oliveira <bruno at abstractj.org> wrote:
>
> > Good morning,
> >
> > I would like to stage the Push server on Friday (13 Jun) or Monday (16
> > Jun). What do you think?
> >
> > --
> >
> > abstractj
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >

> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


--

abstractj

From yagyesh.agrawal at itpeoplecorp.com  Tue Jun 10 06:31:04 2014
From: yagyesh.agrawal at itpeoplecorp.com (Yagyesh)
Date: Tue, 10 Jun 2014 03:31:04 -0700 (PDT)
Subject: [aerogear-dev] Possible error in oauth2Type method in
 AGAuthorizer.m
In-Reply-To: <EAD63BE4-F6C9-4004-9612-A6F412940010@gmail.com>
References: <CAKjsGbuREKMfm-MZDroZddw6EDeQ632nUdzzRjvq+fwFSt+BbQ@mail.gmail.com>
	<1402380418714-8127.post@n5.nabble.com>
	<EAD63BE4-F6C9-4004-9612-A6F412940010@gmail.com>
Message-ID: <1402396264888-8131.post@n5.nabble.com>

Hello Corinne,

Thanks for the reply. 

I kind of figured out that still features are being added to Facebook OAuth.
For instance, currently I could not do a revoke/deauthorize. Though I was
able to achieve it locally at my end by overriding revokeAccessSuccess in
AGRestOAuth2FacebookModule with something like this:

-(void) revokeAccessSuccess:(void (^)(id object))success
                    failure:(void (^)(NSError *error))failure {
    NSDictionary* paramDict = @{@"access_token":self.session.accessToken};
    [_restClient DELETE:self.revokeTokenEndpoint parameters:paramDict
success:^(NSURLSessionDataTask *task, id responseObject) {
        [self.session saveAccessToken:nil refreshToken:nil expiration:nil];
        if (success) {
            success(nil);
        }
    } failure:^(NSURLSessionDataTask *task, NSError *error) {
        if (failure) {
            failure(error);
        }
    }];
}

Revoke end point looks like this:
"https://graph.facebook.com/me/permissions"


I'm hoping with the 1.6 release even the revoke feature would be available
for Facebook OAuth.

Thanks,
Yagyesh



--
View this message in context: http://aerogear-dev.1069024.n5.nabble.com/Re-aerogear-dev-Possible-error-in-oauth2Type-method-in-AGAuthorizer-m-tp8121p8131.html
Sent from the aerogear-dev mailing list archive at Nabble.com.

From corinnekrych at gmail.com  Tue Jun 10 06:40:44 2014
From: corinnekrych at gmail.com (Corinne Krych)
Date: Tue, 10 Jun 2014 12:40:44 +0200
Subject: [aerogear-dev] Possible error in oauth2Type method in
	AGAuthorizer.m
In-Reply-To: <1402396264888-8131.post@n5.nabble.com>
References: <CAKjsGbuREKMfm-MZDroZddw6EDeQ632nUdzzRjvq+fwFSt+BbQ@mail.gmail.com>
	<1402380418714-8127.post@n5.nabble.com>
	<EAD63BE4-F6C9-4004-9612-A6F412940010@gmail.com>
	<1402396264888-8131.post@n5.nabble.com>
Message-ID: <AD914C85-FB6A-4C5B-95D5-D1F65EE3DB07@gmail.com>

About to merge  PR https://github.com/aerogear/aerogear-ios/pull/130
which should fix it.
Thanks!

++
Corinne

On 10 Jun 2014, at 12:31, Yagyesh <yagyesh.agrawal at itpeoplecorp.com> wrote:

> Hello Corinne,
> 
> Thanks for the reply. 
> 
> I kind of figured out that still features are being added to Facebook OAuth.
> For instance, currently I could not do a revoke/deauthorize. Though I was
> able to achieve it locally at my end by overriding revokeAccessSuccess in
> AGRestOAuth2FacebookModule with something like this:
> 
> -(void) revokeAccessSuccess:(void (^)(id object))success
>                    failure:(void (^)(NSError *error))failure {
>    NSDictionary* paramDict = @{@"access_token":self.session.accessToken};
>    [_restClient DELETE:self.revokeTokenEndpoint parameters:paramDict
> success:^(NSURLSessionDataTask *task, id responseObject) {
>        [self.session saveAccessToken:nil refreshToken:nil expiration:nil];
>        if (success) {
>            success(nil);
>        }
>    } failure:^(NSURLSessionDataTask *task, NSError *error) {
>        if (failure) {
>            failure(error);
>        }
>    }];
> }
> 
> Revoke end point looks like this:
> "https://graph.facebook.com/me/permissions"
> 
> 
> I'm hoping with the 1.6 release even the revoke feature would be available
> for Facebook OAuth.
> 
> Thanks,
> Yagyesh
> 
> 
> 
> --
> View this message in context: http://aerogear-dev.1069024.n5.nabble.com/Re-aerogear-dev-Possible-error-in-oauth2Type-method-in-AGAuthorizer-m-tp8121p8131.html
> Sent from the aerogear-dev mailing list archive at Nabble.com.
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev



From lholmqui at redhat.com  Tue Jun 10 08:24:30 2014
From: lholmqui at redhat.com (Lucas Holmquist)
Date: Tue, 10 Jun 2014 08:24:30 -0400
Subject: [aerogear-dev] UnifiedPush server - Staging dates
In-Reply-To: <20140609162702.GB14823@abstractj.org>
References: <20140609162702.GB14823@abstractj.org>
Message-ID: <51263903-3389-49BC-AC29-20179406ACDD@redhat.com>


On Jun 9, 2014, at 12:27 PM, Bruno Oliveira <bruno at abstractj.org> wrote:

> Good morning,
> 
> I would like to stage the Push server on Friday (13 Jun) or Monday (16
ZOMG. Friday the 13th

> Jun). What do you think?
> 
> --
> 
> abstractj
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


From jbalunas at redhat.com  Tue Jun 10 11:41:31 2014
From: jbalunas at redhat.com (Jay Balunas)
Date: Tue, 10 Jun 2014 11:41:31 -0400
Subject: [aerogear-dev] UnifiedPush server - Staging dates
In-Reply-To: <20140610100903.GA33338@abstractj.org>
References: <20140609162702.GB14823@abstractj.org>
	<CAD_dpu1ynXMURMK2__Q107q_VofmcA+aMzOcxJ_863m5y3yJ3g@mail.gmail.com>
	<20140610100903.GA33338@abstractj.org>
Message-ID: <F71B4FCC-8468-41BC-BA06-93EC5145E07C@redhat.com>

This sounds good to me!

On Jun 10, 2014, at 6:09 AM, Bruno Oliveira <bruno at abstractj.org> wrote:

> Let's schedule to Monday (16 Jun). Does it make sense?
> 
> On 2014-06-10, Sebastien Blanc wrote:
>> TBH I think Friday is not really realistic, looking at what is still open ,
>> wdyt ?
>> 
>> 
>> 
>> On Mon, Jun 9, 2014 at 6:27 PM, Bruno Oliveira <bruno at abstractj.org> wrote:
>> 
>>> Good morning,
>>> 
>>> I would like to stage the Push server on Friday (13 Jun) or Monday (16
>>> Jun). What do you think?
>>> 
>>> --
>>> 
>>> abstractj
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>> 
> 
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> 
> 
> --
> 
> abstractj
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev



From yagyesh.agrawal at itpeoplecorp.com  Wed Jun 11 02:44:23 2014
From: yagyesh.agrawal at itpeoplecorp.com (Yagyesh)
Date: Tue, 10 Jun 2014 23:44:23 -0700 (PDT)
Subject: [aerogear-dev] Observations on iOS OAuth
Message-ID: <1402469063899-8135.post@n5.nabble.com>

I have few observations & suggestions based on the time i spent with OAuth
related code in Aerogear iOS library:

1.
Below is the code snippet from authz method of AGAuthorizer.m:
????????
if(![authzConfig.type isEqualToString:@"AG_OAUTH2_FACEBOOK"] &&
![authzConfig.type isEqualToString:@"AG_OAUTH2"])
        return nil;
    
    authzConfig.type = [self oauth2Type:authzConfig];
????????
As ?type? property is exposed to developers & they may set it in their code,
i feel changing it without giving any info/warning will not be appreciated
by the developers. 

2.
Also, since ?type? is exposed, we can also completely eliminate the need for
setting the correct type via oauth2type method. The list of supported types
can be exposed as string constants or enum, & developers can choose to set
the type based on their requirements. In authz method, we can simply assert
with proper message if type is not set. In my opinion, oauth2type method is
anyways not very robust in determining the correct type & may need to be
changed constantly as we add support for more oauth providers. Also, for
instance if facebook changes the authentication end point and access end
point to use to a common base url, oauth2type method may fail in determining
correct type. This is just an example and probably facebook may never change
anything. But the point i'm trying to make is that allowing developers to
set the type will avoid any issues like this.

3.
Similarly, setting default values in init method of AGAuthzConfiguration.m
is also not very useful. As default values will not work if developers do
not set all the relevant config properties. And since we are setting
defaults, we could not assert to developers in case any mandatory property
is not set. 

4.
If we do want to set defaults, we should have defaults specific to modules.
For example, Facebook OAuth should have its own set of default values for
authzEndPoint, accessTokenEndPoint, revokeEndPoint etc. As values for these
properties may not change with applications, even if developers forget to
set these properties things may just work for them out of the box in most
cases.

5. 
We can have asserts for all mandatory properties that are not set.

Let me know what do you guys think about these.



--
View this message in context: http://aerogear-dev.1069024.n5.nabble.com/Observations-on-iOS-OAuth-tp8135.html
Sent from the aerogear-dev mailing list archive at Nabble.com.


From corinnekrych at gmail.com  Wed Jun 11 03:56:26 2014
From: corinnekrych at gmail.com (Corinne Krych)
Date: Wed, 11 Jun 2014 09:56:26 +0200
Subject: [aerogear-dev] Observations on iOS OAuth
In-Reply-To: <1402469063899-8135.post@n5.nabble.com>
References: <1402469063899-8135.post@n5.nabble.com>
Message-ID: <23330B2D-7F0A-4F4C-946B-0BB6A622F38B@gmail.com>


On 11 Jun 2014, at 08:44, Yagyesh <yagyesh.agrawal at itpeoplecorp.com> wrote:

> I have few observations & suggestions based on the time i spent with OAuth
> related code in Aerogear iOS library:
> 
> 1.
> Below is the code snippet from authz method of AGAuthorizer.m:
> ????????
> if(![authzConfig.type isEqualToString:@"AG_OAUTH2_FACEBOOK"] &&
> ![authzConfig.type isEqualToString:@"AG_OAUTH2"])
>        return nil;
> 
>    authzConfig.type = [self oauth2Type:authzConfig];
> ????????
> As ?type? property is exposed to developers & they may set it in their code,
> i feel changing it without giving any info/warning will not be appreciated
> by the developers. 
> 
> 2.
> Also, since ?type? is exposed, we can also completely eliminate the need for
> setting the correct type via oauth2type method. The list of supported types
> can be exposed as string constants or enum, & developers can choose to set
> the type based on their requirements.

Yep some thing to work a bit more. 
The idea is to have extensible type and let the user develop its own, similar to Android factory using class type. This is tracked by ticket https://issues.jboss.org/browse/AGIOS-154
Refactor will be done in next release.

> In authz method, we can simply assert
> with proper message if type is not set. In my opinion, oauth2type method is
> anyways not very robust in determining the correct type & may need to be
> changed constantly as we add support for more oauth providers. Also, for
> instance if facebook changes the authentication end point and access end
> point to use to a common base url, oauth2type method may fail in determining
> correct type. This is just an example and probably facebook may never change
> anything. But the point i'm trying to make is that allowing developers to
> set the type will avoid any issues like this.
> 
> 3.
> Similarly, setting default values in init method of AGAuthzConfiguration.m
> is also not very useful. As default values will not work if developers do
> not set all the relevant config properties. And since we are setting
> defaults, we could not assert to developers in case any mandatory property
> is not set. 
> 
> 4.
> If we do want to set defaults, we should have defaults specific to modules.
> For example, Facebook OAuth should have its own set of default values for
> authzEndPoint, accessTokenEndPoint, revokeEndPoint etc. As values for these
> properties may not change with applications, even if developers forget to
> set these properties things may just work for them out of the box in most
> cases.

Good point.
OAuth2 include a lot of configuration for each provider, writing my blog post, I thought it might just be easier to expose a Facebook Oauth configuration. Therefore the developer can only create an instance of fb config, set his app_id and secret. much shorter, and type will be inferred by the specific configuration.
Here is a JIRA to collect idea on Fb config:
https://issues.jboss.org/browse/AGIOS-205

> 
> 5. 
> We can have asserts for all mandatory properties that are not set.
> 

Let me create a JIRA for those configuration ideas:
https://issues.jboss.org/browse/AGIOS-204

This JIRA will be part of next release (1.7). 
Too short timing to include them in AeroGear iOS 1.6 is coming out end of this week early next week.

We welcome contributions, feel free to send us a PR, process on how to contribute are explained here:
http://aerogear.org/docs/guides/Contributing/

> Let me know what do you guys think about these.

Thanks for your feedback!
++
Corinne

> 
> 
> 
> --
> View this message in context: http://aerogear-dev.1069024.n5.nabble.com/Observations-on-iOS-OAuth-tp8135.html
> Sent from the aerogear-dev mailing list archive at Nabble.com.
> 
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev



From yagyesh.agrawal at itpeoplecorp.com  Wed Jun 11 04:49:55 2014
From: yagyesh.agrawal at itpeoplecorp.com (Yagyesh)
Date: Wed, 11 Jun 2014 01:49:55 -0700 (PDT)
Subject: [aerogear-dev] Observations on iOS OAuth
In-Reply-To: <23330B2D-7F0A-4F4C-946B-0BB6A622F38B@gmail.com>
References: <1402469063899-8135.post@n5.nabble.com>
	<23330B2D-7F0A-4F4C-946B-0BB6A622F38B@gmail.com>
Message-ID: <1402476595703-8137.post@n5.nabble.com>

Hello Corinne,

Thanks for acknowldeging my observations. 

Soon, I shall start contributing & you may start seeing PR's from my end.
For now, i'm kinda getting hang of the code.

Regards,
Yagyesh



--
View this message in context: http://aerogear-dev.1069024.n5.nabble.com/Observations-on-iOS-OAuth-tp8135p8137.html
Sent from the aerogear-dev mailing list archive at Nabble.com.

From edewit at redhat.com  Wed Jun 11 09:14:21 2014
From: edewit at redhat.com (Erik Jan de Wit)
Date: Wed, 11 Jun 2014 15:14:21 +0200
Subject: [aerogear-dev] UnifiedPush Server domain model
Message-ID: <5CF8ACC8-1614-4FAC-A11D-0572FFC6F27A@redhat.com>

Hi,

Right now the domain model of the UnifiedPush Server has the variants split into separate collections. 

https://github.com/edewit/aerogear-unifiedpush-server/blob/master/model/api/src/main/java/org/jboss/aerogear/unifiedpush/api/PushApplication.java#L44-L50

This could be improved to only use one collection, we?ll get more extendibility (adding another variant type for instance) and remove code like this:

https://github.com/edewit/aerogear-unifiedpush-server/blob/master/model/jpa/src/main/java/org/jboss/aerogear/unifiedpush/jpa/dao/impl/JPAPushApplicationDao.java#L93-L96

In places where you only want the iOS variants for instance you could either query them, or have a getter that collects them by type.

What do you think?

	Cheers,
		Erik Jan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140611/6930eea8/attachment-0001.html 

From lholmqui at redhat.com  Wed Jun 11 09:33:02 2014
From: lholmqui at redhat.com (Lucas Holmquist)
Date: Wed, 11 Jun 2014 09:33:02 -0400
Subject: [aerogear-dev] Aerogear.js DataManager now has ES6 promises( for
	2.0 )
Message-ID: <72799351-AB82-4006-8535-FE0081AD487D@redhat.com>


I know we are still in the 1.X series,  but it?s not to early to start thinking about the future.

in our 2.0 branch,  https://github.com/aerogear/aerogear-js/tree/2.0 , Datamanager now returns an ES6 promise. 

We have also gone full on promises by removing the success/error callbacks. ( Also, since this is 2.0,  this can still be up for discussion )

Big props to Lukas for his work on this.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140611/d62c4dac/attachment.html 

From kpiwko at redhat.com  Wed Jun 11 09:38:29 2014
From: kpiwko at redhat.com (Karel Piwko)
Date: Wed, 11 Jun 2014 15:38:29 +0200
Subject: [aerogear-dev] UnifiedPush Server domain model
In-Reply-To: <5CF8ACC8-1614-4FAC-A11D-0572FFC6F27A@redhat.com>
References: <5CF8ACC8-1614-4FAC-A11D-0572FFC6F27A@redhat.com>
Message-ID: <20140611153829.42c66ef2@kapy-ntb-x220>

+1 on not having separate table per variant type and using different
inheritance model here - for instance a discriminator column.

Karel

On Wed, 11 Jun 2014 15:14:21 +0200
Erik Jan de Wit <edewit at redhat.com> wrote:

> Hi,
> 
> Right now the domain model of the UnifiedPush Server has the variants split
> into separate collections. 
> 
> https://github.com/edewit/aerogear-unifiedpush-server/blob/master/model/api/src/main/java/org/jboss/aerogear/unifiedpush/api/PushApplication.java#L44-L50
> 
> This could be improved to only use one collection, we?ll get more
> extendibility (adding another variant type for instance) and remove code like
> this:
> 
> https://github.com/edewit/aerogear-unifiedpush-server/blob/master/model/jpa/src/main/java/org/jboss/aerogear/unifiedpush/jpa/dao/impl/JPAPushApplicationDao.java#L93-L96
> 
> In places where you only want the iOS variants for instance you could either
> query them, or have a getter that collects them by type.
> 
> What do you think?
> 
> 	Cheers,
> 		Erik Jan
> 


From iosdeveloper at agileapps.nl  Mon Jun  9 09:58:01 2014
From: iosdeveloper at agileapps.nl (=?windows-1252?Q?Ren=E9_Smits?=)
Date: Mon, 9 Jun 2014 15:58:01 +0200
Subject: [aerogear-dev] Question about iOS 6
Message-ID: <6BCE06BE-FA08-49AA-9D50-62A4BD3BDE4E@agileapps.nl>

Hello,

I just succeed to install and configure a aerogear push server and used it successfully on a android device.
The next step is an iOS device, i?ve got the demo app deployed on a ipod 4 with iOS 6.1.2 but it crashed.
It looks like you need IOS 7 for the aerogear push library 0.9.1?

Is it possible to deploy to IOS 6? Can i use an older version of the library, which one should i use?
It it not possible to upgrade the ipod to iOS 7.

Regards,
Ren? Smits

From benevides at redhat.com  Mon Jun  9 16:44:55 2014
From: benevides at redhat.com (Rafael Benevides)
Date: Mon, 09 Jun 2014 17:44:55 -0300
Subject: [aerogear-dev] Improving Android HelloPush demo experience in
 Eclipse - PR
In-Reply-To: <20140609164113.37827987@kapy-ntb-x220>
References: <20140606120528.57300bc3@kapy-ntb-x220>	<CAKjsGbvBb=FqrLyA7eC6-=wQ85HZZ39340mxoWEnv93Z9cBuFA@mail.gmail.com>
	<20140609164113.37827987@kapy-ntb-x220>
Message-ID: <53961CC7.5090204@redhat.com>

Btw, Since the new jboss.org site, we're placing the documentation of 
QSTools under: http://jboss-developer.github.io/maven-qstools-plugin/

Daniel,

please let us (me and Karol) know if you need any help on that.

Abra?os.

Em 09/06/14 11:41, Karel Piwko escreveu:
> That's the downside. I believe that only plugins that are relevant for users
> should be there. JDF has tooling to check QS stuff -
> http://www.jboss.org/jdf/quickstarts/qstools/. CC'ed Rafael, I can help
> with creating a CI job to validate quickstarts. Hopefully we'll be able to run
> QS tooling in Travis.


From jeffreynq21 at gmail.com  Sun Jun  8 22:42:31 2014
From: jeffreynq21 at gmail.com (Jeffrey Quiatchon)
Date: Mon, 9 Jun 2014 10:42:31 +0800
Subject: [aerogear-dev] AeroGear UnifiedPush Server
Message-ID: <CAJ6xuJuRjwSoXPmtzgPFpkQsS_PV1j7tEodJDbywuY9LagHBqQ@mail.gmail.com>

Hello,

Just want to know you guys that your product was very good enough to
deliver the needs of push notification in multiple platform.

I would like to ask if you have any documentation regarding the step by
step installation of AeroGear UnifiedPush in Ubuntu 12.04.4 LTS?

Thank you so much
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140609/8c243b0d/attachment.html 

From tolisemm at gmail.com  Wed Jun 11 10:26:09 2014
From: tolisemm at gmail.com (tolis emmanouilidis)
Date: Wed, 11 Jun 2014 17:26:09 +0300
Subject: [aerogear-dev] Aerogear.js DataManager now has ES6 promises(
 for 2.0 )
In-Reply-To: <72799351-AB82-4006-8535-FE0081AD487D@redhat.com>
References: <72799351-AB82-4006-8535-FE0081AD487D@redhat.com>
Message-ID: <CAN5SbcbJGgeUNZnLimRY1upd-1JFxD=gYaqMcnYFfh3qbUsiFg@mail.gmail.com>

great job Luk??


2014-06-11 16:33 GMT+03:00 Lucas Holmquist <lholmqui at redhat.com>:

>
> I know we are still in the 1.X series,  but it?s not to early to start
> thinking about the future.
>
> in our 2.0 branch,  https://github.com/aerogear/aerogear-js/tree/2.0 ,
> Datamanager now returns an ES6 promise.
>
> We have also gone full on promises by removing the success/error
> callbacks. ( Also, since this is 2.0,  this can still be up for discussion )
>
> Big props to Lukas for his work on this.
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140611/e63994d7/attachment.html 

From matzew at apache.org  Wed Jun 11 10:35:37 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Wed, 11 Jun 2014 16:35:37 +0200
Subject: [aerogear-dev] Question about iOS 6
In-Reply-To: <6BCE06BE-FA08-49AA-9D50-62A4BD3BDE4E@agileapps.nl>
References: <6BCE06BE-FA08-49AA-9D50-62A4BD3BDE4E@agileapps.nl>
Message-ID: <CAAg5f2RuYeNOx1Heq3UmX4jmBZogZhiBRArvq0yPkTSE+ucLeQ@mail.gmail.com>

Hi Ren?!

the 0.8.1 should be working for you:

https://github.com/aerogear/aerogear-push-ios-registration/blob/0.8.1/AeroGear-Push.podspec

-M


On Mon, Jun 9, 2014 at 3:58 PM, Ren? Smits <iosdeveloper at agileapps.nl>
wrote:

> Hello,
>
> I just succeed to install and configure a aerogear push server and used it
> successfully on a android device.
> The next step is an iOS device, i?ve got the demo app deployed on a ipod 4
> with iOS 6.1.2 but it crashed.
> It looks like you need IOS 7 for the aerogear push library 0.9.1?
>
> Is it possible to deploy to IOS 6? Can i use an older version of the
> library, which one should i use?
> It it not possible to upgrade the ipod to iOS 7.
>
> Regards,
> Ren? Smits
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140611/f4270640/attachment.html 

From matzew at apache.org  Wed Jun 11 10:36:50 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Wed, 11 Jun 2014 16:36:50 +0200
Subject: [aerogear-dev] UnifiedPush Server domain model
In-Reply-To: <20140611153829.42c66ef2@kapy-ntb-x220>
References: <5CF8ACC8-1614-4FAC-A11D-0572FFC6F27A@redhat.com>
	<20140611153829.42c66ef2@kapy-ntb-x220>
Message-ID: <CAAg5f2QFmCfTPjDfRjX3JRN+GF1JOkUvuJd98N-RGiqBhMTNWg@mail.gmail.com>

+1 on that!

Should we do that for the 0.11 ? Or after?


On Wed, Jun 11, 2014 at 3:38 PM, Karel Piwko <kpiwko at redhat.com> wrote:

> +1 on not having separate table per variant type and using different
> inheritance model here - for instance a discriminator column.
>
> Karel
>
> On Wed, 11 Jun 2014 15:14:21 +0200
> Erik Jan de Wit <edewit at redhat.com> wrote:
>
> > Hi,
> >
> > Right now the domain model of the UnifiedPush Server has the variants
> split
> > into separate collections.
> >
> >
> https://github.com/edewit/aerogear-unifiedpush-server/blob/master/model/api/src/main/java/org/jboss/aerogear/unifiedpush/api/PushApplication.java#L44-L50
> >
> > This could be improved to only use one collection, we?ll get more
> > extendibility (adding another variant type for instance) and remove code
> like
> > this:
> >
> >
> https://github.com/edewit/aerogear-unifiedpush-server/blob/master/model/jpa/src/main/java/org/jboss/aerogear/unifiedpush/jpa/dao/impl/JPAPushApplicationDao.java#L93-L96
> >
> > In places where you only want the iOS variants for instance you could
> either
> > query them, or have a getter that collects them by type.
> >
> > What do you think?
> >
> >       Cheers,
> >               Erik Jan
> >
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140611/0c149eec/attachment-0001.html 

From scm.blanc at gmail.com  Wed Jun 11 10:48:07 2014
From: scm.blanc at gmail.com (Sebastien Blanc)
Date: Wed, 11 Jun 2014 16:48:07 +0200
Subject: [aerogear-dev] UnifiedPush Server domain model
In-Reply-To: <CAAg5f2QFmCfTPjDfRjX3JRN+GF1JOkUvuJd98N-RGiqBhMTNWg@mail.gmail.com>
References: <5CF8ACC8-1614-4FAC-A11D-0572FFC6F27A@redhat.com>
	<20140611153829.42c66ef2@kapy-ntb-x220>
	<CAAg5f2QFmCfTPjDfRjX3JRN+GF1JOkUvuJd98N-RGiqBhMTNWg@mail.gmail.com>
Message-ID: <CAD_dpu12yvbrUcish15XpntGQr9vy4RPPhEvtjQQzCeKjYUUFQ@mail.gmail.com>

I'm also +1 but maybe better to wait after 0.11 no ?



On Wed, Jun 11, 2014 at 4:36 PM, Matthias Wessendorf <matzew at apache.org>
wrote:

> +1 on that!
>
> Should we do that for the 0.11 ? Or after?
>
>
> On Wed, Jun 11, 2014 at 3:38 PM, Karel Piwko <kpiwko at redhat.com> wrote:
>
>> +1 on not having separate table per variant type and using different
>> inheritance model here - for instance a discriminator column.
>>
>> Karel
>>
>> On Wed, 11 Jun 2014 15:14:21 +0200
>> Erik Jan de Wit <edewit at redhat.com> wrote:
>>
>> > Hi,
>> >
>> > Right now the domain model of the UnifiedPush Server has the variants
>> split
>> > into separate collections.
>> >
>> >
>> https://github.com/edewit/aerogear-unifiedpush-server/blob/master/model/api/src/main/java/org/jboss/aerogear/unifiedpush/api/PushApplication.java#L44-L50
>> >
>> > This could be improved to only use one collection, we?ll get more
>> > extendibility (adding another variant type for instance) and remove
>> code like
>> > this:
>> >
>> >
>> https://github.com/edewit/aerogear-unifiedpush-server/blob/master/model/jpa/src/main/java/org/jboss/aerogear/unifiedpush/jpa/dao/impl/JPAPushApplicationDao.java#L93-L96
>> >
>> > In places where you only want the iOS variants for instance you could
>> either
>> > query them, or have a getter that collects them by type.
>> >
>> > What do you think?
>> >
>> >       Cheers,
>> >               Erik Jan
>> >
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140611/bc050b1b/attachment.html 

From bruno at abstractj.org  Wed Jun 11 11:00:10 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Wed, 11 Jun 2014 12:00:10 -0300
Subject: [aerogear-dev] AeroGear UnifiedPush Server
In-Reply-To: <CAJ6xuJuRjwSoXPmtzgPFpkQsS_PV1j7tEodJDbywuY9LagHBqQ@mail.gmail.com>
References: <CAJ6xuJuRjwSoXPmtzgPFpkQsS_PV1j7tEodJDbywuY9LagHBqQ@mail.gmail.com>
Message-ID: <20140611150010.GA13414@abstractj.org>

Good morning my friend, did you face with any issue while deploying on
Ubuntu?

Please, let us know and file a Jira https://issues.jboss.org/browse/agpush for missing
documentation or instructions.


On 2014-06-09, Jeffrey Quiatchon wrote:
> Hello,
>
> Just want to know you guys that your product was very good enough to
> deliver the needs of push notification in multiple platform.
>
> I would like to ask if you have any documentation regarding the step by
> step installation of AeroGear UnifiedPush in Ubuntu 12.04.4 LTS?
>
> Thank you so much

> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


--

abstractj

From corinnekrych at gmail.com  Thu Jun 12 04:32:51 2014
From: corinnekrych at gmail.com (Corinne Krych)
Date: Thu, 12 Jun 2014 10:32:51 +0200
Subject: [aerogear-dev] OAuth2 and Account Management
In-Reply-To: <CAL8vO=c9VnNdGT7ATFkzBLeJc1hJts=V7w0kBB3+W1md-zhZ8w@mail.gmail.com>
References: <CE1F1C3B-8EE6-47CE-815A-50A0026A8AAB@gmail.com>
	<20140529131856.GB33519@abstractj.org>
	<301DFEAA-12FB-453D-B280-01334C7A4C90@gmail.com>
	<CAL8vO=c9VnNdGT7ATFkzBLeJc1hJts=V7w0kBB3+W1md-zhZ8w@mail.gmail.com>
Message-ID: <80DB999B-F86D-4405-AAC3-3CF87AB4C45D@gmail.com>

Hello Summers and all Android guys, 

After a second thought around AccountManager and Authorizer discussing with Christos, we thought there are a lot of similitudes on those two factory classes. 

AccountManager gest a Store injected and can deal with many Authorization Session (containing tokens) each session has an unique accountId. On the other hand, Authorizer has a memory storage (not represented as Store) of one and only one Authorization Session (containing tokens). 
Both class provider factories to create authorisation adapter.

I see AccountManager more generic than Authorizer, and for simpliflying our API, I think we can have AccountManager only and go deprecating Authorizer. For the upcoming 1.6 AeroGear-iOS release we will have both.

Thoughts? Any thing in favor of keeping Authorizer?

++
Corinne
On 30 May 2014, at 14:42, Corinne Krych <corinnekrych at gmail.com> wrote:

> +1
> I'll go for AccountManager taking a Store as an injection. Up to the developer to choose the store.
> Preferred scenario is to use EncryptedStore and as explain in Encrypted Data section from offline spec, it does require password input.
> Demo app (cookbook) could show the usage of AccountManager with encrypted storage.
> Let's not defined any default. but more a recommended scenario.
> 
> @summerp ok for you to remove creation of memory storage within AccountManager and let the user inject its own store?
> 
> ++
> Corinne
> 
> 
> 
> On 30 May 2014 14:19, Christos Vasilakis <cvasilak at gmail.com> wrote:
> 
> On May 29, 2014, at 4:18 PM, Bruno Oliveira <bruno at abstractj.org> wrote:
> 
> > On 2014-05-29, Corinne Krych wrote:
> >> Hello all
> >>
> >> It all started in that thread [1] talking about Android OAuth2 PR, but the discussion shifted on account management and storage. I think AccountManager deserves its own thread besides it?s a cross client topic (although implicit grant for pure web app is less a use case) so title is not right. Let?s fork the discussion.
> >>
> >> Main goal of AccountManager is to store all the social access tokens per account. Here is the use case:
> >> Some application may have to deal with several OAuth2 providers. For example in ios-cookbook, we have Shoot app which let you upload your photos to Google Drive(should change that to Google+ eventually), Facebook (and soon Instagram). When a user open Shoot for the first time and want to share to facebook, he will be prompted for OAuth2 grant, same thing for Google grant. The second photo will not trigger any grant as we?ve got the tokens. But if a user close the app and reopen it, we need something to store them if we don?t want to prompt again => AccountManager.
> >>
> >> Encrypted or not encrypted?
> >
> > Encrypted, always.
> >
> >> Obviously access token and even more refresh token are sensitive data. Should we store them encrypted or in a secure storage like KeyChain or KeyStore? If we go that path a password is required to encrypt or access keychain, so we need an extra prompt for the user to enter password. For example, we can chage Shoot to require a password at first login to ancrypt/decrypt access token.
> >
> > I think here is where offline specification comes in to place
> > (https://github.com/aerogear/aerogear.org/blob/master/docs/specs/aerogear-security-offline/index.md). We already discussed the workflow of how to protect sensitive offline data, but if it's missing something, feel free to include. Into this way we can avoid overlappings.
> >
> >> I would leave this decision to the end-use rdeveloper of the app. I would go for a configurable AccountManager, being able to take a store as demo here [2].
> >>
> >
> > I think it must be encrypted by default and let them disable if
> > necessary.
> 
> if not mistaken, the idea is the AccountManager to create a default encrypted store and use that for storing the tokens. If the user  for some reason wants to go without an encrypted one, we can have the interface of the AccountManager accept also an instance of an arbitaty  Store<?> and utilise this after in.
> 
> am i correct no?
> 
> -
> Christos
> 
> 
> >
> >> For now proposed API:
> >> As explained here [3], use same method signature authz: like for AGAuthorizer. But when use on AccountManager it will create a authzModule and add an account to store tokens.
> >>
> >> What?s next?
> >> We need to be able to revoke tokens and remove account from account manager.
> >>
> >> Thoughts?
> >> @summers : as you?re the guy behind Account Manager, if you can have a look to iOS PR [2] [3] I would love to hear about your thoughts
> >>
> >> ++
> >> Corinne
> >> [1] http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Android-OAuth2-PR-td7576.html
> >> [2] https://github.com/corinnekrych/aerogear-ios-cookbook-1/blob/AGIOS-190.account/Shoot/Shoot/AGShootViewController.m#L45
> >> [3] https://github.com/corinnekrych/aerogear-ios-cookbook-1/blob/AGIOS-190.account/Shoot/Shoot.md#aerogear-account-manager
> >
> >> _______________________________________________
> >> aerogear-dev mailing list
> >> aerogear-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> >
> > --
> >
> > abstractj
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> 
> 
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> 



From kpiwko at redhat.com  Thu Jun 12 07:57:50 2014
From: kpiwko at redhat.com (Karel Piwko)
Date: Thu, 12 Jun 2014 13:57:50 +0200
Subject: [aerogear-dev] UnifiedPush Server domain model
In-Reply-To: <CAD_dpu12yvbrUcish15XpntGQr9vy4RPPhEvtjQQzCeKjYUUFQ@mail.gmail.com>
References: <5CF8ACC8-1614-4FAC-A11D-0572FFC6F27A@redhat.com>
	<20140611153829.42c66ef2@kapy-ntb-x220>
	<CAAg5f2QFmCfTPjDfRjX3JRN+GF1JOkUvuJd98N-RGiqBhMTNWg@mail.gmail.com>
	<CAD_dpu12yvbrUcish15XpntGQr9vy4RPPhEvtjQQzCeKjYUUFQ@mail.gmail.com>
Message-ID: <20140612135750.07892322@kapy-ntb-x220>

On Wed, 11 Jun 2014 16:48:07 +0200
Sebastien Blanc <scm.blanc at gmail.com> wrote:

> I'm also +1 but maybe better to wait after 0.11 no ?
> 
Likely, too many things have been changed in 0.11 already ;-)
> 
> 
> On Wed, Jun 11, 2014 at 4:36 PM, Matthias Wessendorf <matzew at apache.org>
> wrote:
> 
> > +1 on that!
> >
> > Should we do that for the 0.11 ? Or after?
> >
> >
> > On Wed, Jun 11, 2014 at 3:38 PM, Karel Piwko <kpiwko at redhat.com> wrote:
> >
> >> +1 on not having separate table per variant type and using different
> >> inheritance model here - for instance a discriminator column.
> >>
> >> Karel
> >>
> >> On Wed, 11 Jun 2014 15:14:21 +0200
> >> Erik Jan de Wit <edewit at redhat.com> wrote:
> >>
> >> > Hi,
> >> >
> >> > Right now the domain model of the UnifiedPush Server has the variants
> >> split
> >> > into separate collections.
> >> >
> >> >
> >> https://github.com/edewit/aerogear-unifiedpush-server/blob/master/model/api/src/main/java/org/jboss/aerogear/unifiedpush/api/PushApplication.java#L44-L50
> >> >
> >> > This could be improved to only use one collection, we?ll get more
> >> > extendibility (adding another variant type for instance) and remove
> >> code like
> >> > this:
> >> >
> >> >
> >> https://github.com/edewit/aerogear-unifiedpush-server/blob/master/model/jpa/src/main/java/org/jboss/aerogear/unifiedpush/jpa/dao/impl/JPAPushApplicationDao.java#L93-L96
> >> >
> >> > In places where you only want the iOS variants for instance you could
> >> either
> >> > query them, or have a getter that collects them by type.
> >> >
> >> > What do you think?
> >> >
> >> >       Cheers,
> >> >               Erik Jan
> >> >
> >>
> >> _______________________________________________
> >> aerogear-dev mailing list
> >> aerogear-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>
> >
> >
> >
> > --
> > Matthias Wessendorf
> >
> > blog: http://matthiaswessendorf.wordpress.com/
> > sessions: http://www.slideshare.net/mwessendorf
> > twitter: http://twitter.com/mwessendorf
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >



From bruno at abstractj.org  Thu Jun 12 08:17:05 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Thu, 12 Jun 2014 09:17:05 -0300
Subject: [aerogear-dev] UnifiedPush Server domain model
In-Reply-To: <20140612135750.07892322@kapy-ntb-x220>
References: <5CF8ACC8-1614-4FAC-A11D-0572FFC6F27A@redhat.com>
	<20140611153829.42c66ef2@kapy-ntb-x220>
	<CAAg5f2QFmCfTPjDfRjX3JRN+GF1JOkUvuJd98N-RGiqBhMTNWg@mail.gmail.com>
	<CAD_dpu12yvbrUcish15XpntGQr9vy4RPPhEvtjQQzCeKjYUUFQ@mail.gmail.com>
	<20140612135750.07892322@kapy-ntb-x220>
Message-ID: <20140612121705.GA44316@abstractj.org>

I would vote to stabilize 0.11.0 before we start to make big changes.

On 2014-06-12, Karel Piwko wrote:
> On Wed, 11 Jun 2014 16:48:07 +0200
> Sebastien Blanc <scm.blanc at gmail.com> wrote:
>
> > I'm also +1 but maybe better to wait after 0.11 no ?
> >
> Likely, too many things have been changed in 0.11 already ;-)
> >
> >
> > On Wed, Jun 11, 2014 at 4:36 PM, Matthias Wessendorf <matzew at apache.org>
> > wrote:
> >
> > > +1 on that!
> > >
> > > Should we do that for the 0.11 ? Or after?
> > >
> > >
> > > On Wed, Jun 11, 2014 at 3:38 PM, Karel Piwko <kpiwko at redhat.com> wrote:
> > >
> > >> +1 on not having separate table per variant type and using different
> > >> inheritance model here - for instance a discriminator column.
> > >>
> > >> Karel
> > >>
> > >> On Wed, 11 Jun 2014 15:14:21 +0200
> > >> Erik Jan de Wit <edewit at redhat.com> wrote:
> > >>
> > >> > Hi,
> > >> >
> > >> > Right now the domain model of the UnifiedPush Server has the variants
> > >> split
> > >> > into separate collections.
> > >> >
> > >> >
> > >> https://github.com/edewit/aerogear-unifiedpush-server/blob/master/model/api/src/main/java/org/jboss/aerogear/unifiedpush/api/PushApplication.java#L44-L50
> > >> >
> > >> > This could be improved to only use one collection, we?ll get more
> > >> > extendibility (adding another variant type for instance) and remove
> > >> code like
> > >> > this:
> > >> >
> > >> >
> > >> https://github.com/edewit/aerogear-unifiedpush-server/blob/master/model/jpa/src/main/java/org/jboss/aerogear/unifiedpush/jpa/dao/impl/JPAPushApplicationDao.java#L93-L96
> > >> >
> > >> > In places where you only want the iOS variants for instance you could
> > >> either
> > >> > query them, or have a getter that collects them by type.
> > >> >
> > >> > What do you think?
> > >> >
> > >> >       Cheers,
> > >> >               Erik Jan
> > >> >
> > >>
> > >> _______________________________________________
> > >> aerogear-dev mailing list
> > >> aerogear-dev at lists.jboss.org
> > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > >>
> > >
> > >
> > >
> > > --
> > > Matthias Wessendorf
> > >
> > > blog: http://matthiaswessendorf.wordpress.com/
> > > sessions: http://www.slideshare.net/mwessendorf
> > > twitter: http://twitter.com/mwessendorf
> > >
> > > _______________________________________________
> > > aerogear-dev mailing list
> > > aerogear-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > >
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev

--

abstractj

From HunterChen at gangutech.com  Thu Jun 12 06:11:42 2014
From: HunterChen at gangutech.com (Hunter Chen)
Date: Thu, 12 Jun 2014 10:11:42 +0000
Subject: [aerogear-dev] [Help]With OTP between iOS and Android
Message-ID: <B255CC3D00A247448AF86CE5C48F7F631D6CF8@TWGTPNT02.gangutech.com>

Dear Sir,

        I have download the OTP library form Gitihub,
https://github.com/aerogear/aerogear-otp-java
https://github.com/aerogear/aerogear-otp-ios

   after I modify the Clock class android Base32 class
I input fixed string ABCDEFGH, and fixed interval time 46752201

I got the different result
Ios output >  46752190
Android output  >>>  46752201


Could you help me ? thanks..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140612/00bcea1c/attachment-0001.html 

From avibelli at redhat.com  Thu Jun 12 09:02:23 2014
From: avibelli at redhat.com (Andrea Vibelli)
Date: Thu, 12 Jun 2014 06:02:23 -0700 (PDT)
Subject: [aerogear-dev] UnifiedPush Server domain model
In-Reply-To: <20140612121705.GA44316@abstractj.org>
References: <5CF8ACC8-1614-4FAC-A11D-0572FFC6F27A@redhat.com>
	<20140611153829.42c66ef2@kapy-ntb-x220>
	<CAAg5f2QFmCfTPjDfRjX3JRN+GF1JOkUvuJd98N-RGiqBhMTNWg@mail.gmail.com>
	<CAD_dpu12yvbrUcish15XpntGQr9vy4RPPhEvtjQQzCeKjYUUFQ@mail.gmail.com>
	<20140612135750.07892322@kapy-ntb-x220>
	<20140612121705.GA44316@abstractj.org>
Message-ID: <1402578143219-8153.post@n5.nabble.com>

I would also vote for waiting after 0.11.0 release (+1 on this very nice
refactoring).

Andrea
 

Bruno Oliveira wrote
> I would vote to stabilize 0.11.0 before we start to make big changes.
> 
> On 2014-06-12, Karel Piwko wrote:
>> On Wed, 11 Jun 2014 16:48:07 +0200
>> Sebastien Blanc &lt;

> scm.blanc@

> &gt; wrote:
>>
>> > I'm also +1 but maybe better to wait after 0.11 no ?
>> >
>> Likely, too many things have been changed in 0.11 already ;-)
>> >
>> >
>> > On Wed, Jun 11, 2014 at 4:36 PM, Matthias Wessendorf &lt;

> matzew@

> &gt;
>> > wrote:
>> >
>> > > +1 on that!
>> > >
>> > > Should we do that for the 0.11 ? Or after?
>> > >
>> > >
>> > > On Wed, Jun 11, 2014 at 3:38 PM, Karel Piwko &lt;

> kpiwko@

> &gt; wrote:
>> > >
>> > >> +1 on not having separate table per variant type and using different
>> > >> inheritance model here - for instance a discriminator column.
>> > >>
>> > >> Karel
>> > >>
>> > >> On Wed, 11 Jun 2014 15:14:21 +0200
>> > >> Erik Jan de Wit &lt;

> edewit@

> &gt; wrote:
>> > >>
>> > >> > Hi,
>> > >> >
>> > >> > Right now the domain model of the UnifiedPush Server has the
>> variants
>> > >> split
>> > >> > into separate collections.
>> > >> >
>> > >> >
>> > >>
>> https://github.com/edewit/aerogear-unifiedpush-server/blob/master/model/api/src/main/java/org/jboss/aerogear/unifiedpush/api/PushApplication.java#L44-L50
>> > >> >
>> > >> > This could be improved to only use one collection, we?ll get more
>> > >> > extendibility (adding another variant type for instance) and
>> remove
>> > >> code like
>> > >> > this:
>> > >> >
>> > >> >
>> > >>
>> https://github.com/edewit/aerogear-unifiedpush-server/blob/master/model/jpa/src/main/java/org/jboss/aerogear/unifiedpush/jpa/dao/impl/JPAPushApplicationDao.java#L93-L96
>> > >> >
>> > >> > In places where you only want the iOS variants for instance you
>> could
>> > >> either
>> > >> > query them, or have a getter that collects them by type.
>> > >> >
>> > >> > What do you think?
>> > >> >
>> > >> >       Cheers,
>> > >> >               Erik Jan
>> > >> >
>> > >>
>> > >> _______________________________________________
>> > >> aerogear-dev mailing list
>> > >> 

> aerogear-dev at .jboss

>> > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> > >>
>> > >
>> > >
>> > >
>> > > --
>> > > Matthias Wessendorf
>> > >
>> > > blog: http://matthiaswessendorf.wordpress.com/
>> > > sessions: http://www.slideshare.net/mwessendorf
>> > > twitter: http://twitter.com/mwessendorf
>> > >
>> > > _______________________________________________
>> > > aerogear-dev mailing list
>> > > 

> aerogear-dev at .jboss

>> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> > >
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> 

> aerogear-dev at .jboss

>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> 
> --
> 
> abstractj
> _______________________________________________
> aerogear-dev mailing list

> aerogear-dev at .jboss

> https://lists.jboss.org/mailman/listinfo/aerogear-dev





--
View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-UnifiedPush-Server-domain-model-tp8138p8153.html
Sent from the aerogear-dev mailing list archive at Nabble.com.


From vmfamaral at gmail.com  Thu Jun 12 11:01:02 2014
From: vmfamaral at gmail.com (oxsav)
Date: Thu, 12 Jun 2014 08:01:02 -0700 (PDT)
Subject: [aerogear-dev] Vertx Module for Unified Push Server
Message-ID: <1402585262061-8154.post@n5.nabble.com>

Hello.
I have been working in a vert.x module for a few days and I made a module
that works over a eventbus server. 
The module is now in a real real beta version, but if you can take a look
and let me know what do you think about it I would appreciate. 

Here is the URL: 
https://github.com/oxsav/vertx-oxsav-modules/tree/master/vertxUnified

Thank you very much.



--
View this message in context: http://aerogear-dev.1069024.n5.nabble.com/Vertx-Module-for-Unified-Push-Server-tp8154.html
Sent from the aerogear-dev mailing list archive at Nabble.com.

From scm.blanc at gmail.com  Thu Jun 12 11:06:21 2014
From: scm.blanc at gmail.com (Sebastien Blanc)
Date: Thu, 12 Jun 2014 17:06:21 +0200
Subject: [aerogear-dev] Vertx Module for Unified Push Server
In-Reply-To: <1402585262061-8154.post@n5.nabble.com>
References: <1402585262061-8154.post@n5.nabble.com>
Message-ID: <CAD_dpu2p4Q1DHbcgvirk3agP07M7QxA5gr2rs5xnqLDt-bNp9g@mail.gmail.com>

Hey !
Really cool ! I had started one a while ago but had not time to really work
on it.

Do you have some usage examples ? What is the format of the message we send
over the bus ?

Seb




On Thu, Jun 12, 2014 at 5:01 PM, oxsav <vmfamaral at gmail.com> wrote:

> Hello.
> I have been working in a vert.x module for a few days and I made a module
> that works over a eventbus server.
> The module is now in a real real beta version, but if you can take a look
> and let me know what do you think about it I would appreciate.
>
> Here is the URL:
> https://github.com/oxsav/vertx-oxsav-modules/tree/master/vertxUnified
>
> Thank you very much.
>
>
>
> --
> View this message in context:
> http://aerogear-dev.1069024.n5.nabble.com/Vertx-Module-for-Unified-Push-Server-tp8154.html
> Sent from the aerogear-dev mailing list archive at Nabble.com.
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140612/94d8769e/attachment.html 

From vmfamaral at gmail.com  Thu Jun 12 11:22:11 2014
From: vmfamaral at gmail.com (oxsav)
Date: Thu, 12 Jun 2014 08:22:11 -0700 (PDT)
Subject: [aerogear-dev] Vertx Module for Unified Push Server
In-Reply-To: <CAD_dpu2p4Q1DHbcgvirk3agP07M7QxA5gr2rs5xnqLDt-bNp9g@mail.gmail.com>
References: <1402585262061-8154.post@n5.nabble.com>
	<CAD_dpu2p4Q1DHbcgvirk3agP07M7QxA5gr2rs5xnqLDt-bNp9g@mail.gmail.com>
Message-ID: <1402586531973-8156.post@n5.nabble.com>

I just add a simple example in javascript to the README.
plz check it

I will try to improve it and do integration tests to be easier.

Thank you



--
View this message in context: http://aerogear-dev.1069024.n5.nabble.com/Vertx-Module-for-Unified-Push-Server-tp8154p8156.html
Sent from the aerogear-dev mailing list archive at Nabble.com.

From yagyesh.agrawal at itpeoplecorp.com  Fri Jun 13 03:39:58 2014
From: yagyesh.agrawal at itpeoplecorp.com (Yagyesh)
Date: Fri, 13 Jun 2014 00:39:58 -0700 (PDT)
Subject: [aerogear-dev] More on AeroGear - iOS
Message-ID: <1402645198839-8157.post@n5.nabble.com>

1. 
Recently, while working on GoogleDrive iOS sample i found that the app was
not being notified back if user chose 'Cancel' instead of 'Accept' on the
Google's OAuth permission page. The returned url from Google looks something
like this:
org.aerogear.googledrive:/oauth2Callback?error=access_denied

And below is the code snippet from requestAuthorizationCodeSuccess method of
AGRestOAuth2Module:
------------------------------
// extract the code from the URL
            NSString* code = [[self parametersFromQueryString:[url query]]
valueForKey:@"code"];
            // if exists perform the exchange
            if (code)
                [self exchangeAuthorizationCodeForAccessToken:code
success:success failure:failure];
 ----------------------------

If user denied permissions, 'code' would be nil and there is no else part. I
believe there should be a way to notify the app. 

2. 
Another thing that i could not achieve was multipart upload. I'm not sure if
i did anything wrong but no matter what i tired i always used to get 'Bad
request' error. If multipart upload works for iOS, is there any example that
i can refer to? If multipart is not tested throughly, it would be time for
me to bring up wireshark, see how the request is actually being sent over
http & hopefully fix multipart upload for iOS.
 



--
View this message in context: http://aerogear-dev.1069024.n5.nabble.com/More-on-AeroGear-iOS-tp8157.html
Sent from the aerogear-dev mailing list archive at Nabble.com.

From corinnekrych at gmail.com  Fri Jun 13 03:48:31 2014
From: corinnekrych at gmail.com (Corinne Krych)
Date: Fri, 13 Jun 2014 09:48:31 +0200
Subject: [aerogear-dev] More on AeroGear - iOS
In-Reply-To: <1402645198839-8157.post@n5.nabble.com>
References: <1402645198839-8157.post@n5.nabble.com>
Message-ID: <DCB602B8-44B3-4899-A0FC-21B8145B7D47@gmail.com>


On 13 Jun 2014, at 09:39, Yagyesh <yagyesh.agrawal at itpeoplecorp.com> wrote:

> 1. 
> Recently, while working on GoogleDrive iOS sample i found that the app was
> not being notified back if user chose 'Cancel' instead of 'Accept' on the
> Google's OAuth permission page. The returned url from Google looks something
> like this:
> org.aerogear.googledrive:/oauth2Callback?error=access_denied
> 
> And below is the code snippet from requestAuthorizationCodeSuccess method of
> AGRestOAuth2Module:
> ------------------------------
> // extract the code from the URL
>            NSString* code = [[self parametersFromQueryString:[url query]]
> valueForKey:@"code"];
>            // if exists perform the exchange
>            if (code)
>                [self exchangeAuthorizationCodeForAccessToken:code
> success:success failure:failure];
> ----------------------------
> 
> If user denied permissions, 'code' would be nil and there is no else part. I
> believe there should be a way to notify the app. 
> 
> 2. 
> Another thing that i could not achieve was multipart upload. I'm not sure if
> i did anything wrong but no matter what i tired i always used to get 'Bad
> request' error. If multipart upload works for iOS, is there any example that
> i can refer to? If multipart is not tested throughly, it would be time for
> me to bring up wireshark, see how the request is actually being sent over
> http & hopefully fix multipart upload for iOS.


See Shoot app exemple:
https://github.com/aerogear/aerogear-ios-cookbook/blob/master/Shoot/Shoot.md

> 
> 
> 
> 
> --
> View this message in context: http://aerogear-dev.1069024.n5.nabble.com/More-on-AeroGear-iOS-tp8157.html
> Sent from the aerogear-dev mailing list archive at Nabble.com.
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev



From lukas.fryc at gmail.com  Fri Jun 13 04:28:46 2014
From: lukas.fryc at gmail.com (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=)
Date: Fri, 13 Jun 2014 10:28:46 +0200
Subject: [aerogear-dev] admin-ui and Keycloak.js integration
In-Reply-To: <20140609160509.GA14823@abstractj.org>
References: <20140606160512.GA1854@abstractj.org>
	<CAD_dpu0PN6qfSajHW-qV24EG-CPNQNYCmW8tsi1L6tGStGgjqg@mail.gmail.com>
	<20140609160509.GA14823@abstractj.org>
Message-ID: <CAEroY34pmr8rDXa0tiVWy72U7o-GtF6V3RmXmDJ-cBMOeUPnXA@mail.gmail.com>

I've moved bootstrap of the angular to the authenticated (as suggested by
Stian),
that seems to be a cleaner solution:

instead of

...?permanent_login=XYZ/#/main

we get just this URL:

.../#/main

https://github.com/sebastienblanc/aerogear-unified-push-server/pull/1


----

The issue with NPE still persists:

http://lists.jboss.org/pipermail/keycloak-dev/2014-June/001934.html

https://issues.jboss.org/browse/KEYCLOAK-523





On Mon, Jun 9, 2014 at 6:05 PM, Bruno Oliveira <bruno at abstractj.org> wrote:

> Ahoy and thank you.
>
> I was looking and testing your latest changes, in the very beginning of
> this integration I also tried to include Angular.js' interceptors and
> all the Angular-isms available.
>
> The problem is the fact of hiding the probable bug. If you change the
> endpoint to something like:
>
> @GET
> @Produces(MediaType.APPLICATION_JSON)
> public Response listAllPushApplications(@Context
>   HttpServletRequest request) {
>     return
> Response.ok(pushAppService.findAllPushApplicationsForDeveloper("admin")).build();
> }
>
> or
>
> @GET
> @Produces(MediaType.APPLICATION_JSON)
> public Response listAllPushApplications(@Context
>   HttpServletRequest request) {
>     return Response.ok("guacamole").build();
> }
>
> The issue still persists. I'll keep investigating.
>
>
> On 2014-06-07, Sebastien Blanc wrote:
> > Hi my friend !
> >
> > Just to let you know I started to look at your branch and indeed you
> better
> > not be epileptic to survive the crazy reloads ;)
> > I have nothing to push right now but I have some ideas :
> >
> > * Like you mention, the redirect and main route broke the stuff. So, I
> > think we should remove that and do the initial redirect in the success
> > callback of the keycloakAuth.init call. I have a local branch where I
> > manage to do that, but it's really hacky and I face another issue , the
> > first next REST call fails because there are not auth info. But ! This is
> > there where we have to introduce the Auth interceptor like here
> >
> https://github.com/keycloak/keycloak/blob/master/examples/demo-template/angular-product-app/src/main/webapp/js/app.js#L43-L60
> >
> > I think based on this, we should be able to find a solution. I will try
> to
> > push my work ASAP and maybe some dudes for KC could give us some hints as
> > well.
> >
> > Have a good weekend !
> >
> > sebi
> >
> >
> >
> > On Fri, Jun 6, 2014 at 6:05 PM, Bruno Oliveira <bruno at abstractj.org>
> wrote:
> >
> > > Good morning,
> > >
> > > I'm struggling to integrate Keycloak.js with our admin-ui. Everything
> > > works perfectly well out of admin-ui with UPS and Angular.js as you
> > > might notice here:
> > >
> > >
> https://github.com/abstractj/aerogear-unifiedpush-server/tree/keycloak-angular
> > >
> > > The issue lies when I enable the routes related with redirect and
> > > MainController:
> > >
> > >
> https://github.com/abstractj/aerogear-unifiedpush-server/tree/keycloak_angular_integration
> > > .
> > > Just open http://localhost:8080/ag-push and watch your browser reload
> > > like crazy. When the main route and redirect are disable, everything
> goes
> > > well:
> > >
> > >
> https://github.com/abstractj/aerogear-unifiedpush-server/commit/dd9438c6503061fba8aa0e0d77973971888e9379
> > >
> > >
> > > At first glance it doesn't sound to be a problem on KC.js, once already
> > > works with Angular.js:
> > >
> > >
> https://github.com/keycloak/keycloak/tree/master/examples/demo-template/angular-product-app
> > > .
> > >
> > > If you have any idea, help is appreciated.
> > >
> > > --
> > >
> > > abstractj
> > > _______________________________________________
> > > aerogear-dev mailing list
> > > aerogear-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > >
>
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> --
>
> abstractj
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140613/8c0e8ae2/attachment-0001.html 

From corinnekrych at gmail.com  Fri Jun 13 04:30:43 2014
From: corinnekrych at gmail.com (Corinne Krych)
Date: Fri, 13 Jun 2014 10:30:43 +0200
Subject: [aerogear-dev] Pre-announcement for AeroGear-iOS 1.6
Message-ID: <C9B3F396-BDC6-47F4-854C-A36AE621EACB@gmail.com>

Hello iOS guys and ladies,

We?ve been working toward AeroGear-iOS 1.6 release (planned mid-June), we?re almost there! Most PRs have been merged. So if you want to give it a spin and shared feedback, we?ll appreciate all hands. If everything goes smoothly we should tag and publish 1.6 by Thursday next week.

Last words, the main focus of 1.6 is on OAuth2, so be social, spread the word :) 

Corinne && Christos

From yagyesh.agrawal at itpeoplecorp.com  Fri Jun 13 05:08:45 2014
From: yagyesh.agrawal at itpeoplecorp.com (Yagyesh)
Date: Fri, 13 Jun 2014 02:08:45 -0700 (PDT)
Subject: [aerogear-dev] More on AeroGear - iOS
In-Reply-To: <DCB602B8-44B3-4899-A0FC-21B8145B7D47@gmail.com>
References: <1402645198839-8157.post@n5.nabble.com>
	<DCB602B8-44B3-4899-A0FC-21B8145B7D47@gmail.com>
Message-ID: <1402650525369-8161.post@n5.nabble.com>

Hi Corinne,

I'm afraid but i see same issues with the Shoot app. 

1. From the Shoot app,  I selected a picture from the album and then chose
'Google' authentication. Before the app moved to Google's page for
authentication, it started showing "Uploading, please wait" progress dialog.
On the Google's page, I selected 'Cancel' & the Shoot app came to
foreground. The progress dialog is still showing and it does not go off.
This is becuase of the 1st issue i mentioned in post above. I have handled
this via a workaround in the Google Drive app here:
https://github.com/yagyesha/aerogear-ios-cookbook/commit/93368a7ef537f161f389ce5f98a5e4cb3f85118b
<https://github.com/yagyesha/aerogear-ios-cookbook/commit/93368a7ef537f161f389ce5f98a5e4cb3f85118b>  

But i believe, proper notification should come from AeroGear lib.

2. Also, Shoot app does a simple upload i.e. it first uploads the content
and then the metadata. I do not see any multiplart upload happening in shoot
app. 
https://developers.google.com/drive/web/manage-uploads#multipart
<https://developers.google.com/drive/web/manage-uploads#multipart>  

Let me know if there is something that i'm missing.

Regards,
Yagyesh



--
View this message in context: http://aerogear-dev.1069024.n5.nabble.com/More-on-AeroGear-iOS-tp8157p8161.html
Sent from the aerogear-dev mailing list archive at Nabble.com.

From cvasilak at gmail.com  Fri Jun 13 06:42:06 2014
From: cvasilak at gmail.com (Christos Vasilakis)
Date: Fri, 13 Jun 2014 13:42:06 +0300
Subject: [aerogear-dev] More on AeroGear - iOS
In-Reply-To: <1402645198839-8157.post@n5.nabble.com>
References: <1402645198839-8157.post@n5.nabble.com>
Message-ID: <83B49009-1001-4A03-8029-43BC141E1C9B@gmail.com>

Hi Yagyesh,

thanks for trying out and for your PR, nice work!

my comments inline:

On Jun 13, 2014, at 10:39 AM, Yagyesh <yagyesh.agrawal at itpeoplecorp.com> wrote:

> 1. 
> Recently, while working on GoogleDrive iOS sample i found that the app was
> not being notified back if user chose 'Cancel' instead of 'Accept' on the
> Google's OAuth permission page. The returned url from Google looks something
> like this:
> org.aerogear.googledrive:/oauth2Callback?error=access_denied
> 
> And below is the code snippet from requestAuthorizationCodeSuccess method of
> AGRestOAuth2Module:
> ------------------------------
> // extract the code from the URL
>            NSString* code = [[self parametersFromQueryString:[url query]]
> valueForKey:@"code"];
>            // if exists perform the exchange
>            if (code)
>                [self exchangeAuthorizationCodeForAccessToken:code
> success:success failure:failure];
> ----------------------------
> 
> If user denied permissions, 'code' would be nil and there is no else part. I
> believe there should be a way to notify the app. 

+1 agree with this, would you mind to open a JIRA for it [1] to look at.


> 
> 2. 
> Another thing that i could not achieve was multipart upload. I'm not sure if
> i did anything wrong but no matter what i tired i always used to get 'Bad
> request' error. If multipart upload works for iOS, is there any example that
> i can refer to? If multipart is not tested throughly, it would be time for
> me to bring up wireshark, see how the request is actually being sent over
> http & hopefully fix multipart upload for iOS.

I do remember when trying to support ??multipart? endpoint on gdrive this problem, unfortunately I couldn?t find the issue why this was failing.  I remember the frustration, cause dumping the network frames looked exactly similar on what the library was sending underlying. That?s why in the demo instead we went to use two pipes, one for the upload and one for the metadata set.

I would though appreciate if you can revisit with wireshark to possible identify the issue with gdrive, which possible I missed, and hopefully enhance our lib.

Regardless though, for an example of multipart you can try our iOS demo [2] that goes against our integration-tests server [3]  and particularly going against the upload endpoint [4]. Running it, you will see on the log the server dumping the filenames (and their sizes) together with any key-value pairs you set on the request.

Let us know with your findings.

BTW, you can find most of the developers in the irc://irc.freenode.net/aerogear irc channel, feel free to join and introduce yourself!

Thanks and keep up!
Christos

[1] https://issues.jboss.org/browse/AGIOS
[2] https://github.com/cvasilak/MultiPartIOSDemo
[3] https://github.com/aerogear/aerogear-integration-tests-server
[4] https://github.com/aerogear/aerogear-integration-tests-server/blob/master/src/main/java/org/jboss/aerogear/integration/service/UploadService.java


> --
> View this message in context: http://aerogear-dev.1069024.n5.nabble.com/More-on-AeroGear-iOS-tp8157.html
> Sent from the aerogear-dev mailing list archive at Nabble.com.
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev



From corinnekrych at gmail.com  Fri Jun 13 08:10:49 2014
From: corinnekrych at gmail.com (Corinne Krych)
Date: Fri, 13 Jun 2014 14:10:49 +0200
Subject: [aerogear-dev] More on AeroGear - iOS
In-Reply-To: <83B49009-1001-4A03-8029-43BC141E1C9B@gmail.com>
References: <1402645198839-8157.post@n5.nabble.com>
	<83B49009-1001-4A03-8029-43BC141E1C9B@gmail.com>
Message-ID: <B9A71C11-5395-4EE6-8D78-5C6F086E9BC3@gmail.com>

#agreed cancel should be part of AG, here is a proposed PR:
https://github.com/aerogear/aerogear-ios/pull/132

Have a look and let me know. I?d like to have it part of our 1.6 release.

++
Corinne

On 13 Jun 2014, at 12:42, Christos Vasilakis <cvasilak at gmail.com> wrote:

> Hi Yagyesh,
> 
> thanks for trying out and for your PR, nice work!
> 
> my comments inline:
> 
> On Jun 13, 2014, at 10:39 AM, Yagyesh <yagyesh.agrawal at itpeoplecorp.com> wrote:
> 
>> 1. 
>> Recently, while working on GoogleDrive iOS sample i found that the app was
>> not being notified back if user chose 'Cancel' instead of 'Accept' on the
>> Google's OAuth permission page. The returned url from Google looks something
>> like this:
>> org.aerogear.googledrive:/oauth2Callback?error=access_denied
>> 
>> And below is the code snippet from requestAuthorizationCodeSuccess method of
>> AGRestOAuth2Module:
>> ------------------------------
>> // extract the code from the URL
>>           NSString* code = [[self parametersFromQueryString:[url query]]
>> valueForKey:@"code"];
>>           // if exists perform the exchange
>>           if (code)
>>               [self exchangeAuthorizationCodeForAccessToken:code
>> success:success failure:failure];
>> ----------------------------
>> 
>> If user denied permissions, 'code' would be nil and there is no else part. I
>> believe there should be a way to notify the app. 
> 
> +1 agree with this, would you mind to open a JIRA for it [1] to look at.
> 
> 
>> 
>> 2. 
>> Another thing that i could not achieve was multipart upload. I'm not sure if
>> i did anything wrong but no matter what i tired i always used to get 'Bad
>> request' error. If multipart upload works for iOS, is there any example that
>> i can refer to? If multipart is not tested throughly, it would be time for
>> me to bring up wireshark, see how the request is actually being sent over
>> http & hopefully fix multipart upload for iOS.
> 
> I do remember when trying to support ??multipart? endpoint on gdrive this problem, unfortunately I couldn?t find the issue why this was failing.  I remember the frustration, cause dumping the network frames looked exactly similar on what the library was sending underlying. That?s why in the demo instead we went to use two pipes, one for the upload and one for the metadata set.
> 
> I would though appreciate if you can revisit with wireshark to possible identify the issue with gdrive, which possible I missed, and hopefully enhance our lib.
> 
> Regardless though, for an example of multipart you can try our iOS demo [2] that goes against our integration-tests server [3]  and particularly going against the upload endpoint [4]. Running it, you will see on the log the server dumping the filenames (and their sizes) together with any key-value pairs you set on the request.
> 
> Let us know with your findings.
> 
> BTW, you can find most of the developers in the irc://irc.freenode.net/aerogear irc channel, feel free to join and introduce yourself!
> 
> Thanks and keep up!
> Christos
> 
> [1] https://issues.jboss.org/browse/AGIOS
> [2] https://github.com/cvasilak/MultiPartIOSDemo
> [3] https://github.com/aerogear/aerogear-integration-tests-server
> [4] https://github.com/aerogear/aerogear-integration-tests-server/blob/master/src/main/java/org/jboss/aerogear/integration/service/UploadService.java
> 
> 
>> --
>> View this message in context: http://aerogear-dev.1069024.n5.nabble.com/More-on-AeroGear-iOS-tp8157.html
>> Sent from the aerogear-dev mailing list archive at Nabble.com.
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> 
> 
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev



From bruno at abstractj.org  Fri Jun 13 12:39:10 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Fri, 13 Jun 2014 13:39:10 -0300
Subject: [aerogear-dev] admin-ui and Keycloak.js integration
In-Reply-To: <CAEroY34pmr8rDXa0tiVWy72U7o-GtF6V3RmXmDJ-cBMOeUPnXA@mail.gmail.com>
References: <20140606160512.GA1854@abstractj.org>
	<CAD_dpu0PN6qfSajHW-qV24EG-CPNQNYCmW8tsi1L6tGStGgjqg@mail.gmail.com>
	<20140609160509.GA14823@abstractj.org>
	<CAEroY34pmr8rDXa0tiVWy72U7o-GtF6V3RmXmDJ-cBMOeUPnXA@mail.gmail.com>
Message-ID: <20140613163909.GA60093@abstractj.org>

Cool and thank you Luk??.

On 2014-06-13, Luk?? Fry? wrote:
> I've moved bootstrap of the angular to the authenticated (as suggested by
> Stian),
> that seems to be a cleaner solution:
>
> instead of
>
> ...?permanent_login=XYZ/#/main
>
> we get just this URL:
>
> .../#/main
>
> https://github.com/sebastienblanc/aerogear-unified-push-server/pull/1
>
>
> ----
>
> The issue with NPE still persists:
>
> http://lists.jboss.org/pipermail/keycloak-dev/2014-June/001934.html
>
> https://issues.jboss.org/browse/KEYCLOAK-523
>
>
>
>
>
> On Mon, Jun 9, 2014 at 6:05 PM, Bruno Oliveira <bruno at abstractj.org> wrote:
>
> > Ahoy and thank you.
> >
> > I was looking and testing your latest changes, in the very beginning of
> > this integration I also tried to include Angular.js' interceptors and
> > all the Angular-isms available.
> >
> > The problem is the fact of hiding the probable bug. If you change the
> > endpoint to something like:
> >
> > @GET
> > @Produces(MediaType.APPLICATION_JSON)
> > public Response listAllPushApplications(@Context
> >   HttpServletRequest request) {
> >     return
> > Response.ok(pushAppService.findAllPushApplicationsForDeveloper("admin")).build();
> > }
> >
> > or
> >
> > @GET
> > @Produces(MediaType.APPLICATION_JSON)
> > public Response listAllPushApplications(@Context
> >   HttpServletRequest request) {
> >     return Response.ok("guacamole").build();
> > }
> >
> > The issue still persists. I'll keep investigating.
> >
> >
> > On 2014-06-07, Sebastien Blanc wrote:
> > > Hi my friend !
> > >
> > > Just to let you know I started to look at your branch and indeed you
> > better
> > > not be epileptic to survive the crazy reloads ;)
> > > I have nothing to push right now but I have some ideas :
> > >
> > > * Like you mention, the redirect and main route broke the stuff. So, I
> > > think we should remove that and do the initial redirect in the success
> > > callback of the keycloakAuth.init call. I have a local branch where I
> > > manage to do that, but it's really hacky and I face another issue , the
> > > first next REST call fails because there are not auth info. But ! This is
> > > there where we have to introduce the Auth interceptor like here
> > >
> > https://github.com/keycloak/keycloak/blob/master/examples/demo-template/angular-product-app/src/main/webapp/js/app.js#L43-L60
> > >
> > > I think based on this, we should be able to find a solution. I will try
> > to
> > > push my work ASAP and maybe some dudes for KC could give us some hints as
> > > well.
> > >
> > > Have a good weekend !
> > >
> > > sebi
> > >
> > >
> > >
> > > On Fri, Jun 6, 2014 at 6:05 PM, Bruno Oliveira <bruno at abstractj.org>
> > wrote:
> > >
> > > > Good morning,
> > > >
> > > > I'm struggling to integrate Keycloak.js with our admin-ui. Everything
> > > > works perfectly well out of admin-ui with UPS and Angular.js as you
> > > > might notice here:
> > > >
> > > >
> > https://github.com/abstractj/aerogear-unifiedpush-server/tree/keycloak-angular
> > > >
> > > > The issue lies when I enable the routes related with redirect and
> > > > MainController:
> > > >
> > > >
> > https://github.com/abstractj/aerogear-unifiedpush-server/tree/keycloak_angular_integration
> > > > .
> > > > Just open http://localhost:8080/ag-push and watch your browser reload
> > > > like crazy. When the main route and redirect are disable, everything
> > goes
> > > > well:
> > > >
> > > >
> > https://github.com/abstractj/aerogear-unifiedpush-server/commit/dd9438c6503061fba8aa0e0d77973971888e9379
> > > >
> > > >
> > > > At first glance it doesn't sound to be a problem on KC.js, once already
> > > > works with Angular.js:
> > > >
> > > >
> > https://github.com/keycloak/keycloak/tree/master/examples/demo-template/angular-product-app
> > > > .
> > > >
> > > > If you have any idea, help is appreciated.
> > > >
> > > > --
> > > >
> > > > abstractj
> > > > _______________________________________________
> > > > aerogear-dev mailing list
> > > > aerogear-dev at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > >
> >
> > > _______________________________________________
> > > aerogear-dev mailing list
> > > aerogear-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> >
> > --
> >
> > abstractj
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >

> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


--

abstractj

From yagyesh.agrawal at itpeoplecorp.com  Sat Jun 14 02:30:53 2014
From: yagyesh.agrawal at itpeoplecorp.com (Yagyesh)
Date: Fri, 13 Jun 2014 23:30:53 -0700 (PDT)
Subject: [aerogear-dev] More on AeroGear - iOS
In-Reply-To: <B9A71C11-5395-4EE6-8D78-5C6F086E9BC3@gmail.com>
References: <1402645198839-8157.post@n5.nabble.com>
	<83B49009-1001-4A03-8029-43BC141E1C9B@gmail.com>
	<B9A71C11-5395-4EE6-8D78-5C6F086E9BC3@gmail.com>
Message-ID: <1402727453660-8165.post@n5.nabble.com>

Hi Corinne & Christos,

Thanks for acknowledging my observations. Accordingly, I have also updated
the PR by removing the workaround.

I shall start looking into multipart upload as soon as i get to work on
Monday morning.

Regards,
Yagyesh Agrawal



--
View this message in context: http://aerogear-dev.1069024.n5.nabble.com/More-on-AeroGear-iOS-tp8157p8165.html
Sent from the aerogear-dev mailing list archive at Nabble.com.

From daniel.bevenius at gmail.com  Mon Jun 16 02:55:33 2014
From: daniel.bevenius at gmail.com (Daniel Bevenius)
Date: Mon, 16 Jun 2014 08:55:33 +0200
Subject: [aerogear-dev] Team meeting
Message-ID: <CAFJm-3ELwbyKsq8v=3RZ8UM8eV3nMB3F-wW__wK1TifJPuBf_g@mail.gmail.com>

Agenda:
http://oksoclap.com/p/aerogear-team-mgt-20140616
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140616/08bf4921/attachment.html 

From bruno at abstractj.org  Mon Jun 16 07:31:18 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Mon, 16 Jun 2014 08:31:18 -0300
Subject: [aerogear-dev] UPS staging heads up
Message-ID: <20140616113117.GA76439@abstractj.org>

Good morning,

At the present moment we have some critical issues to be fixed before
stage UPS server 0.11.0 and I'm holding it until Keycloak beta3 be released
with the solution for this issue https://issues.jboss.org/browse/KEYCLOAK-523.

More updates will come during the week, as soon as I get more
information.

Thanks in advance

--

abstractj

From lukas.fryc at gmail.com  Mon Jun 16 08:16:32 2014
From: lukas.fryc at gmail.com (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=)
Date: Mon, 16 Jun 2014 14:16:32 +0200
Subject: [aerogear-dev] UPS staging heads up
In-Reply-To: <20140616113117.GA76439@abstractj.org>
References: <20140616113117.GA76439@abstractj.org>
Message-ID: <CAEroY35Pa0k2kmPtZSGDpZtim1p5em91i32YVbNH+45rCm77Qg@mail.gmail.com>

Sounds good,

I have few pull requests opened atm incl. fixes and improvements in the
Admin UI 0.11.0.

If someone could review them and gimme +1 or indicate suggestions for
correction,
the help will be much appreciated:

https://github.com/aerogear/aerogear-unifiedpush-server/pulls

~ Lukas


On Mon, Jun 16, 2014 at 1:31 PM, Bruno Oliveira <bruno at abstractj.org> wrote:

> Good morning,
>
> At the present moment we have some critical issues to be fixed before
> stage UPS server 0.11.0 and I'm holding it until Keycloak beta3 be released
> with the solution for this issue
> https://issues.jboss.org/browse/KEYCLOAK-523.
>
> More updates will come during the week, as soon as I get more
> information.
>
> Thanks in advance
>
> --
>
> abstractj
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140616/bc150761/attachment.html 

From lukas.fryc at gmail.com  Mon Jun 16 08:25:08 2014
From: lukas.fryc at gmail.com (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=)
Date: Mon, 16 Jun 2014 14:25:08 +0200
Subject: [aerogear-dev] UPS console: server error response handling on
	client-side
Message-ID: <CAEroY37JM9JY3_L=J=B6wnO=J2=9qNoqVoS6xRUMfHA5UsyV9g@mail.gmail.com>

Hey guys,

I was looking into AGPUSH-720 and I got an perception that not all error
response do we actually know on the client-side.

We should establish a common pattern - contract between server and client -
which says how is a failure message transported from server to client, e.g.:

- response header
- response message body /w given structure


Right now, I've opened a PR for a generic failure handling mechanism that
can catch and report any error:
https://github.com/aerogear/aerogear-unifiedpush-server/pull/226/files

I plan to extend this error handling code dynamically as needed based on
response codes (e.g. 404=Request resource is missing) and contract
mentioned above ^.

Wdyt?


~ Lukas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140616/c786a392/attachment.html 

From edewit at redhat.com  Mon Jun 16 09:03:27 2014
From: edewit at redhat.com (Erik Jan de Wit)
Date: Mon, 16 Jun 2014 15:03:27 +0200
Subject: [aerogear-dev] UPS staging heads up
In-Reply-To: <CAEroY35Pa0k2kmPtZSGDpZtim1p5em91i32YVbNH+45rCm77Qg@mail.gmail.com>
References: <20140616113117.GA76439@abstractj.org>
	<CAEroY35Pa0k2kmPtZSGDpZtim1p5em91i32YVbNH+45rCm77Qg@mail.gmail.com>
Message-ID: <CD48909C-F828-4B16-B994-65B16060B2AB@redhat.com>

I?m on it
On 16 Jun,2014, at 14:16 , Luk?? Fry? <lukas.fryc at gmail.com> wrote:

> Sounds good,
> 
> I have few pull requests opened atm incl. fixes and improvements in the Admin UI 0.11.0.
> 
> If someone could review them and gimme +1 or indicate suggestions for correction,
> the help will be much appreciated:
> 
> https://github.com/aerogear/aerogear-unifiedpush-server/pulls
> 
> ~ Lukas
> 
> 
> On Mon, Jun 16, 2014 at 1:31 PM, Bruno Oliveira <bruno at abstractj.org> wrote:
> Good morning,
> 
> At the present moment we have some critical issues to be fixed before
> stage UPS server 0.11.0 and I'm holding it until Keycloak beta3 be released
> with the solution for this issue https://issues.jboss.org/browse/KEYCLOAK-523.
> 
> More updates will come during the week, as soon as I get more
> information.
> 
> Thanks in advance
> 
> --
> 
> abstractj
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> 
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140616/0ac9ccb8/attachment.html 

From cvasilak at gmail.com  Mon Jun 16 10:13:31 2014
From: cvasilak at gmail.com (Christos Vasilakis)
Date: Mon, 16 Jun 2014 17:13:31 +0300
Subject: [aerogear-dev] Team meeting
In-Reply-To: <CAFJm-3ELwbyKsq8v=3RZ8UM8eV3nMB3F-wW__wK1TifJPuBf_g@mail.gmail.com>
References: <CAFJm-3ELwbyKsq8v=3RZ8UM8eV3nMB3F-wW__wK1TifJPuBf_g@mail.gmail.com>
Message-ID: <6BFCB6F6-E7C5-48C2-A906-0D4E4C8CB08A@gmail.com>

fyi,

our meeting minutes:

<jbott>	 Meeting ended Mon Jun 16 13:54:37 2014 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
<jbott>	 Minutes:        http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-06-16-13.42.html
<jbott>	 Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-06-16-13.42.txt
<jbott>	 Log:            http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-06-16-13.42.log.html

On Jun 16, 2014, at 9:55 AM, Daniel Bevenius <daniel.bevenius at gmail.com> wrote:

> Agenda:
> http://oksoclap.com/p/aerogear-team-mgt-20140616
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140616/bb44f423/attachment.html 

From bruno at abstractj.org  Mon Jun 16 18:06:48 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Mon, 16 Jun 2014 19:06:48 -0300
Subject: [aerogear-dev] Current status of UPS 0.11.0
Message-ID: <20140616220648.GA6896@abstractj.org>

Good morning peeps,

First I would like to thank Bill Burke, Stian, Sebastien and Lukas for dedicating
their time helping with Keycloak integration.

I think we are almost done, this is the current branch:
https://github.com/abstractj/aerogear-unifiedpush-server/tree/keycloak.js. And now most
of issues were gone and is also possible to display the current logged
in user.

Now I'm working on fix the sender endpoint, to be more precise we need
to remove the HTTP basic authentication for sending push messages
now that most of the endpoints are protect by Keycloak. If you try to
send a push message based on my branch you will see the basic
authentication form atm.

If you have a better idea, I'm all ears.

--

abstractj

From daniel.bevenius at gmail.com  Tue Jun 17 01:54:38 2014
From: daniel.bevenius at gmail.com (Daniel Bevenius)
Date: Tue, 17 Jun 2014 07:54:38 +0200
Subject: [aerogear-dev] Current status of UPS 0.11.0
In-Reply-To: <20140616220648.GA6896@abstractj.org>
References: <20140616220648.GA6896@abstractj.org>
Message-ID: <CAFJm-3GTyHOSL5x=XT=iNUJGJghOieWLQoh7p=uSPLQHqgo77A@mail.gmail.com>

Hey Bruno,

I wanted to take a look at this issue but I'm probably missing something
obvious here:(
I'm using your 'keycloak.js' branch and have updated and builtt keycloak
locally, then built aerogear-unified-push-server and first deployed
auth-server.war and then ag-push.war.

When I then access UPS's admin console using http://localhost:8080/ag-push
I the page looks like the screenshot I've attached,  I'm not seeing any
error in the server console or the browser console, and I'm not able to
really do anything on this page, like click on the user for example.
Let me know if there is some step that I've forgotten.

Thanks,

/Dan




On 17 June 2014 00:06, Bruno Oliveira <bruno at abstractj.org> wrote:

> Good morning peeps,
>
> First I would like to thank Bill Burke, Stian, Sebastien and Lukas for
> dedicating
> their time helping with Keycloak integration.
>
> I think we are almost done, this is the current branch:
> https://github.com/abstractj/aerogear-unifiedpush-server/tree/keycloak.js.
> And now most
> of issues were gone and is also possible to display the current logged
> in user.
>
> Now I'm working on fix the sender endpoint, to be more precise we need
> to remove the HTTP basic authentication for sending push messages
> now that most of the endpoints are protect by Keycloak. If you try to
> send a push message based on my branch you will see the basic
> authentication form atm.
>
> If you have a better idea, I'm all ears.
>
> --
>
> abstractj
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140617/3d69c421/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: admin-console.png
Type: image/png
Size: 70094 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140617/3d69c421/attachment-0001.png 

From matzew at apache.org  Tue Jun 17 02:59:06 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Tue, 17 Jun 2014 08:59:06 +0200
Subject: [aerogear-dev] Current status of UPS 0.11.0
In-Reply-To: <20140616220648.GA6896@abstractj.org>
References: <20140616220648.GA6896@abstractj.org>
Message-ID: <CAAg5f2RuLkX1ijJdS56kZv6PV3_UAvfJD8u4+4YwnN_O2bVurw@mail.gmail.com>

Bom Dia!


On Tue, Jun 17, 2014 at 12:06 AM, Bruno Oliveira <bruno at abstractj.org>
wrote:

> Good morning peeps,
>
> First I would like to thank Bill Burke, Stian, Sebastien and Lukas for
> dedicating
> their time helping with Keycloak integration.
>

Great to hear! :-)


>
> I think we are almost done, this is the current branch:
> https://github.com/abstractj/aerogear-unifiedpush-server/tree/keycloak.js.
> And now most
> of issues were gone and is also possible to display the current logged
> in user.
>
> Now I'm working on fix the sender endpoint, to be more precise we need
> to remove the HTTP basic authentication for sending push messages
> now that most of the endpoints are protect by Keycloak.


Is the reason here that the 'sending endpoint' is also accessed from the
AdminUI, for the 'compose a push' feature?

If it's really required I am OK with that. However, I'd prefer to avoid it,
as changing the behaviour of one of our two HTTP_BASIC endpoints ('device
registration' and 'sending') also requires changes/updates on the relevant
client SDKs.

Greetings,
Matthias




> If you try to
> send a push message based on my branch you will see the basic
> authentication form atm.
>
> If you have a better idea, I'm all ears.
>
> --
>
> abstractj
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140617/227598f4/attachment.html 

From lukas.fryc at gmail.com  Tue Jun 17 04:41:17 2014
From: lukas.fryc at gmail.com (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=)
Date: Tue, 17 Jun 2014 10:41:17 +0200
Subject: [aerogear-dev] UPS admin-ui distribution compiled by
	frontend-maven-plugin
In-Reply-To: <20140604115600.03437480@kapy-ntb-x220>
References: <CAEroY35YqT=B6G4a4YAHS5t0hgdA=gtjXjvbfUrHVHJuAF+g9Q@mail.gmail.com>
	<20140602164035.03c2060e@kapy-ntb-x220>
	<CAAg5f2Srvm9DoWcY9MP451xqOw7B__9MMa0vNdE+pTNYgkTePQ@mail.gmail.com>
	<20140602173402.3896e648@kapy-ntb-x220>
	<CAAg5f2QMxEwbMK3MFXPhdahq2yP15=GkLbc3BSD+k8kHEuCTOg@mail.gmail.com>
	<20140604115600.03437480@kapy-ntb-x220>
Message-ID: <CAEroY37ekH039G0=ZEP7yJ20TgPOKQMh34xq2a-RLXzdwFVgvg@mail.gmail.com>

FYI

ad) frontend-maven-plugin integration

Viliam gave liveoak's console one more try and successfully integrated the
maven/grunt build with frontend-maven-plugin.

http://mail-archive.liveoak.io/Console-downloads-stuff-during-build-td2002.html

He reports it works just fine on OSX and Linux machines.




On Wed, Jun 4, 2014 at 11:56 AM, Karel Piwko <kpiwko at redhat.com> wrote:

> On Mon, 2 Jun 2014 17:55:43 +0200
> Matthias Wessendorf <matzew at apache.org> wrote:
> > >
> > > Correct but the plugin would hide the fact there are two masters
> involved.>
> >
> > two masters? master in terms of git?
>
> Exactly. Recently, I've noticed that UI has been merged to UPS repository,
> so
> this would not be an issue any more. Two masters no more.
>
>
> https://github.com/aerogear/aerogear-unifiedpush-server/tree/master/admin-ui
>
> >
> >
> > > If
> > > we had UI as <dependency> with version -SNAPSHOT in pom.xml, that's a
> > > different
> > > thing.
> > >
> >
> > as said earlier, I think Keycloak does that. But I am not sure on the
> > details of the UI bundling
> >
>
> KC has Angular as a part of regular Maven module:
>
> https://github.com/keycloak/keycloak/tree/master/forms/common-themes
>
> The problem here I'm presuming is a need to produce jar
> of admin-ui, which means bringing Ant/Maven/Gradle/Grunt task
> (maybe grunt-sync-jar) into current UI build.
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140617/83eea0fc/attachment.html 

From lukas.fryc at gmail.com  Tue Jun 17 06:00:43 2014
From: lukas.fryc at gmail.com (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=)
Date: Tue, 17 Jun 2014 12:00:43 +0200
Subject: [aerogear-dev] Current status of UPS 0.11.0
In-Reply-To: <CAAg5f2RuLkX1ijJdS56kZv6PV3_UAvfJD8u4+4YwnN_O2bVurw@mail.gmail.com>
References: <20140616220648.GA6896@abstractj.org>
	<CAAg5f2RuLkX1ijJdS56kZv6PV3_UAvfJD8u4+4YwnN_O2bVurw@mail.gmail.com>
Message-ID: <CAEroY34JPtOf=O0fOccwVKDUQbEWjjvxZC=A9hnewLB0EjCzmA@mail.gmail.com>

Hey guys,

I've did some stabilizations inside the Bruno's keycloak.js branch and then
rebased it against master.

I've also shared this branch on aerogear/aerogear-unified-push-server repo,
so we could all work on it:

https://github.com/aerogear/aerogear-unifiedpush-server/tree/keycloak.js


Dan, I believe this branch should fix issues you were seeing.

~ Lukas


On Tue, Jun 17, 2014 at 8:59 AM, Matthias Wessendorf <matzew at apache.org>
wrote:

> Bom Dia!
>
>
> On Tue, Jun 17, 2014 at 12:06 AM, Bruno Oliveira <bruno at abstractj.org>
> wrote:
>
>> Good morning peeps,
>>
>> First I would like to thank Bill Burke, Stian, Sebastien and Lukas for
>> dedicating
>> their time helping with Keycloak integration.
>>
>
> Great to hear! :-)
>
>
>>
>> I think we are almost done, this is the current branch:
>> https://github.com/abstractj/aerogear-unifiedpush-server/tree/keycloak.js.
>> And now most
>> of issues were gone and is also possible to display the current logged
>> in user.
>>
>> Now I'm working on fix the sender endpoint, to be more precise we need
>> to remove the HTTP basic authentication for sending push messages
>> now that most of the endpoints are protect by Keycloak.
>
>
> Is the reason here that the 'sending endpoint' is also accessed from the
> AdminUI, for the 'compose a push' feature?
>
> If it's really required I am OK with that. However, I'd prefer to avoid
> it, as changing the behaviour of one of our two HTTP_BASIC endpoints
> ('device registration' and 'sending') also requires changes/updates on the
> relevant client SDKs.
>
> Greetings,
> Matthias
>
>
>
>
>> If you try to
>> send a push message based on my branch you will see the basic
>> authentication form atm.
>>
>> If you have a better idea, I'm all ears.
>>
>> --
>>
>> abstractj
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140617/1ecae688/attachment.html 

From lukas.fryc at gmail.com  Tue Jun 17 06:04:50 2014
From: lukas.fryc at gmail.com (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=)
Date: Tue, 17 Jun 2014 12:04:50 +0200
Subject: [aerogear-dev] Current status of UPS 0.11.0
In-Reply-To: <CAEroY34JPtOf=O0fOccwVKDUQbEWjjvxZC=A9hnewLB0EjCzmA@mail.gmail.com>
References: <20140616220648.GA6896@abstractj.org>
	<CAAg5f2RuLkX1ijJdS56kZv6PV3_UAvfJD8u4+4YwnN_O2bVurw@mail.gmail.com>
	<CAEroY34JPtOf=O0fOccwVKDUQbEWjjvxZC=A9hnewLB0EjCzmA@mail.gmail.com>
Message-ID: <CAEroY3583CMWT_W8oxh-SWM1h5pDf8hV1WR57rvnT+_Z3+2+jQ@mail.gmail.com>

Btw,

are we ready to merge keycloak.js branch into master and continue work
there?


On Tue, Jun 17, 2014 at 12:00 PM, Luk?? Fry? <lukas.fryc at gmail.com> wrote:

> Hey guys,
>
> I've did some stabilizations inside the Bruno's keycloak.js branch and
> then rebased it against master.
>
> I've also shared this branch on aerogear/aerogear-unified-push-server
> repo, so we could all work on it:
>
> https://github.com/aerogear/aerogear-unifiedpush-server/tree/keycloak.js
>
>
> Dan, I believe this branch should fix issues you were seeing.
>
> ~ Lukas
>
>
> On Tue, Jun 17, 2014 at 8:59 AM, Matthias Wessendorf <matzew at apache.org>
> wrote:
>
>> Bom Dia!
>>
>>
>> On Tue, Jun 17, 2014 at 12:06 AM, Bruno Oliveira <bruno at abstractj.org>
>> wrote:
>>
>>> Good morning peeps,
>>>
>>> First I would like to thank Bill Burke, Stian, Sebastien and Lukas for
>>> dedicating
>>> their time helping with Keycloak integration.
>>>
>>
>> Great to hear! :-)
>>
>>
>>>
>>> I think we are almost done, this is the current branch:
>>> https://github.com/abstractj/aerogear-unifiedpush-server/tree/keycloak.js.
>>> And now most
>>> of issues were gone and is also possible to display the current logged
>>> in user.
>>>
>>> Now I'm working on fix the sender endpoint, to be more precise we need
>>> to remove the HTTP basic authentication for sending push messages
>>> now that most of the endpoints are protect by Keycloak.
>>
>>
>> Is the reason here that the 'sending endpoint' is also accessed from the
>> AdminUI, for the 'compose a push' feature?
>>
>> If it's really required I am OK with that. However, I'd prefer to avoid
>> it, as changing the behaviour of one of our two HTTP_BASIC endpoints
>> ('device registration' and 'sending') also requires changes/updates on the
>> relevant client SDKs.
>>
>> Greetings,
>> Matthias
>>
>>
>>
>>
>>> If you try to
>>> send a push message based on my branch you will see the basic
>>> authentication form atm.
>>>
>>> If you have a better idea, I'm all ears.
>>>
>>> --
>>>
>>> abstractj
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> sessions: http://www.slideshare.net/mwessendorf
>> twitter: http://twitter.com/mwessendorf
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140617/79f22b06/attachment-0001.html 

From bruno at abstractj.org  Tue Jun 17 10:26:25 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Tue, 17 Jun 2014 11:26:25 -0300
Subject: [aerogear-dev] Keycloak integration and UPS Sender
Message-ID: <20140617142624.GA23555@abstractj.org>

Good morning peeps,

I have a problem to solve which might affect the Sender and
all the related clients.

Previously, the UPS Sender was protected by the basic authentication
method[1], so anyone in possession of _PushApplicationID_ and
_MasterSecret_ is able to send push messages.

After the integration with Keycloak now everything under _/rest_
is properly protect by KC which is totally correct. Our sender is under
the same umbrella which means that now Bearer token authentication is
required[2] and Basic authentication won't exist anymore.

The consequence of this is the basic form being presented when you try
to send push notifications[3]. The problem didn't occur before, because
we were just using Basic authentication[4] instead of Bearer tokens.

Possible solutions:

1- After the removal of Basic authentication, move _PushApplicationID_
and _MasterSecret to http headers like:

-H "PushApplicationID: XXXXXX" -H "MasterSecret: 42"

IMO it sounds correct and reasonable for me.

2. Create a role specific for the sender like _push-applications_ and
dinamically add _PushApplicationID_ and _MasterSecret on Keycloak where:

username: _PushApplicationID_
password: _MasterSecret_

The implications of this alternative is the fact of have to manage those
credentials on the server side inclusion/exclusion/login

3. Implement another authentication provider specifically for the sender
and Basic authentication[5]

4. Do nothing. The consequences of this alternative is to implement
everything already done by Keycloak.js and manage session tokens by hand
on the admin-ui.

To me the first alternative seems to be more simple, but I really want
your feedback on it, once it affects the whole project.

[1] -
https://github.com/aerogear/aerogear-unifiedpush-server/blob/6c1a0d3fedea8fb6ba918009fd8e9785779c151f/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/sender/PushNotificationSenderEndpoint.java#L56

[2] -
https://github.com/abstractj/aerogear-unifiedpush-server/tree/keycloak.js
[3] -
http://photon.abstractj.org/AeroGear_UnifiedPush_Server_2014-06-17_10-00-09_2014-06-17_10-00-12.jpg

[4] -
https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/server/src/main/webapp/WEB-INF/web.xml#L57

[5] - https://github.com/keycloak/keycloak/tree/master/examples/providers/authentication-properties

--

abstractj

From jbalunas at redhat.com  Tue Jun 17 11:26:17 2014
From: jbalunas at redhat.com (Jay Balunas)
Date: Tue, 17 Jun 2014 11:26:17 -0400
Subject: [aerogear-dev] Keycloak integration and UPS Sender
In-Reply-To: <20140617142624.GA23555@abstractj.org>
References: <20140617142624.GA23555@abstractj.org>
Message-ID: <B6A470CC-DE76-4A00-B56B-76434079BDEA@redhat.com>

Great explanation of the issue and options!  

On Jun 17, 2014, at 10:26 AM, Bruno Oliveira <bruno at abstractj.org> wrote:

> Good morning peeps,
> 
> I have a problem to solve which might affect the Sender and
> all the related clients.
> 
> Previously, the UPS Sender was protected by the basic authentication
> method[1], so anyone in possession of _PushApplicationID_ and
> _MasterSecret_ is able to send push messages.
> 
> After the integration with Keycloak now everything under _/rest_
> is properly protect by KC which is totally correct. Our sender is under
> the same umbrella which means that now Bearer token authentication is
> required[2] and Basic authentication won't exist anymore.
> 
> The consequence of this is the basic form being presented when you try
> to send push notifications[3]. The problem didn't occur before, because
> we were just using Basic authentication[4] instead of Bearer tokens.
> 
> Possible solutions:
> 
> 1- After the removal of Basic authentication, move _PushApplicationID_
> and _MasterSecret to http headers like:
> 
> -H "PushApplicationID: XXXXXX" -H "MasterSecret: 42"
> 
> IMO it sounds correct and reasonable for me.

How will this impact CURL usage from the command line?
How will this impact Java sender usage?

> 
> 2. Create a role specific for the sender like _push-applications_ and
> dinamically add _PushApplicationID_ and _MasterSecret on Keycloak where:
> 
> username: _PushApplicationID_
> password: _MasterSecret_
> 
> The implications of this alternative is the fact of have to manage those
> credentials on the server side inclusion/exclusion/login

Would each application have its own "role" just for the sender in this case?

> 
> 3. Implement another authentication provider specifically for the sender
> and Basic authentication[5]

Not sure of the impact here, but sounds like a complex solution.

> 
> 4. Do nothing. The consequences of this alternative is to implement
> everything already done by Keycloak.js and manage session tokens by hand
> on the admin-ui.

-1

> 
> To me the first alternative seems to be more simple, but I really want
> your feedback on it, once it affects the whole project.
> 
> [1] -
> https://github.com/aerogear/aerogear-unifiedpush-server/blob/6c1a0d3fedea8fb6ba918009fd8e9785779c151f/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/sender/PushNotificationSenderEndpoint.java#L56
> 
> [2] -
> https://github.com/abstractj/aerogear-unifiedpush-server/tree/keycloak.js
> [3] -
> http://photon.abstractj.org/AeroGear_UnifiedPush_Server_2014-06-17_10-00-09_2014-06-17_10-00-12.jpg
> 
> [4] -
> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/server/src/main/webapp/WEB-INF/web.xml#L57
> 
> [5] - https://github.com/keycloak/keycloak/tree/master/examples/providers/authentication-properties
> 
> --
> 
> abstractj
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev



From kpiwko at redhat.com  Tue Jun 17 11:42:35 2014
From: kpiwko at redhat.com (Karel Piwko)
Date: Tue, 17 Jun 2014 17:42:35 +0200
Subject: [aerogear-dev] Current status of UPS 0.11.0
In-Reply-To: <20140616220648.GA6896@abstractj.org>
References: <20140616220648.GA6896@abstractj.org>
Message-ID: <20140617174235.7ebc5d09@kapy-ntb-x220>

We definitely need a way how get bearer token from auth server without a form
popping out if we are going to remove HTTP Basic. UPS is supposed to be used
also by other applications using REST endpoints apart from Admin UI. E.g. you
want to show all iOS installations on variant FooBar in your own dashboard
application.

Sender is the same case, your application might want to send a message via UPS.
It might be using either JavaSender or direct REST calls. Ability to authorize
your app non-interactively is crucial here.

Karel

On Mon, 16 Jun 2014 19:06:48 -0300
Bruno Oliveira <bruno at abstractj.org> wrote:

> Good morning peeps,
> 
> First I would like to thank Bill Burke, Stian, Sebastien and Lukas for
> dedicating their time helping with Keycloak integration.
> 
> I think we are almost done, this is the current branch:
> https://github.com/abstractj/aerogear-unifiedpush-server/tree/keycloak.js.
> And now most of issues were gone and is also possible to display the current
> logged in user.
> 
> Now I'm working on fix the sender endpoint, to be more precise we need
> to remove the HTTP basic authentication for sending push messages
> now that most of the endpoints are protect by Keycloak. If you try to
> send a push message based on my branch you will see the basic
> authentication form atm.
> 
> If you have a better idea, I'm all ears.
> 
> --
> 
> abstractj
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


From matzew at apache.org  Tue Jun 17 12:37:12 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Tue, 17 Jun 2014 18:37:12 +0200
Subject: [aerogear-dev] Keycloak integration and UPS Sender
In-Reply-To: <20140617142624.GA23555@abstractj.org>
References: <20140617142624.GA23555@abstractj.org>
Message-ID: <CAAg5f2Ry2KWC1WOp64hoS9udX1OWFFz=ZH0En9qx07gE5vC0Eg@mail.gmail.com>

On Tue, Jun 17, 2014 at 4:26 PM, Bruno Oliveira <bruno at abstractj.org> wrote:

> Good morning peeps,
>
> I have a problem to solve which might affect the Sender and
> all the related clients.
>
> Previously, the UPS Sender was protected by the basic authentication
> method[1], so anyone in possession of _PushApplicationID_ and
> _MasterSecret_ is able to send push messages.
>
> After the integration with Keycloak now everything under _/rest_
> is properly protect by KC which is totally correct. Our sender is under
> the same umbrella which means that now Bearer token authentication is
> required[2] and Basic authentication won't exist anymore.
>


The device (un)registration endpoints are hit by this as well
(/rest/registry/device/*).

I am wondering if it isn't it possible to keep those URLs protected via
HTTP_BASIC, or does the keycloak.js usage deny this?

On master (plain keycloak; before keycloak.js usage) we are doing an
exclude for those URLs:
https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/server/src/main/webapp/WEB-INF/web.xml#L46-L52


IMO if possible, keeping these 'exceptions' (or excludes) under HTTP_BASIC
would be the simplest solution, as that means none of our client SDKs
(Android, iOS, Cordova, Node.js Sender, Java-Sendet etc) would require an
update.

-Matthias





>
> The consequence of this is the basic form being presented when you try
> to send push notifications[3]. The problem didn't occur before, because
> we were just using Basic authentication[4] instead of Bearer tokens.
>
> Possible solutions:
>
> 1- After the removal of Basic authentication, move _PushApplicationID_
> and _MasterSecret to http headers like:
>
> -H "PushApplicationID: XXXXXX" -H "MasterSecret: 42"
>
> IMO it sounds correct and reasonable for me.
>
> 2. Create a role specific for the sender like _push-applications_ and
> dinamically add _PushApplicationID_ and _MasterSecret on Keycloak where:
>
> username: _PushApplicationID_
> password: _MasterSecret_
>
> The implications of this alternative is the fact of have to manage those
> credentials on the server side inclusion/exclusion/login
>
> 3. Implement another authentication provider specifically for the sender
> and Basic authentication[5]
>
> 4. Do nothing. The consequences of this alternative is to implement
> everything already done by Keycloak.js and manage session tokens by hand
> on the admin-ui.
>
> To me the first alternative seems to be more simple, but I really want
> your feedback on it, once it affects the whole project.
>
> [1] -
>
> https://github.com/aerogear/aerogear-unifiedpush-server/blob/6c1a0d3fedea8fb6ba918009fd8e9785779c151f/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/sender/PushNotificationSenderEndpoint.java#L56
>
> [2] -
> https://github.com/abstractj/aerogear-unifiedpush-server/tree/keycloak.js
> [3] -
>
> http://photon.abstractj.org/AeroGear_UnifiedPush_Server_2014-06-17_10-00-09_2014-06-17_10-00-12.jpg
>
> [4] -
>
> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/server/src/main/webapp/WEB-INF/web.xml#L57
>
> [5] -
> https://github.com/keycloak/keycloak/tree/master/examples/providers/authentication-properties
>
> --
>
> abstractj
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140617/26d13a1c/attachment.html 

From scm.blanc at gmail.com  Tue Jun 17 12:51:56 2014
From: scm.blanc at gmail.com (=?utf-8?Q?S=C3=A9bastien_Blanc?=)
Date: Tue, 17 Jun 2014 18:51:56 +0200
Subject: [aerogear-dev] Keycloak integration and UPS Sender
In-Reply-To: <CAAg5f2Ry2KWC1WOp64hoS9udX1OWFFz=ZH0En9qx07gE5vC0Eg@mail.gmail.com>
References: <20140617142624.GA23555@abstractj.org>
	<CAAg5f2Ry2KWC1WOp64hoS9udX1OWFFz=ZH0En9qx07gE5vC0Eg@mail.gmail.com>
Message-ID: <83E00FE8-5864-434D-BA98-1C8C9AB9B270@gmail.com>



Envoy? de mon iPhone

> Le 17 juin 2014 ? 18:37, Matthias Wessendorf <matzew at apache.org> a ?crit :
> 
> 
> 
> 
>> On Tue, Jun 17, 2014 at 4:26 PM, Bruno Oliveira <bruno at abstractj.org> wrote:
>> Good morning peeps,
>> 
>> I have a problem to solve which might affect the Sender and
>> all the related clients.
>> 
>> Previously, the UPS Sender was protected by the basic authentication
>> method[1], so anyone in possession of _PushApplicationID_ and
>> _MasterSecret_ is able to send push messages.
>> 
>> After the integration with Keycloak now everything under _/rest_
>> is properly protect by KC which is totally correct. Our sender is under
>> the same umbrella which means that now Bearer token authentication is
>> required[2] and Basic authentication won't exist anymore.
> 
> 
> The device (un)registration endpoints are hit by this as well (/rest/registry/device/*).
> 
> I am wondering if it isn't it possible to keep those URLs protected via HTTP_BASIC, or does the keycloak.js usage deny this?
> 
> On master (plain keycloak; before keycloak.js usage) we are doing an exclude for those URLs:
> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/server/src/main/webapp/WEB-INF/web.xml#L46-L52
> 
> 
> IMO if possible, keeping these 'exceptions' (or excludes) under HTTP_BASIC would be the simplest solution, as that means none of our client SDKs (Android, iOS, Cordova, Node.js Sender, Java-Sendet etc) would require an update.
+9001
> 
> -Matthias
> 
> 
> 
>  
>> 
>> The consequence of this is the basic form being presented when you try
>> to send push notifications[3]. The problem didn't occur before, because
>> we were just using Basic authentication[4] instead of Bearer tokens.
>> 
>> Possible solutions:
>> 
>> 1- After the removal of Basic authentication, move _PushApplicationID_
>> and _MasterSecret to http headers like:
>> 
>> -H "PushApplicationID: XXXXXX" -H "MasterSecret: 42"
>> 
>> IMO it sounds correct and reasonable for me.
>> 
>> 2. Create a role specific for the sender like _push-applications_ and
>> dinamically add _PushApplicationID_ and _MasterSecret on Keycloak where:
>> 
>> username: _PushApplicationID_
>> password: _MasterSecret_
>> 
>> The implications of this alternative is the fact of have to manage those
>> credentials on the server side inclusion/exclusion/login
>> 
>> 3. Implement another authentication provider specifically for the sender
>> and Basic authentication[5]
>> 
>> 4. Do nothing. The consequences of this alternative is to implement
>> everything already done by Keycloak.js and manage session tokens by hand
>> on the admin-ui.
>> 
>> To me the first alternative seems to be more simple, but I really want
>> your feedback on it, once it affects the whole project.
>> 
>> [1] -
>> https://github.com/aerogear/aerogear-unifiedpush-server/blob/6c1a0d3fedea8fb6ba918009fd8e9785779c151f/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/sender/PushNotificationSenderEndpoint.java#L56
>> 
>> [2] -
>> https://github.com/abstractj/aerogear-unifiedpush-server/tree/keycloak.js
>> [3] -
>> http://photon.abstractj.org/AeroGear_UnifiedPush_Server_2014-06-17_10-00-09_2014-06-17_10-00-12.jpg
>> 
>> [4] -
>> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/server/src/main/webapp/WEB-INF/web.xml#L57
>> 
>> [5] - https://github.com/keycloak/keycloak/tree/master/examples/providers/authentication-properties
>> 
>> --
>> 
>> abstractj
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> 
> 
> 
> -- 
> Matthias Wessendorf 
> 
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140617/ee1089ca/attachment-0001.html 

From bruno at abstractj.org  Tue Jun 17 13:17:36 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Tue, 17 Jun 2014 14:17:36 -0300
Subject: [aerogear-dev] Keycloak integration and UPS Sender
In-Reply-To: <CAAg5f2Ry2KWC1WOp64hoS9udX1OWFFz=ZH0En9qx07gE5vC0Eg@mail.gmail.com>
References: <20140617142624.GA23555@abstractj.org>
	<CAAg5f2Ry2KWC1WOp64hoS9udX1OWFFz=ZH0En9qx07gE5vC0Eg@mail.gmail.com>
Message-ID: <20140617171736.GA32200@abstractj.org>

Hi Matthias, answer inline.

On 2014-06-17, Matthias Wessendorf wrote:
> On Tue, Jun 17, 2014 at 4:26 PM, Bruno Oliveira <bruno at abstractj.org> wrote:
>
> > Good morning peeps,
> >
> > I have a problem to solve which might affect the Sender and
> > all the related clients.
> >
> > Previously, the UPS Sender was protected by the basic authentication
> > method[1], so anyone in possession of _PushApplicationID_ and
> > _MasterSecret_ is able to send push messages.
> >
> > After the integration with Keycloak now everything under _/rest_
> > is properly protect by KC which is totally correct. Our sender is under
> > the same umbrella which means that now Bearer token authentication is
> > required[2] and Basic authentication won't exist anymore.
> >
>
>
> The device (un)registration endpoints are hit by this as well
> (/rest/registry/device/*).

Currently Keycloak is protecting our endpoints under /rest/*

>
> I am wondering if it isn't it possible to keep those URLs protected via
> HTTP_BASIC, or does the keycloak.js usage deny this?

Is not the Keycloak.js usage responsible for this, but the correct
configuration of the application atm. Please compare:

- master branch:
  https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/server/src/main/webapp/WEB-INF/web.xml#L56
- keycloak.js branch:
  https://github.com/aerogear/aerogear-unifiedpush-server/blob/keycloak.js/server/src/main/webapp/WEB-INF/web.xml#L33

Now we're fully using Keycloak bearer tokens instead of Basic.

>
> On master (plain keycloak; before keycloak.js usage) we are doing an
> exclude for those URLs:
> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/server/src/main/webapp/WEB-INF/web.xml#L46-L52

I tried to include your exclusions, but that didn't work for me.

>
>
> IMO if possible, keeping these 'exceptions' (or excludes) under HTTP_BASIC
> would be the simplest solution, as that means none of our client SDKs
> (Android, iOS, Cordova, Node.js Sender, Java-Sendet etc) would require an
> update.

I had a chat with Stian and looks like it's possible to support both
auth methods in a single app, but that would involve changes on Keycloak.
It's just the matter of discuss with KC team.

My two cents is the fact that we should use bearer tokens only, instead
of mix both auth methods in a single app ? now that we have KC.
And discuss the changes into our clients rather sooner than later.

But I'm open for whatever you guys think it's the best.


>
> -Matthias
>
>
>
>
>
> >
> > The consequence of this is the basic form being presented when you try
> > to send push notifications[3]. The problem didn't occur before, because
> > we were just using Basic authentication[4] instead of Bearer tokens.
> >
> > Possible solutions:
> >
> > 1- After the removal of Basic authentication, move _PushApplicationID_
> > and _MasterSecret to http headers like:
> >
> > -H "PushApplicationID: XXXXXX" -H "MasterSecret: 42"
> >
> > IMO it sounds correct and reasonable for me.
> >
> > 2. Create a role specific for the sender like _push-applications_ and
> > dinamically add _PushApplicationID_ and _MasterSecret on Keycloak where:
> >
> > username: _PushApplicationID_
> > password: _MasterSecret_
> >
> > The implications of this alternative is the fact of have to manage those
> > credentials on the server side inclusion/exclusion/login
> >
> > 3. Implement another authentication provider specifically for the sender
> > and Basic authentication[5]
> >
> > 4. Do nothing. The consequences of this alternative is to implement
> > everything already done by Keycloak.js and manage session tokens by hand
> > on the admin-ui.
> >
> > To me the first alternative seems to be more simple, but I really want
> > your feedback on it, once it affects the whole project.
> >
> > [1] -
> >
> > https://github.com/aerogear/aerogear-unifiedpush-server/blob/6c1a0d3fedea8fb6ba918009fd8e9785779c151f/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/sender/PushNotificationSenderEndpoint.java#L56
> >
> > [2] -
> > https://github.com/abstractj/aerogear-unifiedpush-server/tree/keycloak.js
> > [3] -
> >
> > http://photon.abstractj.org/AeroGear_UnifiedPush_Server_2014-06-17_10-00-09_2014-06-17_10-00-12.jpg
> >
> > [4] -
> >
> > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/server/src/main/webapp/WEB-INF/web.xml#L57
> >
> > [5] -
> > https://github.com/keycloak/keycloak/tree/master/examples/providers/authentication-properties
> >
> > --
> >
> > abstractj
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf

> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


--

abstractj

From bruno at abstractj.org  Tue Jun 17 13:23:32 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Tue, 17 Jun 2014 14:23:32 -0300
Subject: [aerogear-dev] Keycloak integration and UPS Sender
In-Reply-To: <B6A470CC-DE76-4A00-B56B-76434079BDEA@redhat.com>
References: <20140617142624.GA23555@abstractj.org>
	<B6A470CC-DE76-4A00-B56B-76434079BDEA@redhat.com>
Message-ID: <20140617172332.GB32200@abstractj.org>

Ahoy Jay, answers inline.

On 2014-06-17, Jay Balunas wrote:
> Great explanation of the issue and options!
>
> On Jun 17, 2014, at 10:26 AM, Bruno Oliveira <bruno at abstractj.org> wrote:
>
> > Good morning peeps,
> >
> > I have a problem to solve which might affect the Sender and
> > all the related clients.
> >
> > Previously, the UPS Sender was protected by the basic authentication
> > method[1], so anyone in possession of _PushApplicationID_ and
> > _MasterSecret_ is able to send push messages.
> >
> > After the integration with Keycloak now everything under _/rest_
> > is properly protect by KC which is totally correct. Our sender is under
> > the same umbrella which means that now Bearer token authentication is
> > required[2] and Basic authentication won't exist anymore.
> >
> > The consequence of this is the basic form being presented when you try
> > to send push notifications[3]. The problem didn't occur before, because
> > we were just using Basic authentication[4] instead of Bearer tokens.
> >
> > Possible solutions:
> >
> > 1- After the removal of Basic authentication, move _PushApplicationID_
> > and _MasterSecret to http headers like:
> >
> > -H "PushApplicationID: XXXXXX" -H "MasterSecret: 42"
> >
> > IMO it sounds correct and reasonable for me.
>
> How will this impact CURL usage from the command line?
> How will this impact Java sender usage?

We would change from (being logged in would be required):

curl -3 -u "{PushApplicationID}:{MasterSecret}"
   -v -H "Accept: application/json" -H "Content-type: application/json"
      -X POST

To:

curl -3
   -v -H "PushApplicationID: XXXXXX" -H "MasterSecret: 42" \
      -H "Accept: application/json" -H "Content-type: application/json"
      -X POST

>
> >
> > 2. Create a role specific for the sender like _push-applications_ and
> > dinamically add _PushApplicationID_ and _MasterSecret on Keycloak where:
> >
> > username: _PushApplicationID_
> > password: _MasterSecret_
> >
> > The implications of this alternative is the fact of have to manage those
> > credentials on the server side inclusion/exclusion/login
>
> Would each application have its own "role" just for the sender in this case?

Each application would have the same role "ups-application".

>
> >
> > 3. Implement another authentication provider specifically for the sender
> > and Basic authentication[5]
>
> Not sure of the impact here, but sounds like a complex solution.

Yes, totally agree on that.

>
> >
> > 4. Do nothing. The consequences of this alternative is to implement
> > everything already done by Keycloak.js and manage session tokens by hand
> > on the admin-ui.
>
> -1

Stian sent to me a message, he might have more ideas about how to
overcome this issue. I will update you guys during this week.

>
> >
> > To me the first alternative seems to be more simple, but I really want
> > your feedback on it, once it affects the whole project.
> >
> > [1] -
> > https://github.com/aerogear/aerogear-unifiedpush-server/blob/6c1a0d3fedea8fb6ba918009fd8e9785779c151f/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/sender/PushNotificationSenderEndpoint.java#L56
> >
> > [2] -
> > https://github.com/abstractj/aerogear-unifiedpush-server/tree/keycloak.js
> > [3] -
> > http://photon.abstractj.org/AeroGear_UnifiedPush_Server_2014-06-17_10-00-09_2014-06-17_10-00-12.jpg
> >
> > [4] -
> > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/server/src/main/webapp/WEB-INF/web.xml#L57
> >
> > [5] - https://github.com/keycloak/keycloak/tree/master/examples/providers/authentication-properties
> >
> > --
> >
> > abstractj
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev

--

abstractj

From matzew at apache.org  Tue Jun 17 14:51:05 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Tue, 17 Jun 2014 20:51:05 +0200
Subject: [aerogear-dev] Keycloak integration and UPS Sender
In-Reply-To: <20140617171736.GA32200@abstractj.org>
References: <20140617142624.GA23555@abstractj.org>
	<CAAg5f2Ry2KWC1WOp64hoS9udX1OWFFz=ZH0En9qx07gE5vC0Eg@mail.gmail.com>
	<20140617171736.GA32200@abstractj.org>
Message-ID: <CAAg5f2S1bxQC6k0dLxXAhd7LX8aj0XakUDSX+TLmzUUeqMG36w@mail.gmail.com>

On Tue, Jun 17, 2014 at 7:17 PM, Bruno Oliveira <bruno at abstractj.org> wrote:

> Hi Matthias, answer inline.
>
> On 2014-06-17, Matthias Wessendorf wrote:
> > On Tue, Jun 17, 2014 at 4:26 PM, Bruno Oliveira <bruno at abstractj.org>
> wrote:
> >
> > > Good morning peeps,
> > >
> > > I have a problem to solve which might affect the Sender and
> > > all the related clients.
> > >
> > > Previously, the UPS Sender was protected by the basic authentication
> > > method[1], so anyone in possession of _PushApplicationID_ and
> > > _MasterSecret_ is able to send push messages.
> > >
> > > After the integration with Keycloak now everything under _/rest_
> > > is properly protect by KC which is totally correct. Our sender is under
> > > the same umbrella which means that now Bearer token authentication is
> > > required[2] and Basic authentication won't exist anymore.
> > >
> >
> >
> > The device (un)registration endpoints are hit by this as well
> > (/rest/registry/device/*).
>
> Currently Keycloak is protecting our endpoints under /rest/*
>
> >
> > I am wondering if it isn't it possible to keep those URLs protected via
> > HTTP_BASIC, or does the keycloak.js usage deny this?
>
> Is not the Keycloak.js usage responsible for this, but the correct
> configuration of the application atm. Please compare:
>
> - master branch:
>
> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/server/src/main/webapp/WEB-INF/web.xml#L56
> - keycloak.js branch:
>
> https://github.com/aerogear/aerogear-unifiedpush-server/blob/keycloak.js/server/src/main/webapp/WEB-INF/web.xml#L33
>
> Now we're fully using Keycloak bearer tokens instead of Basic.
>


Oh, I was following Bill's sample project, where he did not use the
'KEYCLOAK' auth-method:
https://github.com/keycloak/keycloak/blob/master/project-integrations/aerogear-ups/app/src/main/webapp/WEB-INF/web.xml#L44

But we had the exclusion working w/ the KEYCLOAK 'auth-method', but this
goes back to our initial starts in Dec/Jan.
Here is a rebased commit based on your initial commit:
https://github.com/aerogear/aerogear-unifiedpush-server/blob/2aabd073aaaafa79943ea41d2651f6f0c5e4248e/server/src/main/webapp/WEB-INF/web.xml#L42-L53


>
> >
> > On master (plain keycloak; before keycloak.js usage) we are doing an
> > exclude for those URLs:
> >
> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/server/src/main/webapp/WEB-INF/web.xml#L46-L52
>
> I tried to include your exclusions, but that didn't work for me.
>
> >
> >
> > IMO if possible, keeping these 'exceptions' (or excludes) under
> HTTP_BASIC
> > would be the simplest solution, as that means none of our client SDKs
> > (Android, iOS, Cordova, Node.js Sender, Java-Sendet etc) would require an
> > update.
>
> I had a chat with Stian and looks like it's possible to support both
> auth methods in a single app, but that would involve changes on Keycloak.
> It's just the matter of discuss with KC team.
>

I don't think we need to enable to <auth-method> settings in our web.xml;

My initial hope was to be able to simply exclude a few URLs from the
overall Keycloak protection, like the above referenced commit:
https://github.com/aerogear/aerogear-unifiedpush-server/blob/2aabd073aaaafa79943ea41d2651f6f0c5e4248e/server/src/main/webapp/WEB-INF/web.xml#L42-L53

That would be best as that would mean no API change at all, and our
client-registration and sender SDKs could stay as they are.




>
> My two cents is the fact that we should use bearer tokens only, instead
> of mix both auth methods in a single app ? now that we have KC.
> And discuss the changes into our clients rather sooner than later.
>
> But I'm open for whatever you guys think it's the best.
>
>
> >
> > -Matthias
> >
> >
> >
> >
> >
> > >
> > > The consequence of this is the basic form being presented when you try
> > > to send push notifications[3]. The problem didn't occur before, because
> > > we were just using Basic authentication[4] instead of Bearer tokens.
> > >
> > > Possible solutions:
> > >
> > > 1- After the removal of Basic authentication, move _PushApplicationID_
> > > and _MasterSecret to http headers like:
> > >
> > > -H "PushApplicationID: XXXXXX" -H "MasterSecret: 42"
> > >
> > > IMO it sounds correct and reasonable for me.
> > >
> > > 2. Create a role specific for the sender like _push-applications_ and
> > > dinamically add _PushApplicationID_ and _MasterSecret on Keycloak
> where:
> > >
> > > username: _PushApplicationID_
> > > password: _MasterSecret_
> > >
> > > The implications of this alternative is the fact of have to manage
> those
> > > credentials on the server side inclusion/exclusion/login
> > >
> > > 3. Implement another authentication provider specifically for the
> sender
> > > and Basic authentication[5]
> > >
> > > 4. Do nothing. The consequences of this alternative is to implement
> > > everything already done by Keycloak.js and manage session tokens by
> hand
> > > on the admin-ui.
> > >
> > > To me the first alternative seems to be more simple, but I really want
> > > your feedback on it, once it affects the whole project.
> > >
> > > [1] -
> > >
> > >
> https://github.com/aerogear/aerogear-unifiedpush-server/blob/6c1a0d3fedea8fb6ba918009fd8e9785779c151f/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/sender/PushNotificationSenderEndpoint.java#L56
> > >
> > > [2] -
> > >
> https://github.com/abstractj/aerogear-unifiedpush-server/tree/keycloak.js
> > > [3] -
> > >
> > >
> http://photon.abstractj.org/AeroGear_UnifiedPush_Server_2014-06-17_10-00-09_2014-06-17_10-00-12.jpg
> > >
> > > [4] -
> > >
> > >
> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/server/src/main/webapp/WEB-INF/web.xml#L57
> > >
> > > [5] -
> > >
> https://github.com/keycloak/keycloak/tree/master/examples/providers/authentication-properties
> > >
> > > --
> > >
> > > abstractj
> > > _______________________________________________
> > > aerogear-dev mailing list
> > > aerogear-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > >
> >
> >
> >
> > --
> > Matthias Wessendorf
> >
> > blog: http://matthiaswessendorf.wordpress.com/
> > sessions: http://www.slideshare.net/mwessendorf
> > twitter: http://twitter.com/mwessendorf
>
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> --
>
> abstractj
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140617/dcd79c30/attachment-0001.html 

From matzew at apache.org  Tue Jun 17 14:57:13 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Tue, 17 Jun 2014 20:57:13 +0200
Subject: [aerogear-dev] Keycloak integration and UPS Sender
In-Reply-To: <20140617172332.GB32200@abstractj.org>
References: <20140617142624.GA23555@abstractj.org>
	<B6A470CC-DE76-4A00-B56B-76434079BDEA@redhat.com>
	<20140617172332.GB32200@abstractj.org>
Message-ID: <CAAg5f2TgqmkRKWqyjk6kEuMa9Hvgs_RY_7XXdfxrUDsw3kDNag@mail.gmail.com>

Bom Dia!


On Tue, Jun 17, 2014 at 7:23 PM, Bruno Oliveira <bruno at abstractj.org> wrote:

> Ahoy Jay, answers inline.
>
> On 2014-06-17, Jay Balunas wrote:
> > Great explanation of the issue and options!
> >
> > On Jun 17, 2014, at 10:26 AM, Bruno Oliveira <bruno at abstractj.org>
> wrote:
> >
> > > Good morning peeps,
> > >
> > > I have a problem to solve which might affect the Sender and
> > > all the related clients.
> > >
> > > Previously, the UPS Sender was protected by the basic authentication
> > > method[1], so anyone in possession of _PushApplicationID_ and
> > > _MasterSecret_ is able to send push messages.
> > >
> > > After the integration with Keycloak now everything under _/rest_
> > > is properly protect by KC which is totally correct. Our sender is under
> > > the same umbrella which means that now Bearer token authentication is
> > > required[2] and Basic authentication won't exist anymore.
> > >
> > > The consequence of this is the basic form being presented when you try
> > > to send push notifications[3]. The problem didn't occur before, because
> > > we were just using Basic authentication[4] instead of Bearer tokens.
> > >
> > > Possible solutions:
> > >
> > > 1- After the removal of Basic authentication, move _PushApplicationID_
> > > and _MasterSecret to http headers like:
> > >
> > > -H "PushApplicationID: XXXXXX" -H "MasterSecret: 42"
> > >
> > > IMO it sounds correct and reasonable for me.
> >
> > How will this impact CURL usage from the command line?
> > How will this impact Java sender usage?
>
> We would change from (being logged in would be required):
>
> curl -3 -u "{PushApplicationID}:{MasterSecret}"
>    -v -H "Accept: application/json" -H "Content-type: application/json"
>       -X POST
>
> To:
>
> curl -3
>    -v -H "PushApplicationID: XXXXXX" -H "MasterSecret: 42" \
>       -H "Accept: application/json" -H "Content-type: application/json"
>       -X POST
>
>


That sounds like the most safe change to our client-registration and sender
SDKs. Basically a 'minor' change where we issue the HTTP request.

I'd vote for this change, but only if it is not possible to exclude a few
URLs from Keycloak ;-)

Note, that those excluded endpoints (for device-registration and sender)
don't require any <auth-method> setting in web.xml,
as they implement their own simple HTTP_BASIC handling by querying our
database ;-)
https://github.com/abstractj/aerogear-unifiedpush-server/blob/keycloak.js/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/sender/PushNotificationSenderEndpoint.java#L55-L61



But, yeah - if the exclusion is not possible at all, I like your suggested
header usage fix. IMO that's the one with the fewest risks.


-Matthias




> >
> > >
> > > 2. Create a role specific for the sender like _push-applications_ and
> > > dinamically add _PushApplicationID_ and _MasterSecret on Keycloak
> where:
> > >
> > > username: _PushApplicationID_
> > > password: _MasterSecret_
> > >
> > > The implications of this alternative is the fact of have to manage
> those
> > > credentials on the server side inclusion/exclusion/login
> >
> > Would each application have its own "role" just for the sender in this
> case?
>
> Each application would have the same role "ups-application".
>
> >
> > >
> > > 3. Implement another authentication provider specifically for the
> sender
> > > and Basic authentication[5]
> >
> > Not sure of the impact here, but sounds like a complex solution.
>
> Yes, totally agree on that.
>
> >
> > >
> > > 4. Do nothing. The consequences of this alternative is to implement
> > > everything already done by Keycloak.js and manage session tokens by
> hand
> > > on the admin-ui.
> >
> > -1
>
> Stian sent to me a message, he might have more ideas about how to
> overcome this issue. I will update you guys during this week.
>
> >
> > >
> > > To me the first alternative seems to be more simple, but I really want
> > > your feedback on it, once it affects the whole project.
> > >
> > > [1] -
> > >
> https://github.com/aerogear/aerogear-unifiedpush-server/blob/6c1a0d3fedea8fb6ba918009fd8e9785779c151f/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/sender/PushNotificationSenderEndpoint.java#L56
> > >
> > > [2] -
> > >
> https://github.com/abstractj/aerogear-unifiedpush-server/tree/keycloak.js
> > > [3] -
> > >
> http://photon.abstractj.org/AeroGear_UnifiedPush_Server_2014-06-17_10-00-09_2014-06-17_10-00-12.jpg
> > >
> > > [4] -
> > >
> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/server/src/main/webapp/WEB-INF/web.xml#L57
> > >
> > > [5] -
> https://github.com/keycloak/keycloak/tree/master/examples/providers/authentication-properties
> > >
> > > --
> > >
> > > abstractj
> > > _______________________________________________
> > > aerogear-dev mailing list
> > > aerogear-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
> --
>
> abstractj
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140617/b75ae732/attachment.html 

From matzew at apache.org  Tue Jun 17 15:01:28 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Tue, 17 Jun 2014 21:01:28 +0200
Subject: [aerogear-dev] Keycloak integration and UPS Sender
In-Reply-To: <CAAg5f2S1bxQC6k0dLxXAhd7LX8aj0XakUDSX+TLmzUUeqMG36w@mail.gmail.com>
References: <20140617142624.GA23555@abstractj.org>
	<CAAg5f2Ry2KWC1WOp64hoS9udX1OWFFz=ZH0En9qx07gE5vC0Eg@mail.gmail.com>
	<20140617171736.GA32200@abstractj.org>
	<CAAg5f2S1bxQC6k0dLxXAhd7LX8aj0XakUDSX+TLmzUUeqMG36w@mail.gmail.com>
Message-ID: <CAAg5f2RJXsQMdYNjtdf+30Kx6=1sVREoBVB_5Cyry328wcX9Cw@mail.gmail.com>

On Tue, Jun 17, 2014 at 8:51 PM, Matthias Wessendorf <matzew at apache.org>
wrote:

>
>
>
> On Tue, Jun 17, 2014 at 7:17 PM, Bruno Oliveira <bruno at abstractj.org>
> wrote:
>
>> Hi Matthias, answer inline.
>>
>> On 2014-06-17, Matthias Wessendorf wrote:
>> > On Tue, Jun 17, 2014 at 4:26 PM, Bruno Oliveira <bruno at abstractj.org>
>> wrote:
>> >
>> > > Good morning peeps,
>> > >
>> > > I have a problem to solve which might affect the Sender and
>> > > all the related clients.
>> > >
>> > > Previously, the UPS Sender was protected by the basic authentication
>> > > method[1], so anyone in possession of _PushApplicationID_ and
>> > > _MasterSecret_ is able to send push messages.
>> > >
>> > > After the integration with Keycloak now everything under _/rest_
>> > > is properly protect by KC which is totally correct. Our sender is
>> under
>> > > the same umbrella which means that now Bearer token authentication is
>> > > required[2] and Basic authentication won't exist anymore.
>> > >
>> >
>> >
>> > The device (un)registration endpoints are hit by this as well
>> > (/rest/registry/device/*).
>>
>> Currently Keycloak is protecting our endpoints under /rest/*
>>
>> >
>> > I am wondering if it isn't it possible to keep those URLs protected via
>> > HTTP_BASIC, or does the keycloak.js usage deny this?
>>
>> Is not the Keycloak.js usage responsible for this, but the correct
>> configuration of the application atm. Please compare:
>>
>> - master branch:
>>
>> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/server/src/main/webapp/WEB-INF/web.xml#L56
>> - keycloak.js branch:
>>
>> https://github.com/aerogear/aerogear-unifiedpush-server/blob/keycloak.js/server/src/main/webapp/WEB-INF/web.xml#L33
>>
>> Now we're fully using Keycloak bearer tokens instead of Basic.
>>
>
>
> Oh, I was following Bill's sample project, where he did not use the
> 'KEYCLOAK' auth-method:
>
> https://github.com/keycloak/keycloak/blob/master/project-integrations/aerogear-ups/app/src/main/webapp/WEB-INF/web.xml#L44
>
> But we had the exclusion working w/ the KEYCLOAK 'auth-method', but this
> goes back to our initial starts in Dec/Jan.
> Here is a rebased commit based on your initial commit:
>
> https://github.com/aerogear/aerogear-unifiedpush-server/blob/2aabd073aaaafa79943ea41d2651f6f0c5e4248e/server/src/main/webapp/WEB-INF/web.xml#L42-L53
>
>
>>
>> >
>> > On master (plain keycloak; before keycloak.js usage) we are doing an
>> > exclude for those URLs:
>> >
>> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/server/src/main/webapp/WEB-INF/web.xml#L46-L52
>>
>> I tried to include your exclusions, but that didn't work for me.
>>
>> >
>> >
>> > IMO if possible, keeping these 'exceptions' (or excludes) under
>> HTTP_BASIC
>> > would be the simplest solution, as that means none of our client SDKs
>> > (Android, iOS, Cordova, Node.js Sender, Java-Sendet etc) would require
>> an
>> > update.
>>
>> I had a chat with Stian and looks like it's possible to support both
>> auth methods in a single app, but that would involve changes on Keycloak.
>> It's just the matter of discuss with KC team.
>>
>
> I don't think we need to enable to <auth-method> settings in our web.xml;
>

I mean: I think there is no need to enable multiple <auth-method> args, as
we had the exclusion already working at some point, using their KEYCLOAK
auth-method



>
> My initial hope was to be able to simply exclude a few URLs from the
> overall Keycloak protection, like the above referenced commit:
>
> https://github.com/aerogear/aerogear-unifiedpush-server/blob/2aabd073aaaafa79943ea41d2651f6f0c5e4248e/server/src/main/webapp/WEB-INF/web.xml#L42-L53
>
> That would be best as that would mean no API change at all, and our
> client-registration and sender SDKs could stay as they are.
>
>
>
>
>>
>> My two cents is the fact that we should use bearer tokens only, instead
>> of mix both auth methods in a single app ? now that we have KC.
>> And discuss the changes into our clients rather sooner than later.
>>
>> But I'm open for whatever you guys think it's the best.
>>
>>
>> >
>> > -Matthias
>> >
>> >
>> >
>> >
>> >
>> > >
>> > > The consequence of this is the basic form being presented when you try
>> > > to send push notifications[3]. The problem didn't occur before,
>> because
>> > > we were just using Basic authentication[4] instead of Bearer tokens.
>> > >
>> > > Possible solutions:
>> > >
>> > > 1- After the removal of Basic authentication, move _PushApplicationID_
>> > > and _MasterSecret to http headers like:
>> > >
>> > > -H "PushApplicationID: XXXXXX" -H "MasterSecret: 42"
>> > >
>> > > IMO it sounds correct and reasonable for me.
>> > >
>> > > 2. Create a role specific for the sender like _push-applications_ and
>> > > dinamically add _PushApplicationID_ and _MasterSecret on Keycloak
>> where:
>> > >
>> > > username: _PushApplicationID_
>> > > password: _MasterSecret_
>> > >
>> > > The implications of this alternative is the fact of have to manage
>> those
>> > > credentials on the server side inclusion/exclusion/login
>> > >
>> > > 3. Implement another authentication provider specifically for the
>> sender
>> > > and Basic authentication[5]
>> > >
>> > > 4. Do nothing. The consequences of this alternative is to implement
>> > > everything already done by Keycloak.js and manage session tokens by
>> hand
>> > > on the admin-ui.
>> > >
>> > > To me the first alternative seems to be more simple, but I really want
>> > > your feedback on it, once it affects the whole project.
>> > >
>> > > [1] -
>> > >
>> > >
>> https://github.com/aerogear/aerogear-unifiedpush-server/blob/6c1a0d3fedea8fb6ba918009fd8e9785779c151f/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/sender/PushNotificationSenderEndpoint.java#L56
>> > >
>> > > [2] -
>> > >
>> https://github.com/abstractj/aerogear-unifiedpush-server/tree/keycloak.js
>> > > [3] -
>> > >
>> > >
>> http://photon.abstractj.org/AeroGear_UnifiedPush_Server_2014-06-17_10-00-09_2014-06-17_10-00-12.jpg
>> > >
>> > > [4] -
>> > >
>> > >
>> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/server/src/main/webapp/WEB-INF/web.xml#L57
>> > >
>> > > [5] -
>> > >
>> https://github.com/keycloak/keycloak/tree/master/examples/providers/authentication-properties
>> > >
>> > > --
>> > >
>> > > abstractj
>> > > _______________________________________________
>> > > aerogear-dev mailing list
>> > > aerogear-dev at lists.jboss.org
>> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> > >
>> >
>> >
>> >
>> > --
>> > Matthias Wessendorf
>> >
>> > blog: http://matthiaswessendorf.wordpress.com/
>> > sessions: http://www.slideshare.net/mwessendorf
>> > twitter: http://twitter.com/mwessendorf
>>
>> > _______________________________________________
>> > aerogear-dev mailing list
>> > aerogear-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>> --
>>
>> abstractj
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>



-- 
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-dev/attachments/20140617/6a1c4ba1/attachment-0001.html 

From bruno at abstractj.org  Tue Jun 17 18:12:25 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Tue, 17 Jun 2014 19:12:25 -0300
Subject: [aerogear-dev] Keycloak integration and UPS Sender
In-Reply-To: <CAAg5f2RJXsQMdYNjtdf+30Kx6=1sVREoBVB_5Cyry328wcX9Cw@mail.gmail.com>
References: <20140617142624.GA23555@abstractj.org>
	<CAAg5f2Ry2KWC1WOp64hoS9udX1OWFFz=ZH0En9qx07gE5vC0Eg@mail.gmail.com>
	<20140617171736.GA32200@abstractj.org>
	<CAAg5f2S1bxQC6k0dLxXAhd7LX8aj0XakUDSX+TLmzUUeqMG36w@mail.gmail.com>
	<CAAg5f2RJXsQMdYNjtdf+30Kx6=1sVREoBVB_5Cyry328wcX9Cw@mail.gmail.com>
Message-ID: <20140617221225.GA37741@abstractj.org>

Answers inline.

On 2014-06-17, Matthias Wessendorf wrote:
> On Tue, Jun 17, 2014 at 8:51 PM, Matthias Wessendorf <matzew at apache.org>
> wrote:
>
> >
> >
> >
> > On Tue, Jun 17, 2014 at 7:17 PM, Bruno Oliveira <bruno at abstractj.org>
> > wrote:
> >
> >> Hi Matthias, answer inline.
> >>
> >> On 2014-06-17, Matthias Wessendorf wrote:
> >> > On Tue, Jun 17, 2014 at 4:26 PM, Bruno Oliveira <bruno at abstractj.org>
> >> wrote:
> >> >
> >> > > Good morning peeps,
> >> > >
> >> > > I have a problem to solve which might affect the Sender and
> >> > > all the related clients.
> >> > >
> >> > > Previously, the UPS Sender was protected by the basic authentication
> >> > > method[1], so anyone in possession of _PushApplicationID_ and
> >> > > _MasterSecret_ is able to send push messages.
> >> > >
> >> > > After the integration with Keycloak now everything under _/rest_
> >> > > is properly protect by KC which is totally correct. Our sender is
> >> under
> >> > > the same umbrella which means that now Bearer token authentication is
> >> > > required[2] and Basic authentication won't exist anymore.
> >> > >
> >> >
> >> >
> >> > The device (un)registration endpoints are hit by this as well
> >> > (/rest/registry/device/*).
> >>
> >> Currently Keycloak is protecting our endpoints under /rest/*
> >>
> >> >
> >> > I am wondering if it isn't it possible to keep those URLs protected via
> >> > HTTP_BASIC, or does the keycloak.js usage deny this?
> >>
> >> Is not the Keycloak.js usage responsible for this, but the correct
> >> configuration of the application atm. Please compare:
> >>
> >> - master branch:
> >>
> >> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/server/src/main/webapp/WEB-INF/web.xml#L56
> >> - keycloak.js branch:
> >>
> >> https://github.com/aerogear/aerogear-unifiedpush-server/blob/keycloak.js/server/src/main/webapp/WEB-INF/web.xml#L33
> >>
> >> Now we're fully using Keycloak bearer tokens instead of Basic.
> >>
> >
> >
> > Oh, I was following Bill's sample project, where he did not use the
> > 'KEYCLOAK' auth-method:
> >
> > https://github.com/keycloak/keycloak/blob/master/project-integrations/aerogear-ups/app/src/main/webapp/WEB-INF/web.xml#L44
> >
> > But we had the exclusion working w/ the KEYCLOAK 'auth-method', but this
> > goes back to our initial starts in Dec/Jan.
> > Here is a rebased commit based on your initial commit:
> >
> > https://github.com/aerogear/aerogear-unifiedpush-server/blob/2aabd073aaaafa79943ea41d2651f6f0c5e4248e/server/src/main/webapp/WEB-INF/web.xml#L42-L53
> >
> >
> >>
> >> >
> >> > On master (plain keycloak; before keycloak.js usage) we are doing an
> >> > exclude for those URLs:
> >> >
> >> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/server/src/main/webapp/WEB-INF/web.xml#L46-L52
> >>
> >> I tried to include your exclusions, but that didn't work for me.
> >>
> >> >
> >> >
> >> > IMO if possible, keeping these 'exceptions' (or excludes) under
> >> HTTP_BASIC
> >> > would be the simplest solution, as that means none of our client SDKs
> >> > (Android, iOS, Cordova, Node.js Sender, Java-Sendet etc) would require
> >> an
> >> > update.
> >>
> >> I had a chat with Stian and looks like it's possible to support both
> >> auth methods in a single app, but that would involve changes on Keycloak.
> >> It's just the matter of discuss with KC team.
> >>
> >
> > I don't think we need to enable to <auth-method> settings in our web.xml;
> >

How do you manage login/logout/current logged in user on Angular.js? Is
possible to do on the server side, but how do you control it on the
client side?

>
> I mean: I think there is no need to enable multiple <auth-method> args, as
> we had the exclusion already working at some point, using their KEYCLOAK
> auth-method

Stian did that inclusion which for me looks correct. An excerpt from KC
documentation:

"To be able to secure WAR apps deployed on JBoss AS 7.1.1, JBoss EAP 6.x,
or Wildfly, you must install and configure the Keycloak Subsystem. You
then have two options to secure your WARs. You can provide a keycloak
config file in your WAR and change the auth-method to KEYCLOAK within
web.xml. Alternatively, you don't have to crack open your WARs at all
and can apply Keycloak via the Keycloak Subsystem configuration in
standalone.xml. Both methods are described in this section."

You can also stick with BASIC, but probably you end with implementations
and customizations that don't take any benefit of Keycloak.js.

Either way I will talk tomorrow with Stian and let's see what we can do.

>
>
>
> >
> > My initial hope was to be able to simply exclude a few URLs from the
> > overall Keycloak protection, like the above referenced commit:
> >
> > https://github.com/aerogear/aerogear-unifiedpush-server/blob/2aabd073aaaafa79943ea41d2651f6f0c5e4248e/server/src/main/webapp/WEB-INF/web.xml#L42-L53
> >
> > That would be best as that would mean no API change at all, and our
> > client-registration and sender SDKs could stay as they are.
> >
> >
> >
> >
> >>
> >> My two cents is the fact that we should use bearer tokens only, instead
> >> of mix both auth methods in a single app ? now that we have KC.
> >> And discuss the changes into our clients rather sooner than later.
> >>
> >> But I'm open for whatever you guys think it's the best.
> >>
> >>
> >> >
> >> > -Matthias
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > >
> >> > > The consequence of this is the basic form being presented when you try
> >> > > to send push notifications[3]. The problem didn't occur before,
> >> because
> >> > > we were just using Basic authentication[4] instead of Bearer tokens.
> >> > >
> >> > > Possible solutions:
> >> > >
> >> > > 1- After the removal of Basic authentication, move _PushApplicationID_
> >> > > and _MasterSecret to http headers like:
> >> > >
> >> > > -H "PushApplicationID: XXXXXX" -H "MasterSecret: 42"
> >> > >
> >> > > IMO it sounds correct and reasonable for me.
> >> > >
> >> > > 2. Create a role specific for the sender like _push-applications_ and
> >> > > dinamically add _PushApplicationID_ and _MasterSecret on Keycloak
> >> where:
> >> > >
> >> > > username: _PushApplicationID_
> >> > > password: _MasterSecret_
> >> > >
> >> > > The implications of this alternative is the fact of have to manage
> >> those
> >> > > credentials on the server side inclusion/exclusion/login
> >> > >
> >> > > 3. Implement another authentication provider specifically for the
> >> sender
> >> > > and Basic authentication[5]
> >> > >
> >> > > 4. Do nothing. The consequences of this alternative is to implement
> >> > > everything already done by Keycloak.js and manage session tokens by
> >> hand
> >> > > on the admin-ui.
> >> > >
> >> > > To me the first alternative seems to be more simple, but I really want
> >> > > your feedback on it, once it affects the whole project.
> >> > >
> >> > > [1] -
> >> > >
> >> > >
> >> https://github.com/aerogear/aerogear-unifiedpush-server/blob/6c1a0d3fedea8fb6ba918009fd8e9785779c151f/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/sender/PushNotificationSenderEndpoint.java#L56
> >> > >
> >> > > [2] -
> >> > >
> >> https://github.com/abstractj/aerogear-unifiedpush-server/tree/keycloak.js
> >> > > [3] -
> >> > >
> >> > >
> >> http://photon.abstractj.org/AeroGear_UnifiedPush_Server_2014-06-17_10-00-09_2014-06-17_10-00-12.jpg
> >> > >
> >> > > [4] -
> >> > >
> >> > >
> >> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/server/src/main/webapp/WEB-INF/web.xml#L57
> >> > >
> >> > > [5] -
> >> > >
> >> https://github.com/keycloak/keycloak/tree/master/examples/providers/authentication-properties
> >> > >
> >> > > --
> >> > >
> >> > > abstractj
> >> > > _______________________________________________
> >> > > aerogear-dev mailing list
> >> > > aerogear-dev at lists.jboss.org
> >> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >> > >
> >> >
> >> >
> >> >
> >> > --
> >> > Matthias Wessendorf
> >> >
> >> > blog: http://matthiaswessendorf.wordpress.com/
> >> > sessions: http://www.slideshare.net/mwessendorf
> >> > twitter: http://twitter.com/mwessendorf
> >>
> >> > _______________________________________________
> >> > aerogear-dev mailing list
> >> > aerogear-dev at lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>
> >>
> >> --
> >>
> >> abstractj
> >> _______________________________________________
> >> aerogear-dev mailing list
> >> aerogear-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>
> >
> >
> >
> > --
> > Matthias Wessendorf
> >
> > blog: http://matthiaswessendorf.wordpress.com/
> > sessions: http://www.slideshare.net/mwessendorf
> > twitter: http://twitter.com/mwessendorf
> >
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf

> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


--

abstractj

From bruno at abstractj.org  Tue Jun 17 18:22:21 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Tue, 17 Jun 2014 19:22:21 -0300
Subject: [aerogear-dev] Keycloak integration and UPS Sender
In-Reply-To: <CAAg5f2TgqmkRKWqyjk6kEuMa9Hvgs_RY_7XXdfxrUDsw3kDNag@mail.gmail.com>
References: <20140617142624.GA23555@abstractj.org>
	<B6A470CC-DE76-4A00-B56B-76434079BDEA@redhat.com>
	<20140617172332.GB32200@abstractj.org>
	<CAAg5f2TgqmkRKWqyjk6kEuMa9Hvgs_RY_7XXdfxrUDsw3kDNag@mail.gmail.com>
Message-ID: <20140617222221.GB37741@abstractj.org>

On 2014-06-17, Matthias Wessendorf wrote:
> Bom Dia!
>
>
> On Tue, Jun 17, 2014 at 7:23 PM, Bruno Oliveira <bruno at abstractj.org> wrote:
>
> > Ahoy Jay, answers inline.
> >
> > On 2014-06-17, Jay Balunas wrote:
> > > Great explanation of the issue and options!
> > >
> > > On Jun 17, 2014, at 10:26 AM, Bruno Oliveira <bruno at abstractj.org>
> > wrote:
> > >
> > > > Good morning peeps,
> > > >
> > > > I have a problem to solve which might affect the Sender and
> > > > all the related clients.
> > > >
> > > > Previously, the UPS Sender was protected by the basic authentication
> > > > method[1], so anyone in possession of _PushApplicationID_ and
> > > > _MasterSecret_ is able to send push messages.
> > > >
> > > > After the integration with Keycloak now everything under _/rest_
> > > > is properly protect by KC which is totally correct. Our sender is under
> > > > the same umbrella which means that now Bearer token authentication is
> > > > required[2] and Basic authentication won't exist anymore.
> > > >
> > > > The consequence of this is the basic form being presented when you try
> > > > to send push notifications[3]. The problem didn't occur before, because
> > > > we were just using Basic authentication[4] instead of Bearer tokens.
> > > >
> > > > Possible solutions:
> > > >
> > > > 1- After the removal of Basic authentication, move _PushApplicationID_
> > > > and _MasterSecret to http headers like:
> > > >
> > > > -H "PushApplicationID: XXXXXX" -H "MasterSecret: 42"
> > > >
> > > > IMO it sounds correct and reasonable for me.
> > >
> > > How will this impact CURL usage from the command line?
> > > How will this impact Java sender usage?
> >
> > We would change from (being logged in would be required):
> >
> > curl -3 -u "{PushApplicationID}:{MasterSecret}"
> >    -v -H "Accept: application/json" -H "Content-type: application/json"
> >       -X POST
> >
> > To:
> >
> > curl -3
> >    -v -H "PushApplicationID: XXXXXX" -H "MasterSecret: 42" \
> >       -H "Accept: application/json" -H "Content-type: application/json"
> >       -X POST
> >
> >
>
>
> That sounds like the most safe change to our client-registration and sender
> SDKs. Basically a 'minor' change where we issue the HTTP request.
>
> I'd vote for this change, but only if it is not possible to exclude a few
> URLs from Keycloak ;-)

Thanks Matthias, we will try to find a consensus on it.

>
> Note, that those excluded endpoints (for device-registration and sender)
> don't require any <auth-method> setting in web.xml,
> as they implement their own simple HTTP_BASIC handling by querying our
> database ;-)
> https://github.com/abstractj/aerogear-unifiedpush-server/blob/keycloak.js/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/sender/PushNotificationSenderEndpoint.java#L55-L61

If you look at KC examples[1], most of them properly make use of
auth-method. IMO it's necessary if we want to benefit of bearer tokens
on the admin-ui (I can be wrong on my understanding).


>
>
>
> But, yeah - if the exclusion is not possible at all, I like your suggested
> header usage fix. IMO that's the one with the fewest risks.
>
>
> -Matthias
>
>
>
>
> > >
> > > >
> > > > 2. Create a role specific for the sender like _push-applications_ and
> > > > dinamically add _PushApplicationID_ and _MasterSecret on Keycloak
> > where:
> > > >
> > > > username: _PushApplicationID_
> > > > password: _MasterSecret_
> > > >
> > > > The implications of this alternative is the fact of have to manage
> > those
> > > > credentials on the server side inclusion/exclusion/login
> > >
> > > Would each application have its own "role" just for the sender in this
> > case?
> >
> > Each application would have the same role "ups-application".
> >
> > >
> > > >
> > > > 3. Implement another authentication provider specifically for the
> > sender
> > > > and Basic authentication[5]
> > >
> > > Not sure of the impact here, but sounds like a complex solution.
> >
> > Yes, totally agree on that.
> >
> > >
> > > >
> > > > 4. Do nothing. The consequences of this alternative is to implement
> > > > everything already done by Keycloak.js and manage session tokens by
> > hand
> > > > on the admin-ui.
> > >
> > > -1
> >
> > Stian sent to me a message, he might have more ideas about how to
> > overcome this issue. I will update you guys during this week.
> >
> > >
> > > >
> > > > To me the first alternative seems to be more simple, but I really want
> > > > your feedback on it, once it affects the whole project.
> > > >
> > > > [1] -
> > > >
> > https://github.com/aerogear/aerogear-unifiedpush-server/blob/6c1a0d3fedea8fb6ba918009fd8e9785779c151f/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/sender/PushNotificationSenderEndpoint.java#L56
> > > >
> > > > [2] -
> > > >
> > https://github.com/abstractj/aerogear-unifiedpush-server/tree/keycloak.js
> > > > [3] -
> > > >
> > http://photon.abstractj.org/AeroGear_UnifiedPush_Server_2014-06-17_10-00-09_2014-06-17_10-00-12.jpg
> > > >
> > > > [4] -
> > > >
> > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/server/src/main/webapp/WEB-INF/web.xml#L57
> > > >
> > > > [5] -
> > https://github.com/keycloak/keycloak/tree/master/examples/providers/authentication-properties
> > > >
> > > > --
> > > >
> > > > abstractj
> > > > _______________________________________________
> > > > aerogear-dev mailing list
> > > > aerogear-dev at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > >
> > >
> > > _______________________________________________
> > > aerogear-dev mailing list
> > > aerogear-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> > --
> >
> > abstractj
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf

> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


--

abstractj

From bruno at abstractj.org  Tue Jun 17 18:31:52 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Tue, 17 Jun 2014 19:31:52 -0300
Subject: [aerogear-dev] Current status of UPS 0.11.0
In-Reply-To: <20140617174235.7ebc5d09@kapy-ntb-x220>
References: <20140616220648.GA6896@abstractj.org>
	<20140617174235.7ebc5d09@kapy-ntb-x220>
Message-ID: <20140617223152.GC37741@abstractj.org>

I'm totally aware of it and that's the reason why I'm trying to
communicate at each change.

The branch keycloak.js won't be merged until we stabilize it. The reason
to come to the mailing list and give a heads up is to share a problem to
be solved instead of keep it to myself.

Thanks

On 2014-06-17, Karel Piwko wrote:
> We definitely need a way how get bearer token from auth server without a form
> popping out if we are going to remove HTTP Basic. UPS is supposed to be used
> also by other applications using REST endpoints apart from Admin UI. E.g. you
> want to show all iOS installations on variant FooBar in your own dashboard
> application.
>
> Sender is the same case, your application might want to send a message via UPS.
> It might be using either JavaSender or direct REST calls. Ability to authorize
> your app non-interactively is crucial here.
>
> Karel
>
> On Mon, 16 Jun 2014 19:06:48 -0300
> Bruno Oliveira <bruno at abstractj.org> wrote:
>
> > Good morning peeps,
> >
> > First I would like to thank Bill Burke, Stian, Sebastien and Lukas for
> > dedicating their time helping with Keycloak integration.
> >
> > I think we are almost done, this is the current branch:
> > https://github.com/abstractj/aerogear-unifiedpush-server/tree/keycloak.js.
> > And now most of issues were gone and is also possible to display the current
> > logged in user.
> >
> > Now I'm working on fix the sender endpoint, to be more precise we need
> > to remove the HTTP basic authentication for sending push messages
> > now that most of the endpoints are protect by Keycloak. If you try to
> > send a push message based on my branch you will see the basic
> > authentication form atm.
> >
> > If you have a better idea, I'm all ears.
> >
> > --
> >
> > abstractj
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev

--

abstractj

From scm.blanc at gmail.com  Tue Jun 17 18:32:59 2014
From: scm.blanc at gmail.com (Sebastien Blanc)
Date: Wed, 18 Jun 2014 00:32:59 +0200
Subject: [aerogear-dev] Keycloak integration and UPS Sender
In-Reply-To: <20140617222221.GB37741@abstractj.org>
References: <20140617142624.GA23555@abstractj.org>
	<B6A470CC-DE76-4A00-B56B-76434079BDEA@redhat.com>
	<20140617172332.GB32200@abstractj.org>
	<CAAg5f2TgqmkRKWqyjk6kEuMa9Hvgs_RY_7XXdfxrUDsw3kDNag@mail.gmail.com>
	<20140617222221.GB37741@abstractj.org>
Message-ID: <CAD_dpu3Si+EVzMsbdt+hSJ9pQ7P035TXp20ZgHZ+v0EBfaMX_Q@mail.gmail.com>

On Wed, Jun 18, 2014 at 12:22 AM, Bruno Oliveira <bruno at abstractj.org>
wrote:

> On 2014-06-17, Matthias Wessendorf wrote:
> > Bom Dia!
> >
> >
> > On Tue, Jun 17, 2014 at 7:23 PM, Bruno Oliveira <bruno at abstractj.org>
> wrote:
> >
> > > Ahoy Jay, answers inline.
> > >
> > > On 2014-06-17, Jay Balunas wrote:
> > > > Great explanation of the issue and options!
> > > >
> > > > On Jun 17, 2014, at 10:26 AM, Bruno Oliveira <bruno at abstractj.org>
> > > wrote:
> > > >
> > > > > Good morning peeps,
> > > > >
> > > > > I have a problem to solve which might affect the Sender and
> > > > > all the related clients.
> > > > >
> > > > > Previously, the UPS Sender was protected by the basic
> authentication
> > > > > method[1], so anyone in possession of _PushApplicationID_ and
> > > > > _MasterSecret_ is able to send push messages.
> > > > >
> > > > > After the integration with Keycloak now everything under _/rest_
> > > > > is properly protect by KC which is totally correct. Our sender is
> under
> > > > > the same umbrella which means that now Bearer token authentication
> is
> > > > > required[2] and Basic authentication won't exist anymore.
> > > > >
> > > > > The consequence of this is the basic form being presented when you
> try
> > > > > to send push notifications[3]. The problem didn't occur before,
> because
> > > > > we were just using Basic authentication[4] instead of Bearer
> tokens.
> > > > >
> > > > > Possible solutions:
> > > > >
> > > > > 1- After the removal of Basic authentication, move
> _PushApplicationID_
> > > > > and _MasterSecret to http headers like:
> > > > >
> > > > > -H "PushApplicationID: XXXXXX" -H "MasterSecret: 42"
> > > > >
> > > > > IMO it sounds correct and reasonable for me.
> > > >
> > > > How will this impact CURL usage from the command line?
> > > > How will this impact Java sender usage?
> > >
> > > We would change from (being logged in would be required):
> > >
> > > curl -3 -u "{PushApplicationID}:{MasterSecret}"
> > >    -v -H "Accept: application/json" -H "Content-type: application/json"
> > >       -X POST
> > >
> > > To:
> > >
> > > curl -3
> > >    -v -H "PushApplicationID: XXXXXX" -H "MasterSecret: 42" \
> > >       -H "Accept: application/json" -H "Content-type: application/json"
> > >       -X POST
> > >
> > >
> >
> >
> > That sounds like the most safe change to our client-registration and
> sender
> > SDKs. Basically a 'minor' change where we issue the HTTP request.
> >
> > I'd vote for this change, but only if it is not possible to exclude a few
> > URLs from Keycloak ;-)
>
> Thanks Matthias, we will try to find a consensus on it.
>

+ 9001 , let's be pragmatic and join brains :)

One question, Are you worried especially about accessing the send endpoint
through the Admin client (through "Send notififcation")  ? Because for that
we could do some kind of facade protected (implicitly) by KC and later we
could fully protect the endpoint  => this way for 0.11, the admin console
is secured , we don't change the Sender API for now but we can do that for
0.12 .
wdyt ?
Otherwise let's go for solution 1.

>
> >
> > Note, that those excluded endpoints (for device-registration and sender)
> > don't require any <auth-method> setting in web.xml,
> > as they implement their own simple HTTP_BASIC handling by querying our
> > database ;-)
> >
> https://github.com/abstractj/aerogear-unifiedpush-server/blob/keycloak.js/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/sender/PushNotificationSenderEndpoint.java#L55-L61
>
> If you look at KC examples[1], most of them properly make use of
> auth-method. IMO it's necessary if we want to benefit of bearer tokens
> on the admin-ui (I can be wrong on my understanding).
>
>
> >
> >
> >
> > But, yeah - if the exclusion is not possible at all, I like your
> suggested
> > header usage fix. IMO that's the one with the fewest risks.
> >
> >
> > -Matthias
> >
> >
> >
> >
> > > >
> > > > >
> > > > > 2. Create a role specific for the sender like _push-applications_
> and
> > > > > dinamically add _PushApplicationID_ and _MasterSecret on Keycloak
> > > where:
> > > > >
> > > > > username: _PushApplicationID_
> > > > > password: _MasterSecret_
> > > > >
> > > > > The implications of this alternative is the fact of have to manage
> > > those
> > > > > credentials on the server side inclusion/exclusion/login
> > > >
> > > > Would each application have its own "role" just for the sender in
> this
> > > case?
> > >
> > > Each application would have the same role "ups-application".
> > >
> > > >
> > > > >
> > > > > 3. Implement another authentication provider specifically for the
> > > sender
> > > > > and Basic authentication[5]
> > > >
> > > > Not sure of the impact here, but sounds like a complex solution.
> > >
> > > Yes, totally agree on that.
> > >
> > > >
> > > > >
> > > > > 4. Do nothing. The consequences of this alternative is to implement
> > > > > everything already done by Keycloak.js and manage session tokens by
> > > hand
> > > > > on the admin-ui.
> > > >
> > > > -1
> > >
> > > Stian sent to me a message, he might have more ideas about how to
> > > overcome this issue. I will update you guys during this week.
> > >
> > > >
> > > > >
> > > > > To me the first alternative seems to be more simple, but I really
> want
> > > > > your feedback on it, once it affects the whole project.
> > > > >
> > > > > [1] -
> > > > >
> > >
> https://github.com/aerogear/aerogear-unifiedpush-server/blob/6c1a0d3fedea8fb6ba918009fd8e9785779c151f/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/sender/PushNotificationSenderEndpoint.java#L56
> > > > >
> > > > > [2] -
> > > > >
> > >
> https://github.com/abstractj/aerogear-unifiedpush-server/tree/keycloak.js
> > > > > [3] -
> > > > >
> > >
> http://photon.abstractj.org/AeroGear_UnifiedPush_Server_2014-06-17_10-00-09_2014-06-17_10-00-12.jpg
> > > > >
> > > > > [4] -
> > > > >
> > >
> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/server/src/main/webapp/WEB-INF/web.xml#L57
> > > > >
> > > > > [5] -
> > >
> https://github.com/keycloak/keycloak/tree/master/examples/providers/authentication-properties
> > > > >
> > > > > --
> > > > >
> > > > > abstractj
> > > > > _______________________________________________
> > > > > aerogear-dev mailing list
> > > > > aerogear-dev at lists.jboss.org
> > > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > >
> > > >
> > > > _______________________________________________
> > > > aerogear-dev mailing list
> > > > aerogear-dev at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > >
> > > --
> > >
> > > abstractj
> > > _______________________________________________
> > > aerogear-dev mailing list
> > > aerogear-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > >
> >
> >
> >
> > --
> > Matthias Wessendorf
> >
> > blog: http://matthiaswessendorf.wordpress.com/
> > sessions: http://www.slideshare.net/mwessendorf
> > twitter: http://twitter.com/mwessendorf
>
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> --
>
> abstractj
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140618/3851e4f7/attachment-0001.html 

From bruno at abstractj.org  Tue Jun 17 18:34:21 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Tue, 17 Jun 2014 19:34:21 -0300
Subject: [aerogear-dev] Current status of UPS 0.11.0
In-Reply-To: <CAEroY3583CMWT_W8oxh-SWM1h5pDf8hV1WR57rvnT+_Z3+2+jQ@mail.gmail.com>
References: <20140616220648.GA6896@abstractj.org>
	<CAAg5f2RuLkX1ijJdS56kZv6PV3_UAvfJD8u4+4YwnN_O2bVurw@mail.gmail.com>
	<CAEroY34JPtOf=O0fOccwVKDUQbEWjjvxZC=A9hnewLB0EjCzmA@mail.gmail.com>
	<CAEroY3583CMWT_W8oxh-SWM1h5pDf8hV1WR57rvnT+_Z3+2+jQ@mail.gmail.com>
Message-ID: <20140617223421.GD37741@abstractj.org>

On 2014-06-17, Luk?? Fry? wrote:
> Btw,
>
> are we ready to merge keycloak.js branch into master and continue work
> there?

Thanks for helping on it Luk??. I would like to stabilize that branch
before and make sure that everything is working fine, but if you guys
feel like it should be merged, that's ok.

>
>
> On Tue, Jun 17, 2014 at 12:00 PM, Luk?? Fry? <lukas.fryc at gmail.com> wrote:
>
> > Hey guys,
> >
> > I've did some stabilizations inside the Bruno's keycloak.js branch and
> > then rebased it against master.
> >
> > I've also shared this branch on aerogear/aerogear-unified-push-server
> > repo, so we could all work on it:
> >
> > https://github.com/aerogear/aerogear-unifiedpush-server/tree/keycloak.js
> >
> >
> > Dan, I believe this branch should fix issues you were seeing.
> >
> > ~ Lukas
> >
> >
> > On Tue, Jun 17, 2014 at 8:59 AM, Matthias Wessendorf <matzew at apache.org>
> > wrote:
> >
> >> Bom Dia!
> >>
> >>
> >> On Tue, Jun 17, 2014 at 12:06 AM, Bruno Oliveira <bruno at abstractj.org>
> >> wrote:
> >>
> >>> Good morning peeps,
> >>>
> >>> First I would like to thank Bill Burke, Stian, Sebastien and Lukas for
> >>> dedicating
> >>> their time helping with Keycloak integration.
> >>>
> >>
> >> Great to hear! :-)
> >>
> >>
> >>>
> >>> I think we are almost done, this is the current branch:
> >>> https://github.com/abstractj/aerogear-unifiedpush-server/tree/keycloak.js.
> >>> And now most
> >>> of issues were gone and is also possible to display the current logged
> >>> in user.
> >>>
> >>> Now I'm working on fix the sender endpoint, to be more precise we need
> >>> to remove the HTTP basic authentication for sending push messages
> >>> now that most of the endpoints are protect by Keycloak.
> >>
> >>
> >> Is the reason here that the 'sending endpoint' is also accessed from the
> >> AdminUI, for the 'compose a push' feature?
> >>
> >> If it's really required I am OK with that. However, I'd prefer to avoid
> >> it, as changing the behaviour of one of our two HTTP_BASIC endpoints
> >> ('device registration' and 'sending') also requires changes/updates on the
> >> relevant client SDKs.
> >>
> >> Greetings,
> >> Matthias
> >>
> >>
> >>
> >>
> >>> If you try to
> >>> send a push message based on my branch you will see the basic
> >>> authentication form atm.
> >>>
> >>> If you have a better idea, I'm all ears.
> >>>
> >>> --
> >>>
> >>> abstractj
> >>> _______________________________________________
> >>> aerogear-dev mailing list
> >>> aerogear-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>>
> >>
> >>
> >>
> >> --
> >> Matthias Wessendorf
> >>
> >> blog: http://matthiaswessendorf.wordpress.com/
> >> sessions: http://www.slideshare.net/mwessendorf
> >> twitter: http://twitter.com/mwessendorf
> >>
> >> _______________________________________________
> >> aerogear-dev mailing list
> >> aerogear-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>
> >
> >

> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


--

abstractj

From bruno at abstractj.org  Tue Jun 17 18:35:17 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Tue, 17 Jun 2014 19:35:17 -0300
Subject: [aerogear-dev] Current status of UPS 0.11.0
In-Reply-To: <CAFJm-3GTyHOSL5x=XT=iNUJGJghOieWLQoh7p=uSPLQHqgo77A@mail.gmail.com>
References: <20140616220648.GA6896@abstractj.org>
	<CAFJm-3GTyHOSL5x=XT=iNUJGJghOieWLQoh7p=uSPLQHqgo77A@mail.gmail.com>
Message-ID: <20140617223517.GE37741@abstractj.org>

Ping me on IRC tomorrow and we can take a look together.

On 2014-06-17, Daniel Bevenius wrote:
> Hey Bruno,
>
> I wanted to take a look at this issue but I'm probably missing something
> obvious here:(
> I'm using your 'keycloak.js' branch and have updated and builtt keycloak
> locally, then built aerogear-unified-push-server and first deployed
> auth-server.war and then ag-push.war.
>
> When I then access UPS's admin console using http://localhost:8080/ag-push
> I the page looks like the screenshot I've attached,  I'm not seeing any
> error in the server console or the browser console, and I'm not able to
> really do anything on this page, like click on the user for example.
> Let me know if there is some step that I've forgotten.
>
> Thanks,
>
> /Dan
>
>
>
>
> On 17 June 2014 00:06, Bruno Oliveira <bruno at abstractj.org> wrote:
>
> > Good morning peeps,
> >
> > First I would like to thank Bill Burke, Stian, Sebastien and Lukas for
> > dedicating
> > their time helping with Keycloak integration.
> >
> > I think we are almost done, this is the current branch:
> > https://github.com/abstractj/aerogear-unifiedpush-server/tree/keycloak.js.
> > And now most
> > of issues were gone and is also possible to display the current logged
> > in user.
> >
> > Now I'm working on fix the sender endpoint, to be more precise we need
> > to remove the HTTP basic authentication for sending push messages
> > now that most of the endpoints are protect by Keycloak. If you try to
> > send a push message based on my branch you will see the basic
> > authentication form atm.
> >
> > If you have a better idea, I'm all ears.
> >
> > --
> >
> > abstractj
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >


> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


--

abstractj

From bruno at abstractj.org  Wed Jun 18 00:38:21 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Wed, 18 Jun 2014 01:38:21 -0300
Subject: [aerogear-dev] UPS console: server error response handling on
 client-side
In-Reply-To: <CAEroY37JM9JY3_L=J=B6wnO=J2=9qNoqVoS6xRUMfHA5UsyV9g@mail.gmail.com>
References: <CAEroY37JM9JY3_L=J=B6wnO=J2=9qNoqVoS6xRUMfHA5UsyV9g@mail.gmail.com>
Message-ID: <20140618043821.GA50729@abstractj.org>

Sorry for the late response Lukas.

On 2014-06-16, Luk?? Fry? wrote:
> Hey guys,
>
> I was looking into AGPUSH-720 and I got an perception that not all error
> response do we actually know on the client-side.
>
> We should establish a common pattern - contract between server and client -
> which says how is a failure message transported from server to client, e.g.:
>
> - response header
> - response message body /w given structure

Speaking about a contract between client/server what would you suggest?
Maybe we can start a gist for these definitions once it affects other
clients?

>
>
> Right now, I've opened a PR for a generic failure handling mechanism that
> can catch and report any error:
> https://github.com/aerogear/aerogear-unifiedpush-server/pull/226/files

I've already commented on that, overall looks good.

>
> I plan to extend this error handling code dynamically as needed based on
> response codes (e.g. 404=Request resource is missing) and contract
> mentioned above ^.
>
> Wdyt?
>
>
> ~ Lukas

> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


--

abstractj

From matzew at apache.org  Wed Jun 18 01:04:12 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Wed, 18 Jun 2014 07:04:12 +0200
Subject: [aerogear-dev] Keycloak integration and UPS Sender
In-Reply-To: <20140617221225.GA37741@abstractj.org>
References: <20140617142624.GA23555@abstractj.org>
	<CAAg5f2Ry2KWC1WOp64hoS9udX1OWFFz=ZH0En9qx07gE5vC0Eg@mail.gmail.com>
	<20140617171736.GA32200@abstractj.org>
	<CAAg5f2S1bxQC6k0dLxXAhd7LX8aj0XakUDSX+TLmzUUeqMG36w@mail.gmail.com>
	<CAAg5f2RJXsQMdYNjtdf+30Kx6=1sVREoBVB_5Cyry328wcX9Cw@mail.gmail.com>
	<20140617221225.GA37741@abstractj.org>
Message-ID: <CAAg5f2SzOp+cik4iuZPxOo-7ABOAnCk_VCLzEQSKWU7bs=gdSg@mail.gmail.com>

On Wed, Jun 18, 2014 at 12:12 AM, Bruno Oliveira <bruno at abstractj.org>
wrote:

> Answers inline.
>
> On 2014-06-17, Matthias Wessendorf wrote:
> > On Tue, Jun 17, 2014 at 8:51 PM, Matthias Wessendorf <matzew at apache.org>
> > wrote:
> >
> > >
> > >
> > >
> > > On Tue, Jun 17, 2014 at 7:17 PM, Bruno Oliveira <bruno at abstractj.org>
> > > wrote:
> > >
> > >> Hi Matthias, answer inline.
> > >>
> > >> On 2014-06-17, Matthias Wessendorf wrote:
> > >> > On Tue, Jun 17, 2014 at 4:26 PM, Bruno Oliveira <
> bruno at abstractj.org>
> > >> wrote:
> > >> >
> > >> > > Good morning peeps,
> > >> > >
> > >> > > I have a problem to solve which might affect the Sender and
> > >> > > all the related clients.
> > >> > >
> > >> > > Previously, the UPS Sender was protected by the basic
> authentication
> > >> > > method[1], so anyone in possession of _PushApplicationID_ and
> > >> > > _MasterSecret_ is able to send push messages.
> > >> > >
> > >> > > After the integration with Keycloak now everything under _/rest_
> > >> > > is properly protect by KC which is totally correct. Our sender is
> > >> under
> > >> > > the same umbrella which means that now Bearer token
> authentication is
> > >> > > required[2] and Basic authentication won't exist anymore.
> > >> > >
> > >> >
> > >> >
> > >> > The device (un)registration endpoints are hit by this as well
> > >> > (/rest/registry/device/*).
> > >>
> > >> Currently Keycloak is protecting our endpoints under /rest/*
> > >>
> > >> >
> > >> > I am wondering if it isn't it possible to keep those URLs protected
> via
> > >> > HTTP_BASIC, or does the keycloak.js usage deny this?
> > >>
> > >> Is not the Keycloak.js usage responsible for this, but the correct
> > >> configuration of the application atm. Please compare:
> > >>
> > >> - master branch:
> > >>
> > >>
> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/server/src/main/webapp/WEB-INF/web.xml#L56
> > >> - keycloak.js branch:
> > >>
> > >>
> https://github.com/aerogear/aerogear-unifiedpush-server/blob/keycloak.js/server/src/main/webapp/WEB-INF/web.xml#L33
> > >>
> > >> Now we're fully using Keycloak bearer tokens instead of Basic.
> > >>
> > >
> > >
> > > Oh, I was following Bill's sample project, where he did not use the
> > > 'KEYCLOAK' auth-method:
> > >
> > >
> https://github.com/keycloak/keycloak/blob/master/project-integrations/aerogear-ups/app/src/main/webapp/WEB-INF/web.xml#L44
> > >
> > > But we had the exclusion working w/ the KEYCLOAK 'auth-method', but
> this
> > > goes back to our initial starts in Dec/Jan.
> > > Here is a rebased commit based on your initial commit:
> > >
> > >
> https://github.com/aerogear/aerogear-unifiedpush-server/blob/2aabd073aaaafa79943ea41d2651f6f0c5e4248e/server/src/main/webapp/WEB-INF/web.xml#L42-L53
> > >
> > >
> > >>
> > >> >
> > >> > On master (plain keycloak; before keycloak.js usage) we are doing an
> > >> > exclude for those URLs:
> > >> >
> > >>
> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/server/src/main/webapp/WEB-INF/web.xml#L46-L52
> > >>
> > >> I tried to include your exclusions, but that didn't work for me.
> > >>
> > >> >
> > >> >
> > >> > IMO if possible, keeping these 'exceptions' (or excludes) under
> > >> HTTP_BASIC
> > >> > would be the simplest solution, as that means none of our client
> SDKs
> > >> > (Android, iOS, Cordova, Node.js Sender, Java-Sendet etc) would
> require
> > >> an
> > >> > update.
> > >>
> > >> I had a chat with Stian and looks like it's possible to support both
> > >> auth methods in a single app, but that would involve changes on
> Keycloak.
> > >> It's just the matter of discuss with KC team.
> > >>
> > >
> > > I don't think we need to enable to <auth-method> settings in our
> web.xml;
> > >
>
> How do you manage login/logout/current logged in user on Angular.js? Is
> possible to do on the server side, but how do you control it on the
> client side?
>

Sure, to protect the admin-ui and most of the /rest/* endpoints we need the
one <auth-method>KEYCLOAK</auth-method>. No question there. I was trying to
say we do not need multiple 'auth-method' elements on web.xml

But I think it should be possible to exclude a few URLs, like '/rest/foo'
and '/rest/bar', so that they are completely unprotected in terms of
Keycloak (e.g. via different security-constraint elements):
https://github.com/aerogear/aerogear-unifiedpush-server/blob/2aabd073aaaafa79943ea41d2651f6f0c5e4248e/server/src/main/webapp/WEB-INF/web.xml

In terms of "current logged in user on Angular.js":
* For the "/rest/sender" and "/rest/device/registration" endpoints, I don't
see a relationship to the user on Angular.js/AdminUI at all.

Internally these 'unprotected' (or excluded) endpoints implement the
HTTP_BASIC scheme themselves:
* They treat the Application/Variant like a 'user', by performing a DB
lookup of the give application/variantID
* If that (Application or Variant) is found, the endpoints compare the
given 'password' form the request w/ the "secret" on the  Application or
Variant

But for these endpoints (sender and device-registration) there is no real
user here like "Mr. Jay" or "Push-Admin Foo".

The client (registration or sender SDK) performs the auth, by applying the
ID and the secret:
curl -3 -u "{PushApplicationID}:{MasterSecret}" .... https://server



>
> >
> > I mean: I think there is no need to enable multiple <auth-method> args,
> as
> > we had the exclusion already working at some point, using their KEYCLOAK
> > auth-method
>
> Stian did that inclusion which for me looks correct. An excerpt from KC
> documentation:
>
> "To be able to secure WAR apps deployed on JBoss AS 7.1.1, JBoss EAP 6.x,
> or Wildfly, you must install and configure the Keycloak Subsystem. You
> then have two options to secure your WARs. You can provide a keycloak
> config file in your WAR and change the auth-method to KEYCLOAK within
> web.xml. Alternatively, you don't have to crack open your WARs at all
> and can apply Keycloak via the Keycloak Subsystem configuration in
> standalone.xml. Both methods are described in this section."
>
> You can also stick with BASIC, but probably you end with implementations
> and customizations that don't take any benefit of Keycloak.js.
>
> Either way I will talk tomorrow with Stian and let's see what we can do.
>
> >
> >
> >
> > >
> > > My initial hope was to be able to simply exclude a few URLs from the
> > > overall Keycloak protection, like the above referenced commit:
> > >
> > >
> https://github.com/aerogear/aerogear-unifiedpush-server/blob/2aabd073aaaafa79943ea41d2651f6f0c5e4248e/server/src/main/webapp/WEB-INF/web.xml#L42-L53
> > >
> > > That would be best as that would mean no API change at all, and our
> > > client-registration and sender SDKs could stay as they are.
> > >
> > >
> > >
> > >
> > >>
> > >> My two cents is the fact that we should use bearer tokens only,
> instead
> > >> of mix both auth methods in a single app ? now that we have KC.
> > >> And discuss the changes into our clients rather sooner than later.
> > >>
> > >> But I'm open for whatever you guys think it's the best.
> > >>
> > >>
> > >> >
> > >> > -Matthias
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > >
> > >> > > The consequence of this is the basic form being presented when
> you try
> > >> > > to send push notifications[3]. The problem didn't occur before,
> > >> because
> > >> > > we were just using Basic authentication[4] instead of Bearer
> tokens.
> > >> > >
> > >> > > Possible solutions:
> > >> > >
> > >> > > 1- After the removal of Basic authentication, move
> _PushApplicationID_
> > >> > > and _MasterSecret to http headers like:
> > >> > >
> > >> > > -H "PushApplicationID: XXXXXX" -H "MasterSecret: 42"
> > >> > >
> > >> > > IMO it sounds correct and reasonable for me.
> > >> > >
> > >> > > 2. Create a role specific for the sender like _push-applications_
> and
> > >> > > dinamically add _PushApplicationID_ and _MasterSecret on Keycloak
> > >> where:
> > >> > >
> > >> > > username: _PushApplicationID_
> > >> > > password: _MasterSecret_
> > >> > >
> > >> > > The implications of this alternative is the fact of have to manage
> > >> those
> > >> > > credentials on the server side inclusion/exclusion/login
> > >> > >
> > >> > > 3. Implement another authentication provider specifically for the
> > >> sender
> > >> > > and Basic authentication[5]
> > >> > >
> > >> > > 4. Do nothing. The consequences of this alternative is to
> implement
> > >> > > everything already done by Keycloak.js and manage session tokens
> by
> > >> hand
> > >> > > on the admin-ui.
> > >> > >
> > >> > > To me the first alternative seems to be more simple, but I really
> want
> > >> > > your feedback on it, once it affects the whole project.
> > >> > >
> > >> > > [1] -
> > >> > >
> > >> > >
> > >>
> https://github.com/aerogear/aerogear-unifiedpush-server/blob/6c1a0d3fedea8fb6ba918009fd8e9785779c151f/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/sender/PushNotificationSenderEndpoint.java#L56
> > >> > >
> > >> > > [2] -
> > >> > >
> > >>
> https://github.com/abstractj/aerogear-unifiedpush-server/tree/keycloak.js
> > >> > > [3] -
> > >> > >
> > >> > >
> > >>
> http://photon.abstractj.org/AeroGear_UnifiedPush_Server_2014-06-17_10-00-09_2014-06-17_10-00-12.jpg
> > >> > >
> > >> > > [4] -
> > >> > >
> > >> > >
> > >>
> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/server/src/main/webapp/WEB-INF/web.xml#L57
> > >> > >
> > >> > > [5] -
> > >> > >
> > >>
> https://github.com/keycloak/keycloak/tree/master/examples/providers/authentication-properties
> > >> > >
> > >> > > --
> > >> > >
> > >> > > abstractj
> > >> > > _______________________________________________
> > >> > > aerogear-dev mailing list
> > >> > > aerogear-dev at lists.jboss.org
> > >> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > >> > >
> > >> >
> > >> >
> > >> >
> > >> > --
> > >> > Matthias Wessendorf
> > >> >
> > >> > blog: http://matthiaswessendorf.wordpress.com/
> > >> > sessions: http://www.slideshare.net/mwessendorf
> > >> > twitter: http://twitter.com/mwessendorf
> > >>
> > >> > _______________________________________________
> > >> > aerogear-dev mailing list
> > >> > aerogear-dev at lists.jboss.org
> > >> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > >>
> > >>
> > >> --
> > >>
> > >> abstractj
> > >> _______________________________________________
> > >> aerogear-dev mailing list
> > >> aerogear-dev at lists.jboss.org
> > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > >>
> > >
> > >
> > >
> > > --
> > > Matthias Wessendorf
> > >
> > > blog: http://matthiaswessendorf.wordpress.com/
> > > sessions: http://www.slideshare.net/mwessendorf
> > > twitter: http://twitter.com/mwessendorf
> > >
> >
> >
> >
> > --
> > Matthias Wessendorf
> >
> > blog: http://matthiaswessendorf.wordpress.com/
> > sessions: http://www.slideshare.net/mwessendorf
> > twitter: http://twitter.com/mwessendorf
>
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> --
>
> abstractj
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140618/7c47547d/attachment-0001.html 

From matzew at apache.org  Wed Jun 18 01:13:03 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Wed, 18 Jun 2014 07:13:03 +0200
Subject: [aerogear-dev] Keycloak integration and UPS Sender
In-Reply-To: <20140617222221.GB37741@abstractj.org>
References: <20140617142624.GA23555@abstractj.org>
	<B6A470CC-DE76-4A00-B56B-76434079BDEA@redhat.com>
	<20140617172332.GB32200@abstractj.org>
	<CAAg5f2TgqmkRKWqyjk6kEuMa9Hvgs_RY_7XXdfxrUDsw3kDNag@mail.gmail.com>
	<20140617222221.GB37741@abstractj.org>
Message-ID: <CAAg5f2Q90FCtaF8W4ZJAc_JCJJcenpQhTX5JcS3Uav1s=YpGGw@mail.gmail.com>

On Wed, Jun 18, 2014 at 12:22 AM, Bruno Oliveira <bruno at abstractj.org>
wrote:

> On 2014-06-17, Matthias Wessendorf wrote:
> > Bom Dia!
> >
> >
> > On Tue, Jun 17, 2014 at 7:23 PM, Bruno Oliveira <bruno at abstractj.org>
> wrote:
> >
> > > Ahoy Jay, answers inline.
> > >
> > > On 2014-06-17, Jay Balunas wrote:
> > > > Great explanation of the issue and options!
> > > >
> > > > On Jun 17, 2014, at 10:26 AM, Bruno Oliveira <bruno at abstractj.org>
> > > wrote:
> > > >
> > > > > Good morning peeps,
> > > > >
> > > > > I have a problem to solve which might affect the Sender and
> > > > > all the related clients.
> > > > >
> > > > > Previously, the UPS Sender was protected by the basic
> authentication
> > > > > method[1], so anyone in possession of _PushApplicationID_ and
> > > > > _MasterSecret_ is able to send push messages.
> > > > >
> > > > > After the integration with Keycloak now everything under _/rest_
> > > > > is properly protect by KC which is totally correct. Our sender is
> under
> > > > > the same umbrella which means that now Bearer token authentication
> is
> > > > > required[2] and Basic authentication won't exist anymore.
> > > > >
> > > > > The consequence of this is the basic form being presented when you
> try
> > > > > to send push notifications[3]. The problem didn't occur before,
> because
> > > > > we were just using Basic authentication[4] instead of Bearer
> tokens.
> > > > >
> > > > > Possible solutions:
> > > > >
> > > > > 1- After the removal of Basic authentication, move
> _PushApplicationID_
> > > > > and _MasterSecret to http headers like:
> > > > >
> > > > > -H "PushApplicationID: XXXXXX" -H "MasterSecret: 42"
> > > > >
> > > > > IMO it sounds correct and reasonable for me.
> > > >
> > > > How will this impact CURL usage from the command line?
> > > > How will this impact Java sender usage?
> > >
> > > We would change from (being logged in would be required):
> > >
> > > curl -3 -u "{PushApplicationID}:{MasterSecret}"
> > >    -v -H "Accept: application/json" -H "Content-type: application/json"
> > >       -X POST
> > >
> > > To:
> > >
> > > curl -3
> > >    -v -H "PushApplicationID: XXXXXX" -H "MasterSecret: 42" \
> > >       -H "Accept: application/json" -H "Content-type: application/json"
> > >       -X POST
> > >
> > >
> >
> >
> > That sounds like the most safe change to our client-registration and
> sender
> > SDKs. Basically a 'minor' change where we issue the HTTP request.
> >
> > I'd vote for this change, but only if it is not possible to exclude a few
> > URLs from Keycloak ;-)
>
> Thanks Matthias, we will try to find a consensus on it.
>
> >
> > Note, that those excluded endpoints (for device-registration and sender)
> > don't require any <auth-method> setting in web.xml,
> > as they implement their own simple HTTP_BASIC handling by querying our
> > database ;-)
> >
> https://github.com/abstractj/aerogear-unifiedpush-server/blob/keycloak.js/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/sender/PushNotificationSenderEndpoint.java#L55-L61
>
> If you look at KC examples[1], most of them properly make use of
> auth-method.


yeah, I did not say that we should not use
<auth-mehod>KEYCLOAK</auth-method>. Sorry if that was not clear.



> IMO it's necessary if we want to benefit of bearer tokens
> on the admin-ui (I can be wrong on my understanding).
>

Yeah, I understand! But I'd really like to exclude a few URLs from Keycloak
protection and have themselves handle their auth (HTTP_BASIC in this case),
as explained in my previous email.

If this exclusion, with the proper use of
<auth-mehod>KEYCLOAK</auth-method> is NOT possible, let's pay the tax and
update all of our clients. As said, your header suggestion sounds good to
me and should not take longer than a day (per client). But I'd really like
to avoid that change :-))


-Matthias



>
>
> >
> >
> >
> > But, yeah - if the exclusion is not possible at all, I like your
> suggested
> > header usage fix. IMO that's the one with the fewest risks.
> >
> >
> > -Matthias
> >
> >
> >
> >
> > > >
> > > > >
> > > > > 2. Create a role specific for the sender like _push-applications_
> and
> > > > > dinamically add _PushApplicationID_ and _MasterSecret on Keycloak
> > > where:
> > > > >
> > > > > username: _PushApplicationID_
> > > > > password: _MasterSecret_
> > > > >
> > > > > The implications of this alternative is the fact of have to manage
> > > those
> > > > > credentials on the server side inclusion/exclusion/login
> > > >
> > > > Would each application have its own "role" just for the sender in
> this
> > > case?
> > >
> > > Each application would have the same role "ups-application".
> > >
> > > >
> > > > >
> > > > > 3. Implement another authentication provider specifically for the
> > > sender
> > > > > and Basic authentication[5]
> > > >
> > > > Not sure of the impact here, but sounds like a complex solution.
> > >
> > > Yes, totally agree on that.
> > >
> > > >
> > > > >
> > > > > 4. Do nothing. The consequences of this alternative is to implement
> > > > > everything already done by Keycloak.js and manage session tokens by
> > > hand
> > > > > on the admin-ui.
> > > >
> > > > -1
> > >
> > > Stian sent to me a message, he might have more ideas about how to
> > > overcome this issue. I will update you guys during this week.
> > >
> > > >
> > > > >
> > > > > To me the first alternative seems to be more simple, but I really
> want
> > > > > your feedback on it, once it affects the whole project.
> > > > >
> > > > > [1] -
> > > > >
> > >
> https://github.com/aerogear/aerogear-unifiedpush-server/blob/6c1a0d3fedea8fb6ba918009fd8e9785779c151f/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/sender/PushNotificationSenderEndpoint.java#L56
> > > > >
> > > > > [2] -
> > > > >
> > >
> https://github.com/abstractj/aerogear-unifiedpush-server/tree/keycloak.js
> > > > > [3] -
> > > > >
> > >
> http://photon.abstractj.org/AeroGear_UnifiedPush_Server_2014-06-17_10-00-09_2014-06-17_10-00-12.jpg
> > > > >
> > > > > [4] -
> > > > >
> > >
> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/server/src/main/webapp/WEB-INF/web.xml#L57
> > > > >
> > > > > [5] -
> > >
> https://github.com/keycloak/keycloak/tree/master/examples/providers/authentication-properties
> > > > >
> > > > > --
> > > > >
> > > > > abstractj
> > > > > _______________________________________________
> > > > > aerogear-dev mailing list
> > > > > aerogear-dev at lists.jboss.org
> > > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > >
> > > >
> > > > _______________________________________________
> > > > aerogear-dev mailing list
> > > > aerogear-dev at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > >
> > > --
> > >
> > > abstractj
> > > _______________________________________________
> > > aerogear-dev mailing list
> > > aerogear-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > >
> >
> >
> >
> > --
> > Matthias Wessendorf
> >
> > blog: http://matthiaswessendorf.wordpress.com/
> > sessions: http://www.slideshare.net/mwessendorf
> > twitter: http://twitter.com/mwessendorf
>
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> --
>
> abstractj
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140618/d06d0050/attachment.html 

From lukas.fryc at gmail.com  Wed Jun 18 06:10:04 2014
From: lukas.fryc at gmail.com (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=)
Date: Wed, 18 Jun 2014 12:10:04 +0200
Subject: [aerogear-dev] UPS console: server error response handling on
	client-side
In-Reply-To: <20140618043821.GA50729@abstractj.org>
References: <CAEroY37JM9JY3_L=J=B6wnO=J2=9qNoqVoS6xRUMfHA5UsyV9g@mail.gmail.com>
	<20140618043821.GA50729@abstractj.org>
Message-ID: <CAEroY35vF4bwE2jWH4bjFeSRp8LACC5w4iA8sby+qdU=5Pk_jQ@mail.gmail.com>

Generally status code (e.g. 500) and status text (Server Response Failed)
are not enough to provide meaningful feedback to the user.

Sometimes we can use knowledge about the domain problem (e.g. GET /variants
-> 404 = variant is missing),
but often the client can't have any clue why server failed.

It's important to pass this information to the user so he can act upon it.
This will also help us to make our UPS code more robust, because error
reports from UPS Admin Console will contain more information.

~~~

Usually REST interfaces follow common (API-wide) pattern (contract) that
provides user with a meaningful message in a unified way.

Disclaimer: btw it is possible we already use some pattern that I could
miss. :-)

~~~

For example there is nice summary:
https://blog.apigee.com/detail/restful_api_design_what_about_errors


On Wed, Jun 18, 2014 at 6:38 AM, Bruno Oliveira <bruno at abstractj.org> wrote:

> Sorry for the late response Lukas.
>
> On 2014-06-16, Luk?? Fry? wrote:
> > Hey guys,
> >
> > I was looking into AGPUSH-720 and I got an perception that not all error
> > response do we actually know on the client-side.
> >
> > We should establish a common pattern - contract between server and
> client -
> > which says how is a failure message transported from server to client,
> e.g.:
> >
> > - response header
> > - response message body /w given structure
>
> Speaking about a contract between client/server what would you suggest?
> Maybe we can start a gist for these definitions once it affects other
> clients?
>
> >
> >
> > Right now, I've opened a PR for a generic failure handling mechanism that
> > can catch and report any error:
> > https://github.com/aerogear/aerogear-unifiedpush-server/pull/226/files
>
> I've already commented on that, overall looks good.
>
> >
> > I plan to extend this error handling code dynamically as needed based on
> > response codes (e.g. 404=Request resource is missing) and contract
> > mentioned above ^.
> >
> > Wdyt?
> >
> >
> > ~ Lukas
>
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> --
>
> abstractj
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140618/30a37853/attachment-0001.html 

From lukas.fryc at gmail.com  Wed Jun 18 06:17:41 2014
From: lukas.fryc at gmail.com (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=)
Date: Wed, 18 Jun 2014 12:17:41 +0200
Subject: [aerogear-dev] UPS console: server error response handling on
	client-side
In-Reply-To: <CAEroY35vF4bwE2jWH4bjFeSRp8LACC5w4iA8sby+qdU=5Pk_jQ@mail.gmail.com>
References: <CAEroY37JM9JY3_L=J=B6wnO=J2=9qNoqVoS6xRUMfHA5UsyV9g@mail.gmail.com>
	<20140618043821.GA50729@abstractj.org>
	<CAEroY35vF4bwE2jWH4bjFeSRp8LACC5w4iA8sby+qdU=5Pk_jQ@mail.gmail.com>
Message-ID: <CAEroY35Ozc2Z-Hi8GdqRHUf85FMDdVrQRtGayvcPXAFD0CSDtQ@mail.gmail.com>

A gist is here to allow us to brainstorm:
https://gist.github.com/lfryc/fdb7c7411c807e7d99c9


On Wed, Jun 18, 2014 at 12:10 PM, Luk?? Fry? <lukas.fryc at gmail.com> wrote:

> Generally status code (e.g. 500) and status text (Server Response Failed)
> are not enough to provide meaningful feedback to the user.
>
> Sometimes we can use knowledge about the domain problem (e.g. GET
> /variants -> 404 = variant is missing),
> but often the client can't have any clue why server failed.
>
> It's important to pass this information to the user so he can act upon it.
> This will also help us to make our UPS code more robust, because error
> reports from UPS Admin Console will contain more information.
>
> ~~~
>
> Usually REST interfaces follow common (API-wide) pattern (contract) that
> provides user with a meaningful message in a unified way.
>
> Disclaimer: btw it is possible we already use some pattern that I could
> miss. :-)
>
> ~~~
>
> For example there is nice summary:
> https://blog.apigee.com/detail/restful_api_design_what_about_errors
>
>
> On Wed, Jun 18, 2014 at 6:38 AM, Bruno Oliveira <bruno at abstractj.org>
> wrote:
>
>> Sorry for the late response Lukas.
>>
>> On 2014-06-16, Luk?? Fry? wrote:
>> > Hey guys,
>> >
>> > I was looking into AGPUSH-720 and I got an perception that not all error
>> > response do we actually know on the client-side.
>> >
>> > We should establish a common pattern - contract between server and
>> client -
>> > which says how is a failure message transported from server to client,
>> e.g.:
>> >
>> > - response header
>> > - response message body /w given structure
>>
>> Speaking about a contract between client/server what would you suggest?
>> Maybe we can start a gist for these definitions once it affects other
>> clients?
>>
>> >
>> >
>> > Right now, I've opened a PR for a generic failure handling mechanism
>> that
>> > can catch and report any error:
>> > https://github.com/aerogear/aerogear-unifiedpush-server/pull/226/files
>>
>> I've already commented on that, overall looks good.
>>
>> >
>> > I plan to extend this error handling code dynamically as needed based on
>> > response codes (e.g. 404=Request resource is missing) and contract
>> > mentioned above ^.
>> >
>> > Wdyt?
>> >
>> >
>> > ~ Lukas
>>
>> > _______________________________________________
>> > aerogear-dev mailing list
>> > aerogear-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>> --
>>
>> abstractj
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140618/51f1489a/attachment.html 

From bruno at abstractj.org  Wed Jun 18 08:48:46 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Wed, 18 Jun 2014 09:48:46 -0300
Subject: [aerogear-dev] [Help]With OTP between iOS and Android
In-Reply-To: <B255CC3D00A247448AF86CE5C48F7F631D6CF8@TWGTPNT02.gangutech.com>
References: <B255CC3D00A247448AF86CE5C48F7F631D6CF8@TWGTPNT02.gangutech.com>
Message-ID: <20140618124846.GA51272@abstractj.org>

Good morning my friend.

Would you mind to send those classes modified to the mailing list using
https://gist.github.com/ or http://pastebin.com/. Into this way we can
try locally and double check the issue.

Thanks in advance.

On 2014-06-12, Hunter Chen wrote:
> Dear Sir,
>
>         I have download the OTP library form Gitihub,
> https://github.com/aerogear/aerogear-otp-java
> https://github.com/aerogear/aerogear-otp-ios
>
>    after I modify the Clock class android Base32 class
> I input fixed string ABCDEFGH, and fixed interval time 46752201
>
> I got the different result
> Ios output >  46752190
> Android output  >>>  46752201
>
>
> Could you help me ? thanks..

> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


--

abstractj

From keith at kdmooreconsulting.com  Wed Jun 18 08:54:15 2014
From: keith at kdmooreconsulting.com (keithdmoore94)
Date: Wed, 18 Jun 2014 05:54:15 -0700 (PDT)
Subject: [aerogear-dev] Aerogear Cordova Push Plugin: Actual vs Expected
	Results
Message-ID: <1403096055593-8200.post@n5.nabble.com>

I am seeing behavior that is inconsistent with other native applications that
I have used as well as inconsistent behavior between Android and iOS.  For
the sake of simplicity, I am going to leave the ?foreground? flag out of
this discussion.

Precondition
Three push notifications have been sent by an external client.  Let?s call
them ?Push1?, ?Push2? and ?Push3?.  They were sent in that order by the
external client.  Let?s assume the client received them in that order as
well.  Mobile application is not in the foreground.

Actions
User navigates to the notifications panel.   

Android Experience
Android will only show the very last notification in the notification panel. 
User touches the notification(?Push3?), the app is brought into the
foreground.  The notifications are received by the app in the order in which
they were received.  All the push notifications in the notification panel
are gone.  First of all, I would have expected all three notifications to be
displayed in the notifications panel.  Also, I would expect that the
remaining ?Push1? and ?Push3? notifications to remain in the notifications
panel and NOT be sent to the app.

iOS Experience
iOS will show all the apps notifications in the notification panel.  User
touches the ?Push2? notification, the app is brought into the foreground. 
The ?Push2? notification is received by the app.   The others are NOT
received.  All the push notifications in the notification panel are gone. 
Here I would expect the ?Push1? and ?Push3? notifications to remain in the
notifications panel.


The behavior I am seeing seems inconsistent with almost all the other apps I
have used that support push notifications.  Seems like the plugin should be
changed to have standard behavior and should be consistent across both
Android and iOS as much as possible.  I am considering working on doing
that.  Any thoughts regarding this ?


Thanks,

Keith D. Moore



--
View this message in context: http://aerogear-dev.1069024.n5.nabble.com/Aerogear-Cordova-Push-Plugin-Actual-vs-Expected-Results-tp8200.html
Sent from the aerogear-dev mailing list archive at Nabble.com.


From yagyesh.agrawal at itpeoplecorp.com  Wed Jun 18 12:41:47 2014
From: yagyesh.agrawal at itpeoplecorp.com (Yagyesh)
Date: Wed, 18 Jun 2014 09:41:47 -0700 (PDT)
Subject: [aerogear-dev] Aerogear Cordova Push Plugin: Actual vs Expected
	Results
In-Reply-To: <1403096055593-8200.post@n5.nabble.com>
References: <1403096055593-8200.post@n5.nabble.com>
Message-ID: <1403109707308-8201.post@n5.nabble.com>

>From whatever i have seen, on iOS there arent any explicit API's to clear
specific notification from Notification center (not sure if anything got
introduced with iOS8). However, to clear all notifications, Apple's
documentations says to set the badge count to 0.

So to make things consistent, you can clear all notifications from an app
once a notification is selected and app comes to foreground. Having said
that, I feel we should let developer of the app decide whether he wants to
clear or not & let things be.



--
View this message in context: http://aerogear-dev.1069024.n5.nabble.com/Aerogear-Cordova-Push-Plugin-Actual-vs-Expected-Results-tp8200p8201.html
Sent from the aerogear-dev mailing list archive at Nabble.com.

From kpiwko at redhat.com  Wed Jun 18 13:27:04 2014
From: kpiwko at redhat.com (Karel Piwko)
Date: Wed, 18 Jun 2014 13:27:04 -0400 (EDT)
Subject: [aerogear-dev] Keycloak integration and UPS Sender
In-Reply-To: <20140617171736.GA32200@abstractj.org>
References: <20140617142624.GA23555@abstractj.org>
	<CAAg5f2Ry2KWC1WOp64hoS9udX1OWFFz=ZH0En9qx07gE5vC0Eg@mail.gmail.com>
	<20140617171736.GA32200@abstractj.org>
Message-ID: <1134095807.26725095.1403112424692.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Bruno Oliveira" <bruno at abstractj.org>
> To: "AeroGear Developer Mailing List" <aerogear-dev at lists.jboss.org>
> Sent: Tuesday, June 17, 2014 7:17:36 PM
> Subject: Re: [aerogear-dev] Keycloak integration and UPS Sender
> 
> >
> >
> > IMO if possible, keeping these 'exceptions' (or excludes) under HTTP_BASIC
> > would be the simplest solution, as that means none of our client SDKs
> > (Android, iOS, Cordova, Node.js Sender, Java-Sendet etc) would require an
> > update.
> 
> I had a chat with Stian and looks like it's possible to support both
> auth methods in a single app, but that would involve changes on Keycloak.
> It's just the matter of discuss with KC team.
> 
> My two cents is the fact that we should use bearer tokens only, instead
> of mix both auth methods in a single app ? now that we have KC.
> And discuss the changes into our clients rather sooner than later.
> 
> But I'm open for whatever you guys think it's the best.

I agree here, we should try to aim to have only one auth method - bearer tokens unless it has
performance or usability consequences. Mix is more error prone and more complicated to maintain longterm imho.

> 


From bruno at abstractj.org  Wed Jun 18 15:12:55 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Wed, 18 Jun 2014 16:12:55 -0300
Subject: [aerogear-dev] Keycloak integration and UPS Sender
In-Reply-To: <CAAg5f2SzOp+cik4iuZPxOo-7ABOAnCk_VCLzEQSKWU7bs=gdSg@mail.gmail.com>
References: <20140617142624.GA23555@abstractj.org>
	<CAAg5f2Ry2KWC1WOp64hoS9udX1OWFFz=ZH0En9qx07gE5vC0Eg@mail.gmail.com>
	<20140617171736.GA32200@abstractj.org>
	<CAAg5f2S1bxQC6k0dLxXAhd7LX8aj0XakUDSX+TLmzUUeqMG36w@mail.gmail.com>
	<CAAg5f2RJXsQMdYNjtdf+30Kx6=1sVREoBVB_5Cyry328wcX9Cw@mail.gmail.com>
	<20140617221225.GA37741@abstractj.org>
	<CAAg5f2SzOp+cik4iuZPxOo-7ABOAnCk_VCLzEQSKWU7bs=gdSg@mail.gmail.com>
Message-ID: <20140618191255.GB62889@abstractj.org>

Hi guys, let's see the result of the conversation with KC team and we
can revisit this discussion if some changed is required.

On 2014-06-18, Matthias Wessendorf wrote:
> On Wed, Jun 18, 2014 at 12:12 AM, Bruno Oliveira <bruno at abstractj.org>
> wrote:
>
> > Answers inline.
> >
> > On 2014-06-17, Matthias Wessendorf wrote:
> > > On Tue, Jun 17, 2014 at 8:51 PM, Matthias Wessendorf <matzew at apache.org>
> > > wrote:
> > >
> > > >
> > > >
> > > >
> > > > On Tue, Jun 17, 2014 at 7:17 PM, Bruno Oliveira <bruno at abstractj.org>
> > > > wrote:
> > > >
> > > >> Hi Matthias, answer inline.
> > > >>
> > > >> On 2014-06-17, Matthias Wessendorf wrote:
> > > >> > On Tue, Jun 17, 2014 at 4:26 PM, Bruno Oliveira <
> > bruno at abstractj.org>
> > > >> wrote:
> > > >> >
> > > >> > > Good morning peeps,
> > > >> > >
> > > >> > > I have a problem to solve which might affect the Sender and
> > > >> > > all the related clients.
> > > >> > >
> > > >> > > Previously, the UPS Sender was protected by the basic
> > authentication
> > > >> > > method[1], so anyone in possession of _PushApplicationID_ and
> > > >> > > _MasterSecret_ is able to send push messages.
> > > >> > >
> > > >> > > After the integration with Keycloak now everything under _/rest_
> > > >> > > is properly protect by KC which is totally correct. Our sender is
> > > >> under
> > > >> > > the same umbrella which means that now Bearer token
> > authentication is
> > > >> > > required[2] and Basic authentication won't exist anymore.
> > > >> > >
> > > >> >
> > > >> >
> > > >> > The device (un)registration endpoints are hit by this as well
> > > >> > (/rest/registry/device/*).
> > > >>
> > > >> Currently Keycloak is protecting our endpoints under /rest/*
> > > >>
> > > >> >
> > > >> > I am wondering if it isn't it possible to keep those URLs protected
> > via
> > > >> > HTTP_BASIC, or does the keycloak.js usage deny this?
> > > >>
> > > >> Is not the Keycloak.js usage responsible for this, but the correct
> > > >> configuration of the application atm. Please compare:
> > > >>
> > > >> - master branch:
> > > >>
> > > >>
> > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/server/src/main/webapp/WEB-INF/web.xml#L56
> > > >> - keycloak.js branch:
> > > >>
> > > >>
> > https://github.com/aerogear/aerogear-unifiedpush-server/blob/keycloak.js/server/src/main/webapp/WEB-INF/web.xml#L33
> > > >>
> > > >> Now we're fully using Keycloak bearer tokens instead of Basic.
> > > >>
> > > >
> > > >
> > > > Oh, I was following Bill's sample project, where he did not use the
> > > > 'KEYCLOAK' auth-method:
> > > >
> > > >
> > https://github.com/keycloak/keycloak/blob/master/project-integrations/aerogear-ups/app/src/main/webapp/WEB-INF/web.xml#L44
> > > >
> > > > But we had the exclusion working w/ the KEYCLOAK 'auth-method', but
> > this
> > > > goes back to our initial starts in Dec/Jan.
> > > > Here is a rebased commit based on your initial commit:
> > > >
> > > >
> > https://github.com/aerogear/aerogear-unifiedpush-server/blob/2aabd073aaaafa79943ea41d2651f6f0c5e4248e/server/src/main/webapp/WEB-INF/web.xml#L42-L53
> > > >
> > > >
> > > >>
> > > >> >
> > > >> > On master (plain keycloak; before keycloak.js usage) we are doing an
> > > >> > exclude for those URLs:
> > > >> >
> > > >>
> > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/server/src/main/webapp/WEB-INF/web.xml#L46-L52
> > > >>
> > > >> I tried to include your exclusions, but that didn't work for me.
> > > >>
> > > >> >
> > > >> >
> > > >> > IMO if possible, keeping these 'exceptions' (or excludes) under
> > > >> HTTP_BASIC
> > > >> > would be the simplest solution, as that means none of our client
> > SDKs
> > > >> > (Android, iOS, Cordova, Node.js Sender, Java-Sendet etc) would
> > require
> > > >> an
> > > >> > update.
> > > >>
> > > >> I had a chat with Stian and looks like it's possible to support both
> > > >> auth methods in a single app, but that would involve changes on
> > Keycloak.
> > > >> It's just the matter of discuss with KC team.
> > > >>
> > > >
> > > > I don't think we need to enable to <auth-method> settings in our
> > web.xml;
> > > >
> >
> > How do you manage login/logout/current logged in user on Angular.js? Is
> > possible to do on the server side, but how do you control it on the
> > client side?
> >
>
> Sure, to protect the admin-ui and most of the /rest/* endpoints we need the
> one <auth-method>KEYCLOAK</auth-method>. No question there. I was trying to
> say we do not need multiple 'auth-method' elements on web.xml
>
> But I think it should be possible to exclude a few URLs, like '/rest/foo'
> and '/rest/bar', so that they are completely unprotected in terms of
> Keycloak (e.g. via different security-constraint elements):
> https://github.com/aerogear/aerogear-unifiedpush-server/blob/2aabd073aaaafa79943ea41d2651f6f0c5e4248e/server/src/main/webapp/WEB-INF/web.xml
>
> In terms of "current logged in user on Angular.js":
> * For the "/rest/sender" and "/rest/device/registration" endpoints, I don't
> see a relationship to the user on Angular.js/AdminUI at all.
>
> Internally these 'unprotected' (or excluded) endpoints implement the
> HTTP_BASIC scheme themselves:
> * They treat the Application/Variant like a 'user', by performing a DB
> lookup of the give application/variantID
> * If that (Application or Variant) is found, the endpoints compare the
> given 'password' form the request w/ the "secret" on the  Application or
> Variant
>
> But for these endpoints (sender and device-registration) there is no real
> user here like "Mr. Jay" or "Push-Admin Foo".
>
> The client (registration or sender SDK) performs the auth, by applying the
> ID and the secret:
> curl -3 -u "{PushApplicationID}:{MasterSecret}" .... https://server
>
>
>
> >
> > >
> > > I mean: I think there is no need to enable multiple <auth-method> args,
> > as
> > > we had the exclusion already working at some point, using their KEYCLOAK
> > > auth-method
> >
> > Stian did that inclusion which for me looks correct. An excerpt from KC
> > documentation:
> >
> > "To be able to secure WAR apps deployed on JBoss AS 7.1.1, JBoss EAP 6.x,
> > or Wildfly, you must install and configure the Keycloak Subsystem. You
> > then have two options to secure your WARs. You can provide a keycloak
> > config file in your WAR and change the auth-method to KEYCLOAK within
> > web.xml. Alternatively, you don't have to crack open your WARs at all
> > and can apply Keycloak via the Keycloak Subsystem configuration in
> > standalone.xml. Both methods are described in this section."
> >
> > You can also stick with BASIC, but probably you end with implementations
> > and customizations that don't take any benefit of Keycloak.js.
> >
> > Either way I will talk tomorrow with Stian and let's see what we can do.
> >
> > >
> > >
> > >
> > > >
> > > > My initial hope was to be able to simply exclude a few URLs from the
> > > > overall Keycloak protection, like the above referenced commit:
> > > >
> > > >
> > https://github.com/aerogear/aerogear-unifiedpush-server/blob/2aabd073aaaafa79943ea41d2651f6f0c5e4248e/server/src/main/webapp/WEB-INF/web.xml#L42-L53
> > > >
> > > > That would be best as that would mean no API change at all, and our
> > > > client-registration and sender SDKs could stay as they are.
> > > >
> > > >
> > > >
> > > >
> > > >>
> > > >> My two cents is the fact that we should use bearer tokens only,
> > instead
> > > >> of mix both auth methods in a single app ? now that we have KC.
> > > >> And discuss the changes into our clients rather sooner than later.
> > > >>
> > > >> But I'm open for whatever you guys think it's the best.
> > > >>
> > > >>
> > > >> >
> > > >> > -Matthias
> > > >> >
> > > >> >
> > > >> >
> > > >> >
> > > >> >
> > > >> > >
> > > >> > > The consequence of this is the basic form being presented when
> > you try
> > > >> > > to send push notifications[3]. The problem didn't occur before,
> > > >> because
> > > >> > > we were just using Basic authentication[4] instead of Bearer
> > tokens.
> > > >> > >
> > > >> > > Possible solutions:
> > > >> > >
> > > >> > > 1- After the removal of Basic authentication, move
> > _PushApplicationID_
> > > >> > > and _MasterSecret to http headers like:
> > > >> > >
> > > >> > > -H "PushApplicationID: XXXXXX" -H "MasterSecret: 42"
> > > >> > >
> > > >> > > IMO it sounds correct and reasonable for me.
> > > >> > >
> > > >> > > 2. Create a role specific for the sender like _push-applications_
> > and
> > > >> > > dinamically add _PushApplicationID_ and _MasterSecret on Keycloak
> > > >> where:
> > > >> > >
> > > >> > > username: _PushApplicationID_
> > > >> > > password: _MasterSecret_
> > > >> > >
> > > >> > > The implications of this alternative is the fact of have to manage
> > > >> those
> > > >> > > credentials on the server side inclusion/exclusion/login
> > > >> > >
> > > >> > > 3. Implement another authentication provider specifically for the
> > > >> sender
> > > >> > > and Basic authentication[5]
> > > >> > >
> > > >> > > 4. Do nothing. The consequences of this alternative is to
> > implement
> > > >> > > everything already done by Keycloak.js and manage session tokens
> > by
> > > >> hand
> > > >> > > on the admin-ui.
> > > >> > >
> > > >> > > To me the first alternative seems to be more simple, but I really
> > want
> > > >> > > your feedback on it, once it affects the whole project.
> > > >> > >
> > > >> > > [1] -
> > > >> > >
> > > >> > >
> > > >>
> > https://github.com/aerogear/aerogear-unifiedpush-server/blob/6c1a0d3fedea8fb6ba918009fd8e9785779c151f/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/sender/PushNotificationSenderEndpoint.java#L56
> > > >> > >
> > > >> > > [2] -
> > > >> > >
> > > >>
> > https://github.com/abstractj/aerogear-unifiedpush-server/tree/keycloak.js
> > > >> > > [3] -
> > > >> > >
> > > >> > >
> > > >>
> > http://photon.abstractj.org/AeroGear_UnifiedPush_Server_2014-06-17_10-00-09_2014-06-17_10-00-12.jpg
> > > >> > >
> > > >> > > [4] -
> > > >> > >
> > > >> > >
> > > >>
> > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/server/src/main/webapp/WEB-INF/web.xml#L57
> > > >> > >
> > > >> > > [5] -
> > > >> > >
> > > >>
> > https://github.com/keycloak/keycloak/tree/master/examples/providers/authentication-properties
> > > >> > >
> > > >> > > --
> > > >> > >
> > > >> > > abstractj
> > > >> > > _______________________________________________
> > > >> > > aerogear-dev mailing list
> > > >> > > aerogear-dev at lists.jboss.org
> > > >> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > >> > >
> > > >> >
> > > >> >
> > > >> >
> > > >> > --
> > > >> > Matthias Wessendorf
> > > >> >
> > > >> > blog: http://matthiaswessendorf.wordpress.com/
> > > >> > sessions: http://www.slideshare.net/mwessendorf
> > > >> > twitter: http://twitter.com/mwessendorf
> > > >>
> > > >> > _______________________________________________
> > > >> > aerogear-dev mailing list
> > > >> > aerogear-dev at lists.jboss.org
> > > >> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > >>
> > > >>
> > > >> --
> > > >>
> > > >> abstractj
> > > >> _______________________________________________
> > > >> aerogear-dev mailing list
> > > >> aerogear-dev at lists.jboss.org
> > > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > >>
> > > >
> > > >
> > > >
> > > > --
> > > > Matthias Wessendorf
> > > >
> > > > blog: http://matthiaswessendorf.wordpress.com/
> > > > sessions: http://www.slideshare.net/mwessendorf
> > > > twitter: http://twitter.com/mwessendorf
> > > >
> > >
> > >
> > >
> > > --
> > > Matthias Wessendorf
> > >
> > > blog: http://matthiaswessendorf.wordpress.com/
> > > sessions: http://www.slideshare.net/mwessendorf
> > > twitter: http://twitter.com/mwessendorf
> >
> > > _______________________________________________
> > > aerogear-dev mailing list
> > > aerogear-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> >
> > --
> >
> > abstractj
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf

> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


--

abstractj

From bruno at abstractj.org  Wed Jun 18 15:15:50 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Wed, 18 Jun 2014 16:15:50 -0300
Subject: [aerogear-dev] UPS branch for testing KC beta3
Message-ID: <20140618191550.GC62889@abstractj.org>

Good morning,

If you want to try Keycloak beta3, I created a new branch called
keycloak-beta3 for testing and already rebased against the master
(https://github.com/aerogear/aerogear-unifiedpush-server/tree/keycloak-beta3).
Nexus repository was included until KC release be available on Maven central.

Note: This branch does not include the integration with keycloak.js

--

abstractj

From stian at redhat.com  Thu Jun 19 04:33:12 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 19 Jun 2014 04:33:12 -0400 (EDT)
Subject: [aerogear-dev] Keycloak integration and UPS Sender
In-Reply-To: <20140618191255.GB62889@abstractj.org>
References: <20140617142624.GA23555@abstractj.org>
	<CAAg5f2Ry2KWC1WOp64hoS9udX1OWFFz=ZH0En9qx07gE5vC0Eg@mail.gmail.com>
	<20140617171736.GA32200@abstractj.org>
	<CAAg5f2S1bxQC6k0dLxXAhd7LX8aj0XakUDSX+TLmzUUeqMG36w@mail.gmail.com>
	<CAAg5f2RJXsQMdYNjtdf+30Kx6=1sVREoBVB_5Cyry328wcX9Cw@mail.gmail.com>
	<20140617221225.GA37741@abstractj.org>
	<CAAg5f2SzOp+cik4iuZPxOo-7ABOAnCk_VCLzEQSKWU7bs=gdSg@mail.gmail.com>
	<20140618191255.GB62889@abstractj.org>
Message-ID: <1162554208.29260954.1403166792852.JavaMail.zimbra@redhat.com>

Here's an idea on how it could be done (disclaimer: this is just a rough idea so take it with a pinch of salt ;)). Some benefits:

* Relatively simple to maintain backwards compatibility
* Support public clients directly (by using logged in users permissions)
* One application can access multiple UPS Apps
* No need to maintain master secret in UPS (and can support multiple methods to auth in the future, for example cert or jwt
* Manage access through KC - what app/client or user can access what UPS App


When creating a new UPS App create:

* A role on unified-push-server - the name should be equal to id of UPS app

Applications should have 3 options to authenticate:

* As the logged in user (for client side applications)
* As themselves (for server side applications)
* HTTP Basic

The master secret can also be removed from UPS App as it should no longer be required.

As the logged in user
---------------------
This allows public applications to send push messages on behalf of the logged in user. The steps required are:

1) Create an application/client in Keycloak
    * Set to public client
    * Add scope on UPS App role
2) Create user
    * Add role mapping on UPS App role
3) Users logs in with username/password, social, etc through KC login   
   screens
4) Application can send push messages with bearer token using users    
   permissions

As themselves
-------------
This allows a server-side application to send push messages on behalf of itself. The steps required are:

1) Create an application/client in Keycloak
    * Add scope on UPS App role
2) Create user
    * Add role mapping on UPS App role
    * Set a long unique password (equivalent of master secret)
3) Application logs in with username/password (equal to UPS App
   id/master-secret) using direct grant
4) Application can send push messages with bearer token using its own    
   permissions

In the future Keycloak will support additional mechanism for a server-side application to authenticate on behalf of itself (cert, jwts, etc).

HTTP Basic
----------
For backwards compatibility we can add a valve that extracts the UPS App id and master secret from Basic auth. It will then use the direct grant mechanism to obtain a token from Keycloak. The steps required to configure is the same as "As themselves".



----- Original Message -----
> From: "Bruno Oliveira" <bruno at abstractj.org>
> To: "AeroGear Developer Mailing List" <aerogear-dev at lists.jboss.org>
> Sent: Wednesday, 18 June, 2014 8:12:55 PM
> Subject: Re: [aerogear-dev] Keycloak integration and UPS Sender
> 
> Hi guys, let's see the result of the conversation with KC team and we
> can revisit this discussion if some changed is required.
> 
> On 2014-06-18, Matthias Wessendorf wrote:
> > On Wed, Jun 18, 2014 at 12:12 AM, Bruno Oliveira <bruno at abstractj.org>
> > wrote:
> >
> > > Answers inline.
> > >
> > > On 2014-06-17, Matthias Wessendorf wrote:
> > > > On Tue, Jun 17, 2014 at 8:51 PM, Matthias Wessendorf
> > > > <matzew at apache.org>
> > > > wrote:
> > > >
> > > > >
> > > > >
> > > > >
> > > > > On Tue, Jun 17, 2014 at 7:17 PM, Bruno Oliveira <bruno at abstractj.org>
> > > > > wrote:
> > > > >
> > > > >> Hi Matthias, answer inline.
> > > > >>
> > > > >> On 2014-06-17, Matthias Wessendorf wrote:
> > > > >> > On Tue, Jun 17, 2014 at 4:26 PM, Bruno Oliveira <
> > > bruno at abstractj.org>
> > > > >> wrote:
> > > > >> >
> > > > >> > > Good morning peeps,
> > > > >> > >
> > > > >> > > I have a problem to solve which might affect the Sender and
> > > > >> > > all the related clients.
> > > > >> > >
> > > > >> > > Previously, the UPS Sender was protected by the basic
> > > authentication
> > > > >> > > method[1], so anyone in possession of _PushApplicationID_ and
> > > > >> > > _MasterSecret_ is able to send push messages.
> > > > >> > >
> > > > >> > > After the integration with Keycloak now everything under _/rest_
> > > > >> > > is properly protect by KC which is totally correct. Our sender
> > > > >> > > is
> > > > >> under
> > > > >> > > the same umbrella which means that now Bearer token
> > > authentication is
> > > > >> > > required[2] and Basic authentication won't exist anymore.
> > > > >> > >
> > > > >> >
> > > > >> >
> > > > >> > The device (un)registration endpoints are hit by this as well
> > > > >> > (/rest/registry/device/*).
> > > > >>
> > > > >> Currently Keycloak is protecting our endpoints under /rest/*
> > > > >>
> > > > >> >
> > > > >> > I am wondering if it isn't it possible to keep those URLs
> > > > >> > protected
> > > via
> > > > >> > HTTP_BASIC, or does the keycloak.js usage deny this?
> > > > >>
> > > > >> Is not the Keycloak.js usage responsible for this, but the correct
> > > > >> configuration of the application atm. Please compare:
> > > > >>
> > > > >> - master branch:
> > > > >>
> > > > >>
> > > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/server/src/main/webapp/WEB-INF/web.xml#L56
> > > > >> - keycloak.js branch:
> > > > >>
> > > > >>
> > > https://github.com/aerogear/aerogear-unifiedpush-server/blob/keycloak.js/server/src/main/webapp/WEB-INF/web.xml#L33
> > > > >>
> > > > >> Now we're fully using Keycloak bearer tokens instead of Basic.
> > > > >>
> > > > >
> > > > >
> > > > > Oh, I was following Bill's sample project, where he did not use the
> > > > > 'KEYCLOAK' auth-method:
> > > > >
> > > > >
> > > https://github.com/keycloak/keycloak/blob/master/project-integrations/aerogear-ups/app/src/main/webapp/WEB-INF/web.xml#L44
> > > > >
> > > > > But we had the exclusion working w/ the KEYCLOAK 'auth-method', but
> > > this
> > > > > goes back to our initial starts in Dec/Jan.
> > > > > Here is a rebased commit based on your initial commit:
> > > > >
> > > > >
> > > https://github.com/aerogear/aerogear-unifiedpush-server/blob/2aabd073aaaafa79943ea41d2651f6f0c5e4248e/server/src/main/webapp/WEB-INF/web.xml#L42-L53
> > > > >
> > > > >
> > > > >>
> > > > >> >
> > > > >> > On master (plain keycloak; before keycloak.js usage) we are doing
> > > > >> > an
> > > > >> > exclude for those URLs:
> > > > >> >
> > > > >>
> > > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/server/src/main/webapp/WEB-INF/web.xml#L46-L52
> > > > >>
> > > > >> I tried to include your exclusions, but that didn't work for me.
> > > > >>
> > > > >> >
> > > > >> >
> > > > >> > IMO if possible, keeping these 'exceptions' (or excludes) under
> > > > >> HTTP_BASIC
> > > > >> > would be the simplest solution, as that means none of our client
> > > SDKs
> > > > >> > (Android, iOS, Cordova, Node.js Sender, Java-Sendet etc) would
> > > require
> > > > >> an
> > > > >> > update.
> > > > >>
> > > > >> I had a chat with Stian and looks like it's possible to support both
> > > > >> auth methods in a single app, but that would involve changes on
> > > Keycloak.
> > > > >> It's just the matter of discuss with KC team.
> > > > >>
> > > > >
> > > > > I don't think we need to enable to <auth-method> settings in our
> > > web.xml;
> > > > >
> > >
> > > How do you manage login/logout/current logged in user on Angular.js? Is
> > > possible to do on the server side, but how do you control it on the
> > > client side?
> > >
> >
> > Sure, to protect the admin-ui and most of the /rest/* endpoints we need the
> > one <auth-method>KEYCLOAK</auth-method>. No question there. I was trying to
> > say we do not need multiple 'auth-method' elements on web.xml
> >
> > But I think it should be possible to exclude a few URLs, like '/rest/foo'
> > and '/rest/bar', so that they are completely unprotected in terms of
> > Keycloak (e.g. via different security-constraint elements):
> > https://github.com/aerogear/aerogear-unifiedpush-server/blob/2aabd073aaaafa79943ea41d2651f6f0c5e4248e/server/src/main/webapp/WEB-INF/web.xml
> >
> > In terms of "current logged in user on Angular.js":
> > * For the "/rest/sender" and "/rest/device/registration" endpoints, I don't
> > see a relationship to the user on Angular.js/AdminUI at all.
> >
> > Internally these 'unprotected' (or excluded) endpoints implement the
> > HTTP_BASIC scheme themselves:
> > * They treat the Application/Variant like a 'user', by performing a DB
> > lookup of the give application/variantID
> > * If that (Application or Variant) is found, the endpoints compare the
> > given 'password' form the request w/ the "secret" on the  Application or
> > Variant
> >
> > But for these endpoints (sender and device-registration) there is no real
> > user here like "Mr. Jay" or "Push-Admin Foo".
> >
> > The client (registration or sender SDK) performs the auth, by applying the
> > ID and the secret:
> > curl -3 -u "{PushApplicationID}:{MasterSecret}" .... https://server
> >
> >
> >
> > >
> > > >
> > > > I mean: I think there is no need to enable multiple <auth-method> args,
> > > as
> > > > we had the exclusion already working at some point, using their
> > > > KEYCLOAK
> > > > auth-method
> > >
> > > Stian did that inclusion which for me looks correct. An excerpt from KC
> > > documentation:
> > >
> > > "To be able to secure WAR apps deployed on JBoss AS 7.1.1, JBoss EAP 6.x,
> > > or Wildfly, you must install and configure the Keycloak Subsystem. You
> > > then have two options to secure your WARs. You can provide a keycloak
> > > config file in your WAR and change the auth-method to KEYCLOAK within
> > > web.xml. Alternatively, you don't have to crack open your WARs at all
> > > and can apply Keycloak via the Keycloak Subsystem configuration in
> > > standalone.xml. Both methods are described in this section."
> > >
> > > You can also stick with BASIC, but probably you end with implementations
> > > and customizations that don't take any benefit of Keycloak.js.
> > >
> > > Either way I will talk tomorrow with Stian and let's see what we can do.
> > >
> > > >
> > > >
> > > >
> > > > >
> > > > > My initial hope was to be able to simply exclude a few URLs from the
> > > > > overall Keycloak protection, like the above referenced commit:
> > > > >
> > > > >
> > > https://github.com/aerogear/aerogear-unifiedpush-server/blob/2aabd073aaaafa79943ea41d2651f6f0c5e4248e/server/src/main/webapp/WEB-INF/web.xml#L42-L53
> > > > >
> > > > > That would be best as that would mean no API change at all, and our
> > > > > client-registration and sender SDKs could stay as they are.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >>
> > > > >> My two cents is the fact that we should use bearer tokens only,
> > > instead
> > > > >> of mix both auth methods in a single app ? now that we have KC.
> > > > >> And discuss the changes into our clients rather sooner than later.
> > > > >>
> > > > >> But I'm open for whatever you guys think it's the best.
> > > > >>
> > > > >>
> > > > >> >
> > > > >> > -Matthias
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> > >
> > > > >> > > The consequence of this is the basic form being presented when
> > > you try
> > > > >> > > to send push notifications[3]. The problem didn't occur before,
> > > > >> because
> > > > >> > > we were just using Basic authentication[4] instead of Bearer
> > > tokens.
> > > > >> > >
> > > > >> > > Possible solutions:
> > > > >> > >
> > > > >> > > 1- After the removal of Basic authentication, move
> > > _PushApplicationID_
> > > > >> > > and _MasterSecret to http headers like:
> > > > >> > >
> > > > >> > > -H "PushApplicationID: XXXXXX" -H "MasterSecret: 42"
> > > > >> > >
> > > > >> > > IMO it sounds correct and reasonable for me.
> > > > >> > >
> > > > >> > > 2. Create a role specific for the sender like
> > > > >> > > _push-applications_
> > > and
> > > > >> > > dinamically add _PushApplicationID_ and _MasterSecret on
> > > > >> > > Keycloak
> > > > >> where:
> > > > >> > >
> > > > >> > > username: _PushApplicationID_
> > > > >> > > password: _MasterSecret_
> > > > >> > >
> > > > >> > > The implications of this alternative is the fact of have to
> > > > >> > > manage
> > > > >> those
> > > > >> > > credentials on the server side inclusion/exclusion/login
> > > > >> > >
> > > > >> > > 3. Implement another authentication provider specifically for
> > > > >> > > the
> > > > >> sender
> > > > >> > > and Basic authentication[5]
> > > > >> > >
> > > > >> > > 4. Do nothing. The consequences of this alternative is to
> > > implement
> > > > >> > > everything already done by Keycloak.js and manage session tokens
> > > by
> > > > >> hand
> > > > >> > > on the admin-ui.
> > > > >> > >
> > > > >> > > To me the first alternative seems to be more simple, but I
> > > > >> > > really
> > > want
> > > > >> > > your feedback on it, once it affects the whole project.
> > > > >> > >
> > > > >> > > [1] -
> > > > >> > >
> > > > >> > >
> > > > >>
> > > https://github.com/aerogear/aerogear-unifiedpush-server/blob/6c1a0d3fedea8fb6ba918009fd8e9785779c151f/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/sender/PushNotificationSenderEndpoint.java#L56
> > > > >> > >
> > > > >> > > [2] -
> > > > >> > >
> > > > >>
> > > https://github.com/abstractj/aerogear-unifiedpush-server/tree/keycloak.js
> > > > >> > > [3] -
> > > > >> > >
> > > > >> > >
> > > > >>
> > > http://photon.abstractj.org/AeroGear_UnifiedPush_Server_2014-06-17_10-00-09_2014-06-17_10-00-12.jpg
> > > > >> > >
> > > > >> > > [4] -
> > > > >> > >
> > > > >> > >
> > > > >>
> > > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/server/src/main/webapp/WEB-INF/web.xml#L57
> > > > >> > >
> > > > >> > > [5] -
> > > > >> > >
> > > > >>
> > > https://github.com/keycloak/keycloak/tree/master/examples/providers/authentication-properties
> > > > >> > >
> > > > >> > > --
> > > > >> > >
> > > > >> > > abstractj
> > > > >> > > _______________________________________________
> > > > >> > > aerogear-dev mailing list
> > > > >> > > aerogear-dev at lists.jboss.org
> > > > >> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > > >> > >
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> > --
> > > > >> > Matthias Wessendorf
> > > > >> >
> > > > >> > blog: http://matthiaswessendorf.wordpress.com/
> > > > >> > sessions: http://www.slideshare.net/mwessendorf
> > > > >> > twitter: http://twitter.com/mwessendorf
> > > > >>
> > > > >> > _______________________________________________
> > > > >> > aerogear-dev mailing list
> > > > >> > aerogear-dev at lists.jboss.org
> > > > >> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > > >>
> > > > >>
> > > > >> --
> > > > >>
> > > > >> abstractj
> > > > >> _______________________________________________
> > > > >> aerogear-dev mailing list
> > > > >> aerogear-dev at lists.jboss.org
> > > > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > > >>
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Matthias Wessendorf
> > > > >
> > > > > blog: http://matthiaswessendorf.wordpress.com/
> > > > > sessions: http://www.slideshare.net/mwessendorf
> > > > > twitter: http://twitter.com/mwessendorf
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Matthias Wessendorf
> > > >
> > > > blog: http://matthiaswessendorf.wordpress.com/
> > > > sessions: http://www.slideshare.net/mwessendorf
> > > > twitter: http://twitter.com/mwessendorf
> > >
> > > > _______________________________________________
> > > > aerogear-dev mailing list
> > > > aerogear-dev at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > >
> > >
> > > --
> > >
> > > abstractj
> > > _______________________________________________
> > > aerogear-dev mailing list
> > > aerogear-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > >
> >
> >
> >
> > --
> > Matthias Wessendorf
> >
> > blog: http://matthiaswessendorf.wordpress.com/
> > sessions: http://www.slideshare.net/mwessendorf
> > twitter: http://twitter.com/mwessendorf
> 
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> 
> 
> --
> 
> abstractj
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


From bruno at abstractj.org  Thu Jun 19 06:32:43 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Thu, 19 Jun 2014 07:32:43 -0300
Subject: [aerogear-dev] Keycloak integration and UPS Sender
In-Reply-To: <1162554208.29260954.1403166792852.JavaMail.zimbra@redhat.com>
References: <20140617142624.GA23555@abstractj.org>
	<CAAg5f2Ry2KWC1WOp64hoS9udX1OWFFz=ZH0En9qx07gE5vC0Eg@mail.gmail.com>
	<20140617171736.GA32200@abstractj.org>
	<CAAg5f2S1bxQC6k0dLxXAhd7LX8aj0XakUDSX+TLmzUUeqMG36w@mail.gmail.com>
	<CAAg5f2RJXsQMdYNjtdf+30Kx6=1sVREoBVB_5Cyry328wcX9Cw@mail.gmail.com>
	<20140617221225.GA37741@abstractj.org>
	<CAAg5f2SzOp+cik4iuZPxOo-7ABOAnCk_VCLzEQSKWU7bs=gdSg@mail.gmail.com>
	<20140618191255.GB62889@abstractj.org>
	<1162554208.29260954.1403166792852.JavaMail.zimbra@redhat.com>
Message-ID: <20140619103243.GA67632@abstractj.org>

Good morning Stian, thanks for the feedback. I'm totally fine with the
idea. I think we could start on keeping the backwards compatibility first and
implement the other items for UPS beta1.

On 2014-06-19, Stian Thorgersen wrote:
> Here's an idea on how it could be done (disclaimer: this is just a rough idea so take it with a pinch of salt ;)). Some benefits:
>
> * Relatively simple to maintain backwards compatibility
> * Support public clients directly (by using logged in users permissions)
> * One application can access multiple UPS Apps
> * No need to maintain master secret in UPS (and can support multiple methods to auth in the future, for example cert or jwt
> * Manage access through KC - what app/client or user can access what UPS App
>
>
> When creating a new UPS App create:
>
> * A role on unified-push-server - the name should be equal to id of UPS app
>
> Applications should have 3 options to authenticate:
>
> * As the logged in user (for client side applications)
> * As themselves (for server side applications)
> * HTTP Basic
>
> The master secret can also be removed from UPS App as it should no longer be required.
>
> As the logged in user
> ---------------------
> This allows public applications to send push messages on behalf of the logged in user. The steps required are:
>
> 1) Create an application/client in Keycloak
>     * Set to public client
>     * Add scope on UPS App role
> 2) Create user
>     * Add role mapping on UPS App role
> 3) Users logs in with username/password, social, etc through KC login
>    screens
> 4) Application can send push messages with bearer token using users
>    permissions
>
> As themselves
> -------------
> This allows a server-side application to send push messages on behalf of itself. The steps required are:
>
> 1) Create an application/client in Keycloak
>     * Add scope on UPS App role
> 2) Create user
>     * Add role mapping on UPS App role
>     * Set a long unique password (equivalent of master secret)
> 3) Application logs in with username/password (equal to UPS App
>    id/master-secret) using direct grant
> 4) Application can send push messages with bearer token using its own
>    permissions
>
> In the future Keycloak will support additional mechanism for a server-side application to authenticate on behalf of itself (cert, jwts, etc).
>
> HTTP Basic
> ----------
> For backwards compatibility we can add a valve that extracts the UPS App id and master secret from Basic auth. It will then use the direct grant mechanism to obtain a token from Keycloak. The steps required to configure is the same as "As themselves".
>
>
>
> ----- Original Message -----
> > From: "Bruno Oliveira" <bruno at abstractj.org>
> > To: "AeroGear Developer Mailing List" <aerogear-dev at lists.jboss.org>
> > Sent: Wednesday, 18 June, 2014 8:12:55 PM
> > Subject: Re: [aerogear-dev] Keycloak integration and UPS Sender
> >
> > Hi guys, let's see the result of the conversation with KC team and we
> > can revisit this discussion if some changed is required.
> >
> > On 2014-06-18, Matthias Wessendorf wrote:
> > > On Wed, Jun 18, 2014 at 12:12 AM, Bruno Oliveira <bruno at abstractj.org>
> > > wrote:
> > >
> > > > Answers inline.
> > > >
> > > > On 2014-06-17, Matthias Wessendorf wrote:
> > > > > On Tue, Jun 17, 2014 at 8:51 PM, Matthias Wessendorf
> > > > > <matzew at apache.org>
> > > > > wrote:
> > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Tue, Jun 17, 2014 at 7:17 PM, Bruno Oliveira <bruno at abstractj.org>
> > > > > > wrote:
> > > > > >
> > > > > >> Hi Matthias, answer inline.
> > > > > >>
> > > > > >> On 2014-06-17, Matthias Wessendorf wrote:
> > > > > >> > On Tue, Jun 17, 2014 at 4:26 PM, Bruno Oliveira <
> > > > bruno at abstractj.org>
> > > > > >> wrote:
> > > > > >> >
> > > > > >> > > Good morning peeps,
> > > > > >> > >
> > > > > >> > > I have a problem to solve which might affect the Sender and
> > > > > >> > > all the related clients.
> > > > > >> > >
> > > > > >> > > Previously, the UPS Sender was protected by the basic
> > > > authentication
> > > > > >> > > method[1], so anyone in possession of _PushApplicationID_ and
> > > > > >> > > _MasterSecret_ is able to send push messages.
> > > > > >> > >
> > > > > >> > > After the integration with Keycloak now everything under _/rest_
> > > > > >> > > is properly protect by KC which is totally correct. Our sender
> > > > > >> > > is
> > > > > >> under
> > > > > >> > > the same umbrella which means that now Bearer token
> > > > authentication is
> > > > > >> > > required[2] and Basic authentication won't exist anymore.
> > > > > >> > >
> > > > > >> >
> > > > > >> >
> > > > > >> > The device (un)registration endpoints are hit by this as well
> > > > > >> > (/rest/registry/device/*).
> > > > > >>
> > > > > >> Currently Keycloak is protecting our endpoints under /rest/*
> > > > > >>
> > > > > >> >
> > > > > >> > I am wondering if it isn't it possible to keep those URLs
> > > > > >> > protected
> > > > via
> > > > > >> > HTTP_BASIC, or does the keycloak.js usage deny this?
> > > > > >>
> > > > > >> Is not the Keycloak.js usage responsible for this, but the correct
> > > > > >> configuration of the application atm. Please compare:
> > > > > >>
> > > > > >> - master branch:
> > > > > >>
> > > > > >>
> > > > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/server/src/main/webapp/WEB-INF/web.xml#L56
> > > > > >> - keycloak.js branch:
> > > > > >>
> > > > > >>
> > > > https://github.com/aerogear/aerogear-unifiedpush-server/blob/keycloak.js/server/src/main/webapp/WEB-INF/web.xml#L33
> > > > > >>
> > > > > >> Now we're fully using Keycloak bearer tokens instead of Basic.
> > > > > >>
> > > > > >
> > > > > >
> > > > > > Oh, I was following Bill's sample project, where he did not use the
> > > > > > 'KEYCLOAK' auth-method:
> > > > > >
> > > > > >
> > > > https://github.com/keycloak/keycloak/blob/master/project-integrations/aerogear-ups/app/src/main/webapp/WEB-INF/web.xml#L44
> > > > > >
> > > > > > But we had the exclusion working w/ the KEYCLOAK 'auth-method', but
> > > > this
> > > > > > goes back to our initial starts in Dec/Jan.
> > > > > > Here is a rebased commit based on your initial commit:
> > > > > >
> > > > > >
> > > > https://github.com/aerogear/aerogear-unifiedpush-server/blob/2aabd073aaaafa79943ea41d2651f6f0c5e4248e/server/src/main/webapp/WEB-INF/web.xml#L42-L53
> > > > > >
> > > > > >
> > > > > >>
> > > > > >> >
> > > > > >> > On master (plain keycloak; before keycloak.js usage) we are doing
> > > > > >> > an
> > > > > >> > exclude for those URLs:
> > > > > >> >
> > > > > >>
> > > > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/server/src/main/webapp/WEB-INF/web.xml#L46-L52
> > > > > >>
> > > > > >> I tried to include your exclusions, but that didn't work for me.
> > > > > >>
> > > > > >> >
> > > > > >> >
> > > > > >> > IMO if possible, keeping these 'exceptions' (or excludes) under
> > > > > >> HTTP_BASIC
> > > > > >> > would be the simplest solution, as that means none of our client
> > > > SDKs
> > > > > >> > (Android, iOS, Cordova, Node.js Sender, Java-Sendet etc) would
> > > > require
> > > > > >> an
> > > > > >> > update.
> > > > > >>
> > > > > >> I had a chat with Stian and looks like it's possible to support both
> > > > > >> auth methods in a single app, but that would involve changes on
> > > > Keycloak.
> > > > > >> It's just the matter of discuss with KC team.
> > > > > >>
> > > > > >
> > > > > > I don't think we need to enable to <auth-method> settings in our
> > > > web.xml;
> > > > > >
> > > >
> > > > How do you manage login/logout/current logged in user on Angular.js? Is
> > > > possible to do on the server side, but how do you control it on the
> > > > client side?
> > > >
> > >
> > > Sure, to protect the admin-ui and most of the /rest/* endpoints we need the
> > > one <auth-method>KEYCLOAK</auth-method>. No question there. I was trying to
> > > say we do not need multiple 'auth-method' elements on web.xml
> > >
> > > But I think it should be possible to exclude a few URLs, like '/rest/foo'
> > > and '/rest/bar', so that they are completely unprotected in terms of
> > > Keycloak (e.g. via different security-constraint elements):
> > > https://github.com/aerogear/aerogear-unifiedpush-server/blob/2aabd073aaaafa79943ea41d2651f6f0c5e4248e/server/src/main/webapp/WEB-INF/web.xml
> > >
> > > In terms of "current logged in user on Angular.js":
> > > * For the "/rest/sender" and "/rest/device/registration" endpoints, I don't
> > > see a relationship to the user on Angular.js/AdminUI at all.
> > >
> > > Internally these 'unprotected' (or excluded) endpoints implement the
> > > HTTP_BASIC scheme themselves:
> > > * They treat the Application/Variant like a 'user', by performing a DB
> > > lookup of the give application/variantID
> > > * If that (Application or Variant) is found, the endpoints compare the
> > > given 'password' form the request w/ the "secret" on the  Application or
> > > Variant
> > >
> > > But for these endpoints (sender and device-registration) there is no real
> > > user here like "Mr. Jay" or "Push-Admin Foo".
> > >
> > > The client (registration or sender SDK) performs the auth, by applying the
> > > ID and the secret:
> > > curl -3 -u "{PushApplicationID}:{MasterSecret}" .... https://server
> > >
> > >
> > >
> > > >
> > > > >
> > > > > I mean: I think there is no need to enable multiple <auth-method> args,
> > > > as
> > > > > we had the exclusion already working at some point, using their
> > > > > KEYCLOAK
> > > > > auth-method
> > > >
> > > > Stian did that inclusion which for me looks correct. An excerpt from KC
> > > > documentation:
> > > >
> > > > "To be able to secure WAR apps deployed on JBoss AS 7.1.1, JBoss EAP 6.x,
> > > > or Wildfly, you must install and configure the Keycloak Subsystem. You
> > > > then have two options to secure your WARs. You can provide a keycloak
> > > > config file in your WAR and change the auth-method to KEYCLOAK within
> > > > web.xml. Alternatively, you don't have to crack open your WARs at all
> > > > and can apply Keycloak via the Keycloak Subsystem configuration in
> > > > standalone.xml. Both methods are described in this section."
> > > >
> > > > You can also stick with BASIC, but probably you end with implementations
> > > > and customizations that don't take any benefit of Keycloak.js.
> > > >
> > > > Either way I will talk tomorrow with Stian and let's see what we can do.
> > > >
> > > > >
> > > > >
> > > > >
> > > > > >
> > > > > > My initial hope was to be able to simply exclude a few URLs from the
> > > > > > overall Keycloak protection, like the above referenced commit:
> > > > > >
> > > > > >
> > > > https://github.com/aerogear/aerogear-unifiedpush-server/blob/2aabd073aaaafa79943ea41d2651f6f0c5e4248e/server/src/main/webapp/WEB-INF/web.xml#L42-L53
> > > > > >
> > > > > > That would be best as that would mean no API change at all, and our
> > > > > > client-registration and sender SDKs could stay as they are.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >>
> > > > > >> My two cents is the fact that we should use bearer tokens only,
> > > > instead
> > > > > >> of mix both auth methods in a single app ? now that we have KC.
> > > > > >> And discuss the changes into our clients rather sooner than later.
> > > > > >>
> > > > > >> But I'm open for whatever you guys think it's the best.
> > > > > >>
> > > > > >>
> > > > > >> >
> > > > > >> > -Matthias
> > > > > >> >
> > > > > >> >
> > > > > >> >
> > > > > >> >
> > > > > >> >
> > > > > >> > >
> > > > > >> > > The consequence of this is the basic form being presented when
> > > > you try
> > > > > >> > > to send push notifications[3]. The problem didn't occur before,
> > > > > >> because
> > > > > >> > > we were just using Basic authentication[4] instead of Bearer
> > > > tokens.
> > > > > >> > >
> > > > > >> > > Possible solutions:
> > > > > >> > >
> > > > > >> > > 1- After the removal of Basic authentication, move
> > > > _PushApplicationID_
> > > > > >> > > and _MasterSecret to http headers like:
> > > > > >> > >
> > > > > >> > > -H "PushApplicationID: XXXXXX" -H "MasterSecret: 42"
> > > > > >> > >
> > > > > >> > > IMO it sounds correct and reasonable for me.
> > > > > >> > >
> > > > > >> > > 2. Create a role specific for the sender like
> > > > > >> > > _push-applications_
> > > > and
> > > > > >> > > dinamically add _PushApplicationID_ and _MasterSecret on
> > > > > >> > > Keycloak
> > > > > >> where:
> > > > > >> > >
> > > > > >> > > username: _PushApplicationID_
> > > > > >> > > password: _MasterSecret_
> > > > > >> > >
> > > > > >> > > The implications of this alternative is the fact of have to
> > > > > >> > > manage
> > > > > >> those
> > > > > >> > > credentials on the server side inclusion/exclusion/login
> > > > > >> > >
> > > > > >> > > 3. Implement another authentication provider specifically for
> > > > > >> > > the
> > > > > >> sender
> > > > > >> > > and Basic authentication[5]
> > > > > >> > >
> > > > > >> > > 4. Do nothing. The consequences of this alternative is to
> > > > implement
> > > > > >> > > everything already done by Keycloak.js and manage session tokens
> > > > by
> > > > > >> hand
> > > > > >> > > on the admin-ui.
> > > > > >> > >
> > > > > >> > > To me the first alternative seems to be more simple, but I
> > > > > >> > > really
> > > > want
> > > > > >> > > your feedback on it, once it affects the whole project.
> > > > > >> > >
> > > > > >> > > [1] -
> > > > > >> > >
> > > > > >> > >
> > > > > >>
> > > > https://github.com/aerogear/aerogear-unifiedpush-server/blob/6c1a0d3fedea8fb6ba918009fd8e9785779c151f/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/sender/PushNotificationSenderEndpoint.java#L56
> > > > > >> > >
> > > > > >> > > [2] -
> > > > > >> > >
> > > > > >>
> > > > https://github.com/abstractj/aerogear-unifiedpush-server/tree/keycloak.js
> > > > > >> > > [3] -
> > > > > >> > >
> > > > > >> > >
> > > > > >>
> > > > http://photon.abstractj.org/AeroGear_UnifiedPush_Server_2014-06-17_10-00-09_2014-06-17_10-00-12.jpg
> > > > > >> > >
> > > > > >> > > [4] -
> > > > > >> > >
> > > > > >> > >
> > > > > >>
> > > > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/server/src/main/webapp/WEB-INF/web.xml#L57
> > > > > >> > >
> > > > > >> > > [5] -
> > > > > >> > >
> > > > > >>
> > > > https://github.com/keycloak/keycloak/tree/master/examples/providers/authentication-properties
> > > > > >> > >
> > > > > >> > > --
> > > > > >> > >
> > > > > >> > > abstractj
> > > > > >> > > _______________________________________________
> > > > > >> > > aerogear-dev mailing list
> > > > > >> > > aerogear-dev at lists.jboss.org
> > > > > >> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > > > >> > >
> > > > > >> >
> > > > > >> >
> > > > > >> >
> > > > > >> > --
> > > > > >> > Matthias Wessendorf
> > > > > >> >
> > > > > >> > blog: http://matthiaswessendorf.wordpress.com/
> > > > > >> > sessions: http://www.slideshare.net/mwessendorf
> > > > > >> > twitter: http://twitter.com/mwessendorf
> > > > > >>
> > > > > >> > _______________________________________________
> > > > > >> > aerogear-dev mailing list
> > > > > >> > aerogear-dev at lists.jboss.org
> > > > > >> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > > > >>
> > > > > >>
> > > > > >> --
> > > > > >>
> > > > > >> abstractj
> > > > > >> _______________________________________________
> > > > > >> aerogear-dev mailing list
> > > > > >> aerogear-dev at lists.jboss.org
> > > > > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > > > >>
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Matthias Wessendorf
> > > > > >
> > > > > > blog: http://matthiaswessendorf.wordpress.com/
> > > > > > sessions: http://www.slideshare.net/mwessendorf
> > > > > > twitter: http://twitter.com/mwessendorf
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Matthias Wessendorf
> > > > >
> > > > > blog: http://matthiaswessendorf.wordpress.com/
> > > > > sessions: http://www.slideshare.net/mwessendorf
> > > > > twitter: http://twitter.com/mwessendorf
> > > >
> > > > > _______________________________________________
> > > > > aerogear-dev mailing list
> > > > > aerogear-dev at lists.jboss.org
> > > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > >
> > > >
> > > > --
> > > >
> > > > abstractj
> > > > _______________________________________________
> > > > aerogear-dev mailing list
> > > > aerogear-dev at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > >
> > >
> > >
> > >
> > > --
> > > Matthias Wessendorf
> > >
> > > blog: http://matthiaswessendorf.wordpress.com/
> > > sessions: http://www.slideshare.net/mwessendorf
> > > twitter: http://twitter.com/mwessendorf
> >
> > > _______________________________________________
> > > aerogear-dev mailing list
> > > aerogear-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> >
> > --
> >
> > abstractj
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev

--

abstractj

From bruno at abstractj.org  Thu Jun 19 07:00:48 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Thu, 19 Jun 2014 08:00:48 -0300
Subject: [aerogear-dev] Keycloak integration and UPS Sender
In-Reply-To: <20140619103243.GA67632@abstractj.org>
References: <20140617142624.GA23555@abstractj.org>
	<CAAg5f2Ry2KWC1WOp64hoS9udX1OWFFz=ZH0En9qx07gE5vC0Eg@mail.gmail.com>
	<20140617171736.GA32200@abstractj.org>
	<CAAg5f2S1bxQC6k0dLxXAhd7LX8aj0XakUDSX+TLmzUUeqMG36w@mail.gmail.com>
	<CAAg5f2RJXsQMdYNjtdf+30Kx6=1sVREoBVB_5Cyry328wcX9Cw@mail.gmail.com>
	<20140617221225.GA37741@abstractj.org>
	<CAAg5f2SzOp+cik4iuZPxOo-7ABOAnCk_VCLzEQSKWU7bs=gdSg@mail.gmail.com>
	<20140618191255.GB62889@abstractj.org>
	<1162554208.29260954.1403166792852.JavaMail.zimbra@redhat.com>
	<20140619103243.GA67632@abstractj.org>
Message-ID: <20140619110048.GB67632@abstractj.org>

Ahoy, the following Jira was created:
https://issues.jboss.org/browse/AGPUSH-736. I will be working on it and
ask for help as needed to KC team.

On 2014-06-19, Bruno Oliveira wrote:
> Good morning Stian, thanks for the feedback. I'm totally fine with the
> idea. I think we could start on keeping the backwards compatibility first and
> implement the other items for UPS beta1.
>
> On 2014-06-19, Stian Thorgersen wrote:
> > Here's an idea on how it could be done (disclaimer: this is just a rough idea so take it with a pinch of salt ;)). Some benefits:
> >
> > * Relatively simple to maintain backwards compatibility
> > * Support public clients directly (by using logged in users permissions)
> > * One application can access multiple UPS Apps
> > * No need to maintain master secret in UPS (and can support multiple methods to auth in the future, for example cert or jwt
> > * Manage access through KC - what app/client or user can access what UPS App
> >
> >
> > When creating a new UPS App create:
> >
> > * A role on unified-push-server - the name should be equal to id of UPS app
> >
> > Applications should have 3 options to authenticate:
> >
> > * As the logged in user (for client side applications)
> > * As themselves (for server side applications)
> > * HTTP Basic
> >
> > The master secret can also be removed from UPS App as it should no longer be required.
> >
> > As the logged in user
> > ---------------------
> > This allows public applications to send push messages on behalf of the logged in user. The steps required are:
> >
> > 1) Create an application/client in Keycloak
> >     * Set to public client
> >     * Add scope on UPS App role
> > 2) Create user
> >     * Add role mapping on UPS App role
> > 3) Users logs in with username/password, social, etc through KC login
> >    screens
> > 4) Application can send push messages with bearer token using users
> >    permissions
> >
> > As themselves
> > -------------
> > This allows a server-side application to send push messages on behalf of itself. The steps required are:
> >
> > 1) Create an application/client in Keycloak
> >     * Add scope on UPS App role
> > 2) Create user
> >     * Add role mapping on UPS App role
> >     * Set a long unique password (equivalent of master secret)
> > 3) Application logs in with username/password (equal to UPS App
> >    id/master-secret) using direct grant
> > 4) Application can send push messages with bearer token using its own
> >    permissions
> >
> > In the future Keycloak will support additional mechanism for a server-side application to authenticate on behalf of itself (cert, jwts, etc).
> >
> > HTTP Basic
> > ----------
> > For backwards compatibility we can add a valve that extracts the UPS App id and master secret from Basic auth. It will then use the direct grant mechanism to obtain a token from Keycloak. The steps required to configure is the same as "As themselves".
> >
> >
> >
> > ----- Original Message -----
> > > From: "Bruno Oliveira" <bruno at abstractj.org>
> > > To: "AeroGear Developer Mailing List" <aerogear-dev at lists.jboss.org>
> > > Sent: Wednesday, 18 June, 2014 8:12:55 PM
> > > Subject: Re: [aerogear-dev] Keycloak integration and UPS Sender
> > >
> > > Hi guys, let's see the result of the conversation with KC team and we
> > > can revisit this discussion if some changed is required.
> > >
> > > On 2014-06-18, Matthias Wessendorf wrote:
> > > > On Wed, Jun 18, 2014 at 12:12 AM, Bruno Oliveira <bruno at abstractj.org>
> > > > wrote:
> > > >
> > > > > Answers inline.
> > > > >
> > > > > On 2014-06-17, Matthias Wessendorf wrote:
> > > > > > On Tue, Jun 17, 2014 at 8:51 PM, Matthias Wessendorf
> > > > > > <matzew at apache.org>
> > > > > > wrote:
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Tue, Jun 17, 2014 at 7:17 PM, Bruno Oliveira <bruno at abstractj.org>
> > > > > > > wrote:
> > > > > > >
> > > > > > >> Hi Matthias, answer inline.
> > > > > > >>
> > > > > > >> On 2014-06-17, Matthias Wessendorf wrote:
> > > > > > >> > On Tue, Jun 17, 2014 at 4:26 PM, Bruno Oliveira <
> > > > > bruno at abstractj.org>
> > > > > > >> wrote:
> > > > > > >> >
> > > > > > >> > > Good morning peeps,
> > > > > > >> > >
> > > > > > >> > > I have a problem to solve which might affect the Sender and
> > > > > > >> > > all the related clients.
> > > > > > >> > >
> > > > > > >> > > Previously, the UPS Sender was protected by the basic
> > > > > authentication
> > > > > > >> > > method[1], so anyone in possession of _PushApplicationID_ and
> > > > > > >> > > _MasterSecret_ is able to send push messages.
> > > > > > >> > >
> > > > > > >> > > After the integration with Keycloak now everything under _/rest_
> > > > > > >> > > is properly protect by KC which is totally correct. Our sender
> > > > > > >> > > is
> > > > > > >> under
> > > > > > >> > > the same umbrella which means that now Bearer token
> > > > > authentication is
> > > > > > >> > > required[2] and Basic authentication won't exist anymore.
> > > > > > >> > >
> > > > > > >> >
> > > > > > >> >
> > > > > > >> > The device (un)registration endpoints are hit by this as well
> > > > > > >> > (/rest/registry/device/*).
> > > > > > >>
> > > > > > >> Currently Keycloak is protecting our endpoints under /rest/*
> > > > > > >>
> > > > > > >> >
> > > > > > >> > I am wondering if it isn't it possible to keep those URLs
> > > > > > >> > protected
> > > > > via
> > > > > > >> > HTTP_BASIC, or does the keycloak.js usage deny this?
> > > > > > >>
> > > > > > >> Is not the Keycloak.js usage responsible for this, but the correct
> > > > > > >> configuration of the application atm. Please compare:
> > > > > > >>
> > > > > > >> - master branch:
> > > > > > >>
> > > > > > >>
> > > > > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/server/src/main/webapp/WEB-INF/web.xml#L56
> > > > > > >> - keycloak.js branch:
> > > > > > >>
> > > > > > >>
> > > > > https://github.com/aerogear/aerogear-unifiedpush-server/blob/keycloak.js/server/src/main/webapp/WEB-INF/web.xml#L33
> > > > > > >>
> > > > > > >> Now we're fully using Keycloak bearer tokens instead of Basic.
> > > > > > >>
> > > > > > >
> > > > > > >
> > > > > > > Oh, I was following Bill's sample project, where he did not use the
> > > > > > > 'KEYCLOAK' auth-method:
> > > > > > >
> > > > > > >
> > > > > https://github.com/keycloak/keycloak/blob/master/project-integrations/aerogear-ups/app/src/main/webapp/WEB-INF/web.xml#L44
> > > > > > >
> > > > > > > But we had the exclusion working w/ the KEYCLOAK 'auth-method', but
> > > > > this
> > > > > > > goes back to our initial starts in Dec/Jan.
> > > > > > > Here is a rebased commit based on your initial commit:
> > > > > > >
> > > > > > >
> > > > > https://github.com/aerogear/aerogear-unifiedpush-server/blob/2aabd073aaaafa79943ea41d2651f6f0c5e4248e/server/src/main/webapp/WEB-INF/web.xml#L42-L53
> > > > > > >
> > > > > > >
> > > > > > >>
> > > > > > >> >
> > > > > > >> > On master (plain keycloak; before keycloak.js usage) we are doing
> > > > > > >> > an
> > > > > > >> > exclude for those URLs:
> > > > > > >> >
> > > > > > >>
> > > > > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/server/src/main/webapp/WEB-INF/web.xml#L46-L52
> > > > > > >>
> > > > > > >> I tried to include your exclusions, but that didn't work for me.
> > > > > > >>
> > > > > > >> >
> > > > > > >> >
> > > > > > >> > IMO if possible, keeping these 'exceptions' (or excludes) under
> > > > > > >> HTTP_BASIC
> > > > > > >> > would be the simplest solution, as that means none of our client
> > > > > SDKs
> > > > > > >> > (Android, iOS, Cordova, Node.js Sender, Java-Sendet etc) would
> > > > > require
> > > > > > >> an
> > > > > > >> > update.
> > > > > > >>
> > > > > > >> I had a chat with Stian and looks like it's possible to support both
> > > > > > >> auth methods in a single app, but that would involve changes on
> > > > > Keycloak.
> > > > > > >> It's just the matter of discuss with KC team.
> > > > > > >>
> > > > > > >
> > > > > > > I don't think we need to enable to <auth-method> settings in our
> > > > > web.xml;
> > > > > > >
> > > > >
> > > > > How do you manage login/logout/current logged in user on Angular.js? Is
> > > > > possible to do on the server side, but how do you control it on the
> > > > > client side?
> > > > >
> > > >
> > > > Sure, to protect the admin-ui and most of the /rest/* endpoints we need the
> > > > one <auth-method>KEYCLOAK</auth-method>. No question there. I was trying to
> > > > say we do not need multiple 'auth-method' elements on web.xml
> > > >
> > > > But I think it should be possible to exclude a few URLs, like '/rest/foo'
> > > > and '/rest/bar', so that they are completely unprotected in terms of
> > > > Keycloak (e.g. via different security-constraint elements):
> > > > https://github.com/aerogear/aerogear-unifiedpush-server/blob/2aabd073aaaafa79943ea41d2651f6f0c5e4248e/server/src/main/webapp/WEB-INF/web.xml
> > > >
> > > > In terms of "current logged in user on Angular.js":
> > > > * For the "/rest/sender" and "/rest/device/registration" endpoints, I don't
> > > > see a relationship to the user on Angular.js/AdminUI at all.
> > > >
> > > > Internally these 'unprotected' (or excluded) endpoints implement the
> > > > HTTP_BASIC scheme themselves:
> > > > * They treat the Application/Variant like a 'user', by performing a DB
> > > > lookup of the give application/variantID
> > > > * If that (Application or Variant) is found, the endpoints compare the
> > > > given 'password' form the request w/ the "secret" on the  Application or
> > > > Variant
> > > >
> > > > But for these endpoints (sender and device-registration) there is no real
> > > > user here like "Mr. Jay" or "Push-Admin Foo".
> > > >
> > > > The client (registration or sender SDK) performs the auth, by applying the
> > > > ID and the secret:
> > > > curl -3 -u "{PushApplicationID}:{MasterSecret}" .... https://server
> > > >
> > > >
> > > >
> > > > >
> > > > > >
> > > > > > I mean: I think there is no need to enable multiple <auth-method> args,
> > > > > as
> > > > > > we had the exclusion already working at some point, using their
> > > > > > KEYCLOAK
> > > > > > auth-method
> > > > >
> > > > > Stian did that inclusion which for me looks correct. An excerpt from KC
> > > > > documentation:
> > > > >
> > > > > "To be able to secure WAR apps deployed on JBoss AS 7.1.1, JBoss EAP 6.x,
> > > > > or Wildfly, you must install and configure the Keycloak Subsystem. You
> > > > > then have two options to secure your WARs. You can provide a keycloak
> > > > > config file in your WAR and change the auth-method to KEYCLOAK within
> > > > > web.xml. Alternatively, you don't have to crack open your WARs at all
> > > > > and can apply Keycloak via the Keycloak Subsystem configuration in
> > > > > standalone.xml. Both methods are described in this section."
> > > > >
> > > > > You can also stick with BASIC, but probably you end with implementations
> > > > > and customizations that don't take any benefit of Keycloak.js.
> > > > >
> > > > > Either way I will talk tomorrow with Stian and let's see what we can do.
> > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > My initial hope was to be able to simply exclude a few URLs from the
> > > > > > > overall Keycloak protection, like the above referenced commit:
> > > > > > >
> > > > > > >
> > > > > https://github.com/aerogear/aerogear-unifiedpush-server/blob/2aabd073aaaafa79943ea41d2651f6f0c5e4248e/server/src/main/webapp/WEB-INF/web.xml#L42-L53
> > > > > > >
> > > > > > > That would be best as that would mean no API change at all, and our
> > > > > > > client-registration and sender SDKs could stay as they are.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >>
> > > > > > >> My two cents is the fact that we should use bearer tokens only,
> > > > > instead
> > > > > > >> of mix both auth methods in a single app ? now that we have KC.
> > > > > > >> And discuss the changes into our clients rather sooner than later.
> > > > > > >>
> > > > > > >> But I'm open for whatever you guys think it's the best.
> > > > > > >>
> > > > > > >>
> > > > > > >> >
> > > > > > >> > -Matthias
> > > > > > >> >
> > > > > > >> >
> > > > > > >> >
> > > > > > >> >
> > > > > > >> >
> > > > > > >> > >
> > > > > > >> > > The consequence of this is the basic form being presented when
> > > > > you try
> > > > > > >> > > to send push notifications[3]. The problem didn't occur before,
> > > > > > >> because
> > > > > > >> > > we were just using Basic authentication[4] instead of Bearer
> > > > > tokens.
> > > > > > >> > >
> > > > > > >> > > Possible solutions:
> > > > > > >> > >
> > > > > > >> > > 1- After the removal of Basic authentication, move
> > > > > _PushApplicationID_
> > > > > > >> > > and _MasterSecret to http headers like:
> > > > > > >> > >
> > > > > > >> > > -H "PushApplicationID: XXXXXX" -H "MasterSecret: 42"
> > > > > > >> > >
> > > > > > >> > > IMO it sounds correct and reasonable for me.
> > > > > > >> > >
> > > > > > >> > > 2. Create a role specific for the sender like
> > > > > > >> > > _push-applications_
> > > > > and
> > > > > > >> > > dinamically add _PushApplicationID_ and _MasterSecret on
> > > > > > >> > > Keycloak
> > > > > > >> where:
> > > > > > >> > >
> > > > > > >> > > username: _PushApplicationID_
> > > > > > >> > > password: _MasterSecret_
> > > > > > >> > >
> > > > > > >> > > The implications of this alternative is the fact of have to
> > > > > > >> > > manage
> > > > > > >> those
> > > > > > >> > > credentials on the server side inclusion/exclusion/login
> > > > > > >> > >
> > > > > > >> > > 3. Implement another authentication provider specifically for
> > > > > > >> > > the
> > > > > > >> sender
> > > > > > >> > > and Basic authentication[5]
> > > > > > >> > >
> > > > > > >> > > 4. Do nothing. The consequences of this alternative is to
> > > > > implement
> > > > > > >> > > everything already done by Keycloak.js and manage session tokens
> > > > > by
> > > > > > >> hand
> > > > > > >> > > on the admin-ui.
> > > > > > >> > >
> > > > > > >> > > To me the first alternative seems to be more simple, but I
> > > > > > >> > > really
> > > > > want
> > > > > > >> > > your feedback on it, once it affects the whole project.
> > > > > > >> > >
> > > > > > >> > > [1] -
> > > > > > >> > >
> > > > > > >> > >
> > > > > > >>
> > > > > https://github.com/aerogear/aerogear-unifiedpush-server/blob/6c1a0d3fedea8fb6ba918009fd8e9785779c151f/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/sender/PushNotificationSenderEndpoint.java#L56
> > > > > > >> > >
> > > > > > >> > > [2] -
> > > > > > >> > >
> > > > > > >>
> > > > > https://github.com/abstractj/aerogear-unifiedpush-server/tree/keycloak.js
> > > > > > >> > > [3] -
> > > > > > >> > >
> > > > > > >> > >
> > > > > > >>
> > > > > http://photon.abstractj.org/AeroGear_UnifiedPush_Server_2014-06-17_10-00-09_2014-06-17_10-00-12.jpg
> > > > > > >> > >
> > > > > > >> > > [4] -
> > > > > > >> > >
> > > > > > >> > >
> > > > > > >>
> > > > > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/server/src/main/webapp/WEB-INF/web.xml#L57
> > > > > > >> > >
> > > > > > >> > > [5] -
> > > > > > >> > >
> > > > > > >>
> > > > > https://github.com/keycloak/keycloak/tree/master/examples/providers/authentication-properties
> > > > > > >> > >
> > > > > > >> > > --
> > > > > > >> > >
> > > > > > >> > > abstractj
> > > > > > >> > > _______________________________________________
> > > > > > >> > > aerogear-dev mailing list
> > > > > > >> > > aerogear-dev at lists.jboss.org
> > > > > > >> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > > > > >> > >
> > > > > > >> >
> > > > > > >> >
> > > > > > >> >
> > > > > > >> > --
> > > > > > >> > Matthias Wessendorf
> > > > > > >> >
> > > > > > >> > blog: http://matthiaswessendorf.wordpress.com/
> > > > > > >> > sessions: http://www.slideshare.net/mwessendorf
> > > > > > >> > twitter: http://twitter.com/mwessendorf
> > > > > > >>
> > > > > > >> > _______________________________________________
> > > > > > >> > aerogear-dev mailing list
> > > > > > >> > aerogear-dev at lists.jboss.org
> > > > > > >> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > > > > >>
> > > > > > >>
> > > > > > >> --
> > > > > > >>
> > > > > > >> abstractj
> > > > > > >> _______________________________________________
> > > > > > >> aerogear-dev mailing list
> > > > > > >> aerogear-dev at lists.jboss.org
> > > > > > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > > > > >>
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Matthias Wessendorf
> > > > > > >
> > > > > > > blog: http://matthiaswessendorf.wordpress.com/
> > > > > > > sessions: http://www.slideshare.net/mwessendorf
> > > > > > > twitter: http://twitter.com/mwessendorf
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Matthias Wessendorf
> > > > > >
> > > > > > blog: http://matthiaswessendorf.wordpress.com/
> > > > > > sessions: http://www.slideshare.net/mwessendorf
> > > > > > twitter: http://twitter.com/mwessendorf
> > > > >
> > > > > > _______________________________________________
> > > > > > aerogear-dev mailing list
> > > > > > aerogear-dev at lists.jboss.org
> > > > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > > >
> > > > >
> > > > > --
> > > > >
> > > > > abstractj
> > > > > _______________________________________________
> > > > > aerogear-dev mailing list
> > > > > aerogear-dev at lists.jboss.org
> > > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Matthias Wessendorf
> > > >
> > > > blog: http://matthiaswessendorf.wordpress.com/
> > > > sessions: http://www.slideshare.net/mwessendorf
> > > > twitter: http://twitter.com/mwessendorf
> > >
> > > > _______________________________________________
> > > > aerogear-dev mailing list
> > > > aerogear-dev at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > >
> > >
> > > --
> > >
> > > abstractj
> > > _______________________________________________
> > > aerogear-dev mailing list
> > > aerogear-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
> --
>
> abstractj

--

abstractj

From matzew at apache.org  Thu Jun 19 08:47:07 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Thu, 19 Jun 2014 14:47:07 +0200
Subject: [aerogear-dev] Keycloak integration and UPS Sender
In-Reply-To: <1162554208.29260954.1403166792852.JavaMail.zimbra@redhat.com>
References: <20140617142624.GA23555@abstractj.org>
	<CAAg5f2Ry2KWC1WOp64hoS9udX1OWFFz=ZH0En9qx07gE5vC0Eg@mail.gmail.com>
	<20140617171736.GA32200@abstractj.org>
	<CAAg5f2S1bxQC6k0dLxXAhd7LX8aj0XakUDSX+TLmzUUeqMG36w@mail.gmail.com>
	<CAAg5f2RJXsQMdYNjtdf+30Kx6=1sVREoBVB_5Cyry328wcX9Cw@mail.gmail.com>
	<20140617221225.GA37741@abstractj.org>
	<CAAg5f2SzOp+cik4iuZPxOo-7ABOAnCk_VCLzEQSKWU7bs=gdSg@mail.gmail.com>
	<20140618191255.GB62889@abstractj.org>
	<1162554208.29260954.1403166792852.JavaMail.zimbra@redhat.com>
Message-ID: <CAAg5f2QMx_5KdO-sRcBqPxWz0Ekzj5wumOYm001uvZyojAfETA@mail.gmail.com>

Hi,

a few questions:
* for device registration will it be possible to perform the actual
registration by using the variantID and its secret? (Please note that there
is no "user" on the mobile device. Currently, for the registration, we
perform http_basic authentification against a variant (via varianID
/secret))


* isn't it possible to exclude a few URIs (e.g. security-constraint
element(s) in web.xml) from Keycloak? That way 'sender' (and 'device
registration') cloud stay as they are: using their custom http_basic impl


I am NOT against changes, but I am a bit worried that we add new and
instable code for the sender/registration endpoints (and our mobile clients
and our senders), just a few weeks before we will have our 1.0.0 release.

Or are my concerns are invalid and the Android, Cordova, iOS SDKs, as well
as our senders (java and node), will work just fine, without major changes

Thanks,
Matthias

On Thursday, June 19, 2014, Stian Thorgersen <stian at redhat.com> wrote:

> Here's an idea on how it could be done (disclaimer: this is just a rough
> idea so take it with a pinch of salt ;)). Some benefits:
>
> * Relatively simple to maintain backwards compatibility
> * Support public clients directly (by using logged in users permissions)
> * One application can access multiple UPS Apps
> * No need to maintain master secret in UPS (and can support multiple
> methods to auth in the future, for example cert or jwt
> * Manage access through KC - what app/client or user can access what UPS
> App
>
>
> When creating a new UPS App create:
>
> * A role on unified-push-server - the name should be equal to id of UPS app
>
> Applications should have 3 options to authenticate:
>
> * As the logged in user (for client side applications)
> * As themselves (for server side applications)
> * HTTP Basic
>
> The master secret can also be removed from UPS App as it should no longer
> be required.
>
> As the logged in user
> ---------------------
> This allows public applications to send push messages on behalf of the
> logged in user. The steps required are:
>
> 1) Create an application/client in Keycloak
>     * Set to public client
>     * Add scope on UPS App role
> 2) Create user
>     * Add role mapping on UPS App role
> 3) Users logs in with username/password, social, etc through KC login
>    screens
> 4) Application can send push messages with bearer token using users
>    permissions
>
> As themselves
> -------------
> This allows a server-side application to send push messages on behalf of
> itself. The steps required are:
>
> 1) Create an application/client in Keycloak
>     * Add scope on UPS App role
> 2) Create user
>     * Add role mapping on UPS App role
>     * Set a long unique password (equivalent of master secret)
> 3) Application logs in with username/password (equal to UPS App
>    id/master-secret) using direct grant
> 4) Application can send push messages with bearer token using its own
>    permissions
>
> In the future Keycloak will support additional mechanism for a server-side
> application to authenticate on behalf of itself (cert, jwts, etc).
>
> HTTP Basic
> ----------
> For backwards compatibility we can add a valve that extracts the UPS App
> id and master secret from Basic auth. It will then use the direct grant
> mechanism to obtain a token from Keycloak. The steps required to configure
> is the same as "As themselves".
>
>
>
> ----- Original Message -----
> > From: "Bruno Oliveira" <bruno at abstractj.org <javascript:;>>
> > To: "AeroGear Developer Mailing List" <aerogear-dev at lists.jboss.org
> <javascript:;>>
> > Sent: Wednesday, 18 June, 2014 8:12:55 PM
> > Subject: Re: [aerogear-dev] Keycloak integration and UPS Sender
> >
> > Hi guys, let's see the result of the conversation with KC team and we
> > can revisit this discussion if some changed is required.
> >
> > On 2014-06-18, Matthias Wessendorf wrote:
> > > On Wed, Jun 18, 2014 at 12:12 AM, Bruno Oliveira <bruno at abstractj.org
> <javascript:;>>
> > > wrote:
> > >
> > > > Answers inline.
> > > >
> > > > On 2014-06-17, Matthias Wessendorf wrote:
> > > > > On Tue, Jun 17, 2014 at 8:51 PM, Matthias Wessendorf
> > > > > <matzew at apache.org <javascript:;>>
> > > > > wrote:
> > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Tue, Jun 17, 2014 at 7:17 PM, Bruno Oliveira <
> bruno at abstractj.org <javascript:;>>
> > > > > > wrote:
> > > > > >
> > > > > >> Hi Matthias, answer inline.
> > > > > >>
> > > > > >> On 2014-06-17, Matthias Wessendorf wrote:
> > > > > >> > On Tue, Jun 17, 2014 at 4:26 PM, Bruno Oliveira <
> > > > bruno at abstractj.org <javascript:;>>
> > > > > >> wrote:
> > > > > >> >
> > > > > >> > > Good morning peeps,
> > > > > >> > >
> > > > > >> > > I have a problem to solve which might affect the Sender and
> > > > > >> > > all the related clients.
> > > > > >> > >
> > > > > >> > > Previously, the UPS Sender was protected by the basic
> > > > authentication
> > > > > >> > > method[1], so anyone in possession of _PushApplicationID_
> and
> > > > > >> > > _MasterSecret_ is able to send push messages.
> > > > > >> > >
> > > > > >> > > After the integration with Keycloak now everything under
> _/rest_
> > > > > >> > > is properly protect by KC which is totally correct. Our
> sender
> > > > > >> > > is
> > > > > >> under
> > > > > >> > > the same umbrella which means that now Bearer token
> > > > authentication is
> > > > > >> > > required[2] and Basic authentication won't exist anymore.
> > > > > >> > >
> > > > > >> >
> > > > > >> >
> > > > > >> > The device (un)registration endpoints are hit by this as well
> > > > > >> > (/rest/registry/device/*).
> > > > > >>
> > > > > >> Currently Keycloak is protecting our endpoints under /rest/*
> > > > > >>
> > > > > >> >
> > > > > >> > I am wondering if it isn't it possible to keep those URLs
> > > > > >> > protected
> > > > via
> > > > > >> > HTTP_BASIC, or does the keycloak.js usage deny this?
> > > > > >>
> > > > > >> Is not the Keycloak.js usage responsible for this, but the
> correct
> > > > > >> configuration of the application atm. Please compare:
> > > > > >>
> > > > > >> - master branch:
> > > > > >>
> > > > > >>
> > > >
> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/server/src/main/webapp/WEB-INF/web.xml#L56
> > > > > >> - keycloak.js branch:
> > > > > >>
> > > > > >>
> > > >
> https://github.com/aerogear/aerogear-unifiedpush-server/blob/keycloak.js/server/src/main/webapp/WEB-INF/web.xml#L33
> > > > > >>
> > > > > >> Now we're fully using Keycloak bearer tokens instead of Basic.
> > > > > >>
> > > > > >
> > > > > >
> > > > > > Oh, I was following Bill's sample project, where he did not use
> the
> > > > > > 'KEYCLOAK' auth-method:
> > > > > >
> > > > > >
> > > >
> https://github.com/keycloak/keycloak/blob/master/project-integrations/aerogear-ups/app/src/main/webapp/WEB-INF/web.xml#L44
> > > > > >
> > > > > > But we had the exclusion working w/ the KEYCLOAK 'auth-method',
> but
> > > > this
> > > > > > goes back to our initial starts in Dec/Jan.
> > > > > > Here is a rebased commit based on your initial commit:
> > > > > >
> > > > > >
> > > >
> https://github.com/aerogear/aerogear-unifiedpush-server/blob/2aabd073aaaafa79943ea41d2651f6f0c5e4248e/server/src/main/webapp/WEB-INF/web.xml#L42-L53
> > > > > >
> > > > > >
> > > > > >>
> > > > > >> >
> > > > > >> > On master (plain keycloak; before keycloak.js usage) we are
> doing
> > > > > >> > an
> > > > > >> > exclude for those URLs:
> > > > > >> >
> > > > > >>
> > > >
> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/server/src/main/webapp/WEB-INF/web.xml#L46-L52
> > > > > >>
> > > > > >> I tried to include your exclusions, but that didn't work for me.
> > > > > >>
> > > > > >> >
> > > > > >> >
> > > > > >> > IMO if possible, keeping these 'exceptions' (or excludes)
> under
> > > > > >> HTTP_BASIC
> > > > > >> > would be the simplest solution, as that means none of our
> client
> > > > SDKs
> > > > > >> > (Android, iOS, Cordova, Node.js Sender, Java-Sendet etc) would
> > > > require
> > > > > >> an
> > > > > >> > update.
> > > > > >>
> > > > > >> I had a chat with Stian and looks like it's possible to support
> both
> > > > > >> auth methods in a single app, but that would involve changes on
> > > > Keycloak.
> > > > > >> It's just the matter of discuss with KC team.
> > > > > >>
> > > > > >
> > > > > > I don't think we need to enable to <auth-method> settings in our
> > > > web.xml;
> > > > > >
> > > >
> > > > How do you manage login/logout/current logged in user on Angular.js?
> Is
> > > > possible to do on the server side, but how do you control it on the
> > > > client side?
> > > >
> > >
> > > Sure, to protect the admin-ui and most of the /rest/* endpoints we
> need the
> > > one <auth-method>KEYCLOAK</auth-method>. No question there. I was
> trying to
> > > say we do not need multiple 'auth-method' elements on web.xml
> > >
> > > But I think it should be possible to exclude a few URLs, like
> '/rest/foo'
> > > and '/rest/bar', so that they are completely unprotected in terms of
> > > Keycloak (e.g. via different security-constraint elements):
> > >
> https://github.com/aerogear/aerogear-unifiedpush-server/blob/2aabd073aaaafa79943ea41d2651f6f0c5e4248e/server/src/main/webapp/WEB-INF/web.xml
> > >
> > > In terms of "current logged in user on Angular.js":
> > > * For the "/rest/sender" and "/rest/device/registration" endpoints, I
> don't
> > > see a relationship to the user on Angular.js/AdminUI at all.
> > >
> > > Internally these 'unprotected' (or excluded) endpoints implement the
> > > HTTP_BASIC scheme themselves:
> > > * They treat the Application/Variant like a 'user', by performing a DB
> > > lookup of the give application/variantID
> > > * If that (Application or Variant) is found, the endpoints compare the
> > > given 'password' form the request w/ the "secret" on the  Application
> or
> > > Variant
> > >
> > > But for these endpoints (sender and device-registration) there is no
> real
> > > user here like "Mr. Jay" or "Push-Admin Foo".
> > >
> > > The client (registration or sender SDK) performs the auth, by applying
> the
> > > ID and the secret:
> > > curl -3 -u "{PushApplicationID}:{MasterSecret}" .... https://server
> > >
> > >
> > >
> > > >
> > > > >
> > > > > I mean: I think there is no need to enable multiple <auth-method>
> args,
> > > > as
> > > > > we had the exclusion already working at some point, using their
> > > > > KEYCLOAK
> > > > > auth-method
> > > >
> > > > Stian did that inclusion which for me looks correct. An excerpt from
> KC
> > > > documentation:
> > > >
> > > > "To be able to secure WAR apps deployed on JBoss AS 7.1.1, JBoss EAP
> 6.x,
> > > > or Wildfly, you must install and configure the Keycloak Subsystem.
> You
> > > > then have two options to secure your WARs. You can provide a keycloak
> > > > config file in your WAR and change the auth-method to KEYCLOAK within
> > > > web.xml. Alternatively, you don't have to crack open your WARs at all
> > > > and can apply Keycloak via the Keycloak Subsystem configuration in
> > > > standalone.xml. Both methods are described in this section."
> > > >
> > > > You can also stick with BASIC, but probably you end with
> implementations
> > > > and customizations that don't take any benefit of Keycloak.js.
> > > >
> > > > Either way I will talk tomorrow with Stian and let's see what we can
> do.
> > > >
> > > > >
> > > > >
> > > > >
> > > > > >
> > > > > > My initial hope was to be able to simply exclude a few URLs from
> the
> > > > > > overall Keycloak protection, like the above referenced commit:
> > > > > >
> > > > > >
> > > >
> https://github.com/aerogear/aerogear-unifiedpush-server/blob/2aabd073aaaafa79943ea41d2651f6f0c5e4248e/server/src/main/webapp/WEB-INF/web.xml#L42-L53
> > > > > >
> > > > > > That would be best as that would mean no API change at all, and
> our
> > > > > > client-registration and sender SDKs could stay as they are.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >>
> > > > > >> My two cents is the fact that we should use bearer tokens only,
> > > > instead
> > > > > >> of mix both auth methods in a single app ? now that we have KC.
> > > > > >> And discuss the changes into our clients rather sooner than
> later.
> > > > > >>
> > > > > >> But I'm open for whatever you guys think it's the best.
> > > > > >>
> > > > > >>
> > > > > >> >
> > > > > >> > -Matthias
> > > > > >> >
> > > > > >> >
> > > > > >> >
> > > > > >> >
> > > > > >> >
> > > > > >> > >
> > > > > >> > > The consequence of this is the basic form being presented
> when
> > > > you try
> > > > > >> > > to send push notifications[3]. The problem didn't occur
> before,
> > > > > >> because
> > > > > >> > > we were just using Basic authentication[4] instead of Bearer
> > > > tokens.
> > > > > >> > >
> > > > > >> > > Possible solutions:
> > > > > >> > >
> > > > > >> > > 1- After the removal of Basic authentication, move
> > > > _PushApplicationID_
> > > > > >> > > and _MasterSecret to http headers like:
> > > > > >> > >
> > > > > >> > > -H "PushApplicationID: XXXXXX" -H "MasterSecret: 42"
> > > > > >> > >
> > > > > >> > > IMO it sounds correct and reasonable for me.
> > > > > >> > >
> > > > > >> > > 2. Create a role specific for the sender like
> > > > > >> > > _push-applications_
> > > > and
> > > > > >> > > dinamically add _PushApplicationID_ and _MasterSecret on
> > > > > >> > > Keycloak
> > > > > >> where:
> > > > > >> > >
> > > > > >> > > username: _PushApplicationID_
> > > > > >> > > password: _MasterSecret_
> > > > > >> > >
> > > > > >> > > The implications of this alternative is the fact of have to
> > > > > >> > > manage
> > > > > >> those
> > > > > >> > > credentials on the server side inclusion/exclusion/login
> > > > > >> > >
> > > > > >> > > 3. Implement another authentication provider specifically
> for
> > > > > >> > > the
> > > > > >> sender
> > > > > >> > > and Basic authentication[5]
> > > > > >> > >
> > > > > >> > > 4. Do nothing. The consequences of this alternative is to
> > > > implement
> > > > > >> > > everything already done by Keycloak.js and manage session
> tokens
> > > > by
> > > > > >> hand
> > > > > >> > > on the admin-ui.
> > > > > >> > >
> > > > > >> > > To me the first alternative seems to be more simple, but I
> > > > > >> > > really
> > > > want
> > > > > >> > > your feedback on it, once it affects the whole project.
> > > > > >> > >
> > > > > >> > > [1] -
> > > > > >> > >
> > > > > >> > >
> > > > > >>
> > > >
> https://github.com/aerogear/aerogear-unifiedpush-server/blob/6c1a0d3fedea8fb6ba918009fd8e9785779c151f/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/sender/PushNotificationSenderEndpoint.java#L56
> > > > > >> > >
> > > > > >> > > [2] -
> > > > > >> > >
> > > > > >>
> > > >
> https://github.com/abstractj/aerogear-unifiedpush-server/tree/keycloak.js
> > > > > >> > > [3] -
> > > > > >> > >
> > > > > >> > >
> > > > > >>
> > > >
> http://photon.abstractj.org/AeroGear_UnifiedPush_Server_2014-06-17_10-00-09_2014-06-17_10-00-12.jpg
> > > > > >> > >
> > > > > >> > > [4] -
> > > > > >> > >
> > > > > >> > >
> > > > > >>
> > > >
> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/server/src/main/webapp/WEB-INF/web.xml#L57
> > > > > >> > >
> > > > > >> > > [5] -
> > > > > >> > >
> > > > > >>
> > > >
> https://github.com/keycloak/keycloak/tree/master/examples/providers/authentication-properties
> > > > > >> > >
> > > > > >> > > --
> > > > > >> > >
> > > > > >> > > abstractj
> > > > > >> > > _______________________________________________
> > > > > >> > > aerogear-dev mailing list
> > > > > >> > > aerogear-dev at lists.jboss.org <javascript:;>
> > > > > >> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > > > >> > >
> > > > > >> >
> > > > > >> >
> > > > > >> >
> > > > > >> > --
> > > > > >> > Matthias Wessendorf
> > > > > >> >
> > > > > >> > blog: http://matthiaswessendorf.wordpress.com/
> > > > > >> > sessions: http://www.slideshare.net/mwessendorf
> > > > > >> > twitter: http://twitter.com/mwessendorf
> > > > > >>
> > > > > >> > _______________________________________________
> > > > > >> > aerogear-dev mailing list
> > > > > >> > aerogear-dev at lists.jboss.org <javascript:;>
> > > > > >> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > > > >>
> > > > > >>
> > > > > >> --
> > > > > >>
> > > > > >> abstractj
> > > > > >> _______________________________________________
> > > > > >> aerogear-dev mailing list
> > > > > >> aerogear-dev at lists.jboss.org <javascript:;>
> > > > > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > > > >>
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Matthias Wessendorf
> > > > > >
> > > > > > blog: http://matthiaswessendorf.wordpress.com/
> > > > > > sessions: http://www.slideshare.net/mwessendorf
> > > > > > twitter: http://twitter.com/mwessendorf
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Matthias Wessendorf
> > > > >
> > > > > blog: http://matthiaswessendorf.wordpress.com/
> > > > > sessions: http://www.slideshare.net/mwessendorf
> > > > > twitter: http://twitter.com/mwessendorf
> > > >
> > > > > _______________________________________________
> > > > > aerogear-dev mailing list
> > > > > aerogear-dev at lists.jboss.org <javascript:;>
> > > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > >
> > > >
> > > > --
> > > >
> > > > abstractj
> > > > _______________________________________________
> > > > aerogear-dev mailing list
> > > > aerogear-dev at lists.jboss.org <javascript:;>
> > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > >
> > >
> > >
> > >
> > > --
> > > Matthias Wessendorf
> > >
> > > blog: http://matthiaswessendorf.wordpress.com/
> > > sessions: http://www.slideshare.net/mwessendorf
> > > twitter: http://twitter.com/mwessendorf
> >
> > > _______________________________________________
> > > aerogear-dev mailing list
> > > aerogear-dev at lists.jboss.org <javascript:;>
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> >
> > --
> >
> > abstractj
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org <javascript:;>
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org <javascript:;>
> https://lists.jboss.org/mailman/listinfo/aerogear-dev



-- 
Sent from Gmail Mobile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140619/0022106a/attachment-0001.html 

From bruno at abstractj.org  Thu Jun 19 12:17:04 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Thu, 19 Jun 2014 13:17:04 -0300
Subject: [aerogear-dev] Keycloak integration and UPS Sender
In-Reply-To: <CAAg5f2QMx_5KdO-sRcBqPxWz0Ekzj5wumOYm001uvZyojAfETA@mail.gmail.com>
References: <20140617142624.GA23555@abstractj.org>
	<CAAg5f2Ry2KWC1WOp64hoS9udX1OWFFz=ZH0En9qx07gE5vC0Eg@mail.gmail.com>
	<20140617171736.GA32200@abstractj.org>
	<CAAg5f2S1bxQC6k0dLxXAhd7LX8aj0XakUDSX+TLmzUUeqMG36w@mail.gmail.com>
	<CAAg5f2RJXsQMdYNjtdf+30Kx6=1sVREoBVB_5Cyry328wcX9Cw@mail.gmail.com>
	<20140617221225.GA37741@abstractj.org>
	<CAAg5f2SzOp+cik4iuZPxOo-7ABOAnCk_VCLzEQSKWU7bs=gdSg@mail.gmail.com>
	<20140618191255.GB62889@abstractj.org>
	<1162554208.29260954.1403166792852.JavaMail.zimbra@redhat.com>
	<CAAg5f2QMx_5KdO-sRcBqPxWz0Ekzj5wumOYm001uvZyojAfETA@mail.gmail.com>
Message-ID: <20140619161704.GA71743@abstractj.org>

Hi Matthias, not sure if I will answer your question. But atm I will
focus on leave it as is like Stian suggested with Keycloak custom valves
for UPS.

Later, after 0.11.0, the other items will be revisited.

On 2014-06-19, Matthias Wessendorf wrote:
> Hi,
>
> a few questions:
> * for device registration will it be possible to perform the actual
> registration by using the variantID and its secret? (Please note that there
> is no "user" on the mobile device. Currently, for the registration, we
> perform http_basic authentification against a variant (via varianID
> /secret))
>
>
> * isn't it possible to exclude a few URIs (e.g. security-constraint
> element(s) in web.xml) from Keycloak? That way 'sender' (and 'device
> registration') cloud stay as they are: using their custom http_basic impl
>
>
> I am NOT against changes, but I am a bit worried that we add new and
> instable code for the sender/registration endpoints (and our mobile clients
> and our senders), just a few weeks before we will have our 1.0.0 release.
>
> Or are my concerns are invalid and the Android, Cordova, iOS SDKs, as well
> as our senders (java and node), will work just fine, without major changes
>
> Thanks,
> Matthias
>
> On Thursday, June 19, 2014, Stian Thorgersen <stian at redhat.com> wrote:
>
> > Here's an idea on how it could be done (disclaimer: this is just a rough
> > idea so take it with a pinch of salt ;)). Some benefits:
> >
> > * Relatively simple to maintain backwards compatibility
> > * Support public clients directly (by using logged in users permissions)
> > * One application can access multiple UPS Apps
> > * No need to maintain master secret in UPS (and can support multiple
> > methods to auth in the future, for example cert or jwt
> > * Manage access through KC - what app/client or user can access what UPS
> > App
> >
> >
> > When creating a new UPS App create:
> >
> > * A role on unified-push-server - the name should be equal to id of UPS app
> >
> > Applications should have 3 options to authenticate:
> >
> > * As the logged in user (for client side applications)
> > * As themselves (for server side applications)
> > * HTTP Basic
> >
> > The master secret can also be removed from UPS App as it should no longer
> > be required.
> >
> > As the logged in user
> > ---------------------
> > This allows public applications to send push messages on behalf of the
> > logged in user. The steps required are:
> >
> > 1) Create an application/client in Keycloak
> >     * Set to public client
> >     * Add scope on UPS App role
> > 2) Create user
> >     * Add role mapping on UPS App role
> > 3) Users logs in with username/password, social, etc through KC login
> >    screens
> > 4) Application can send push messages with bearer token using users
> >    permissions
> >
> > As themselves
> > -------------
> > This allows a server-side application to send push messages on behalf of
> > itself. The steps required are:
> >
> > 1) Create an application/client in Keycloak
> >     * Add scope on UPS App role
> > 2) Create user
> >     * Add role mapping on UPS App role
> >     * Set a long unique password (equivalent of master secret)
> > 3) Application logs in with username/password (equal to UPS App
> >    id/master-secret) using direct grant
> > 4) Application can send push messages with bearer token using its own
> >    permissions
> >
> > In the future Keycloak will support additional mechanism for a server-side
> > application to authenticate on behalf of itself (cert, jwts, etc).
> >
> > HTTP Basic
> > ----------
> > For backwards compatibility we can add a valve that extracts the UPS App
> > id and master secret from Basic auth. It will then use the direct grant
> > mechanism to obtain a token from Keycloak. The steps required to configure
> > is the same as "As themselves".
> >
> >
> >
> > ----- Original Message -----
> > > From: "Bruno Oliveira" <bruno at abstractj.org <javascript:;>>
> > > To: "AeroGear Developer Mailing List" <aerogear-dev at lists.jboss.org
> > <javascript:;>>
> > > Sent: Wednesday, 18 June, 2014 8:12:55 PM
> > > Subject: Re: [aerogear-dev] Keycloak integration and UPS Sender
> > >
> > > Hi guys, let's see the result of the conversation with KC team and we
> > > can revisit this discussion if some changed is required.
> > >
> > > On 2014-06-18, Matthias Wessendorf wrote:
> > > > On Wed, Jun 18, 2014 at 12:12 AM, Bruno Oliveira <bruno at abstractj.org
> > <javascript:;>>
> > > > wrote:
> > > >
> > > > > Answers inline.
> > > > >
> > > > > On 2014-06-17, Matthias Wessendorf wrote:
> > > > > > On Tue, Jun 17, 2014 at 8:51 PM, Matthias Wessendorf
> > > > > > <matzew at apache.org <javascript:;>>
> > > > > > wrote:
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Tue, Jun 17, 2014 at 7:17 PM, Bruno Oliveira <
> > bruno at abstractj.org <javascript:;>>
> > > > > > > wrote:
> > > > > > >
> > > > > > >> Hi Matthias, answer inline.
> > > > > > >>
> > > > > > >> On 2014-06-17, Matthias Wessendorf wrote:
> > > > > > >> > On Tue, Jun 17, 2014 at 4:26 PM, Bruno Oliveira <
> > > > > bruno at abstractj.org <javascript:;>>
> > > > > > >> wrote:
> > > > > > >> >
> > > > > > >> > > Good morning peeps,
> > > > > > >> > >
> > > > > > >> > > I have a problem to solve which might affect the Sender and
> > > > > > >> > > all the related clients.
> > > > > > >> > >
> > > > > > >> > > Previously, the UPS Sender was protected by the basic
> > > > > authentication
> > > > > > >> > > method[1], so anyone in possession of _PushApplicationID_
> > and
> > > > > > >> > > _MasterSecret_ is able to send push messages.
> > > > > > >> > >
> > > > > > >> > > After the integration with Keycloak now everything under
> > _/rest_
> > > > > > >> > > is properly protect by KC which is totally correct. Our
> > sender
> > > > > > >> > > is
> > > > > > >> under
> > > > > > >> > > the same umbrella which means that now Bearer token
> > > > > authentication is
> > > > > > >> > > required[2] and Basic authentication won't exist anymore.
> > > > > > >> > >
> > > > > > >> >
> > > > > > >> >
> > > > > > >> > The device (un)registration endpoints are hit by this as well
> > > > > > >> > (/rest/registry/device/*).
> > > > > > >>
> > > > > > >> Currently Keycloak is protecting our endpoints under /rest/*
> > > > > > >>
> > > > > > >> >
> > > > > > >> > I am wondering if it isn't it possible to keep those URLs
> > > > > > >> > protected
> > > > > via
> > > > > > >> > HTTP_BASIC, or does the keycloak.js usage deny this?
> > > > > > >>
> > > > > > >> Is not the Keycloak.js usage responsible for this, but the
> > correct
> > > > > > >> configuration of the application atm. Please compare:
> > > > > > >>
> > > > > > >> - master branch:
> > > > > > >>
> > > > > > >>
> > > > >
> > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/server/src/main/webapp/WEB-INF/web.xml#L56
> > > > > > >> - keycloak.js branch:
> > > > > > >>
> > > > > > >>
> > > > >
> > https://github.com/aerogear/aerogear-unifiedpush-server/blob/keycloak.js/server/src/main/webapp/WEB-INF/web.xml#L33
> > > > > > >>
> > > > > > >> Now we're fully using Keycloak bearer tokens instead of Basic.
> > > > > > >>
> > > > > > >
> > > > > > >
> > > > > > > Oh, I was following Bill's sample project, where he did not use
> > the
> > > > > > > 'KEYCLOAK' auth-method:
> > > > > > >
> > > > > > >
> > > > >
> > https://github.com/keycloak/keycloak/blob/master/project-integrations/aerogear-ups/app/src/main/webapp/WEB-INF/web.xml#L44
> > > > > > >
> > > > > > > But we had the exclusion working w/ the KEYCLOAK 'auth-method',
> > but
> > > > > this
> > > > > > > goes back to our initial starts in Dec/Jan.
> > > > > > > Here is a rebased commit based on your initial commit:
> > > > > > >
> > > > > > >
> > > > >
> > https://github.com/aerogear/aerogear-unifiedpush-server/blob/2aabd073aaaafa79943ea41d2651f6f0c5e4248e/server/src/main/webapp/WEB-INF/web.xml#L42-L53
> > > > > > >
> > > > > > >
> > > > > > >>
> > > > > > >> >
> > > > > > >> > On master (plain keycloak; before keycloak.js usage) we are
> > doing
> > > > > > >> > an
> > > > > > >> > exclude for those URLs:
> > > > > > >> >
> > > > > > >>
> > > > >
> > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/server/src/main/webapp/WEB-INF/web.xml#L46-L52
> > > > > > >>
> > > > > > >> I tried to include your exclusions, but that didn't work for me.
> > > > > > >>
> > > > > > >> >
> > > > > > >> >
> > > > > > >> > IMO if possible, keeping these 'exceptions' (or excludes)
> > under
> > > > > > >> HTTP_BASIC
> > > > > > >> > would be the simplest solution, as that means none of our
> > client
> > > > > SDKs
> > > > > > >> > (Android, iOS, Cordova, Node.js Sender, Java-Sendet etc) would
> > > > > require
> > > > > > >> an
> > > > > > >> > update.
> > > > > > >>
> > > > > > >> I had a chat with Stian and looks like it's possible to support
> > both
> > > > > > >> auth methods in a single app, but that would involve changes on
> > > > > Keycloak.
> > > > > > >> It's just the matter of discuss with KC team.
> > > > > > >>
> > > > > > >
> > > > > > > I don't think we need to enable to <auth-method> settings in our
> > > > > web.xml;
> > > > > > >
> > > > >
> > > > > How do you manage login/logout/current logged in user on Angular.js?
> > Is
> > > > > possible to do on the server side, but how do you control it on the
> > > > > client side?
> > > > >
> > > >
> > > > Sure, to protect the admin-ui and most of the /rest/* endpoints we
> > need the
> > > > one <auth-method>KEYCLOAK</auth-method>. No question there. I was
> > trying to
> > > > say we do not need multiple 'auth-method' elements on web.xml
> > > >
> > > > But I think it should be possible to exclude a few URLs, like
> > '/rest/foo'
> > > > and '/rest/bar', so that they are completely unprotected in terms of
> > > > Keycloak (e.g. via different security-constraint elements):
> > > >
> > https://github.com/aerogear/aerogear-unifiedpush-server/blob/2aabd073aaaafa79943ea41d2651f6f0c5e4248e/server/src/main/webapp/WEB-INF/web.xml
> > > >
> > > > In terms of "current logged in user on Angular.js":
> > > > * For the "/rest/sender" and "/rest/device/registration" endpoints, I
> > don't
> > > > see a relationship to the user on Angular.js/AdminUI at all.
> > > >
> > > > Internally these 'unprotected' (or excluded) endpoints implement the
> > > > HTTP_BASIC scheme themselves:
> > > > * They treat the Application/Variant like a 'user', by performing a DB
> > > > lookup of the give application/variantID
> > > > * If that (Application or Variant) is found, the endpoints compare the
> > > > given 'password' form the request w/ the "secret" on the  Application
> > or
> > > > Variant
> > > >
> > > > But for these endpoints (sender and device-registration) there is no
> > real
> > > > user here like "Mr. Jay" or "Push-Admin Foo".
> > > >
> > > > The client (registration or sender SDK) performs the auth, by applying
> > the
> > > > ID and the secret:
> > > > curl -3 -u "{PushApplicationID}:{MasterSecret}" .... https://server
> > > >
> > > >
> > > >
> > > > >
> > > > > >
> > > > > > I mean: I think there is no need to enable multiple <auth-method>
> > args,
> > > > > as
> > > > > > we had the exclusion already working at some point, using their
> > > > > > KEYCLOAK
> > > > > > auth-method
> > > > >
> > > > > Stian did that inclusion which for me looks correct. An excerpt from
> > KC
> > > > > documentation:
> > > > >
> > > > > "To be able to secure WAR apps deployed on JBoss AS 7.1.1, JBoss EAP
> > 6.x,
> > > > > or Wildfly, you must install and configure the Keycloak Subsystem.
> > You
> > > > > then have two options to secure your WARs. You can provide a keycloak
> > > > > config file in your WAR and change the auth-method to KEYCLOAK within
> > > > > web.xml. Alternatively, you don't have to crack open your WARs at all
> > > > > and can apply Keycloak via the Keycloak Subsystem configuration in
> > > > > standalone.xml. Both methods are described in this section."
> > > > >
> > > > > You can also stick with BASIC, but probably you end with
> > implementations
> > > > > and customizations that don't take any benefit of Keycloak.js.
> > > > >
> > > > > Either way I will talk tomorrow with Stian and let's see what we can
> > do.
> > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > My initial hope was to be able to simply exclude a few URLs from
> > the
> > > > > > > overall Keycloak protection, like the above referenced commit:
> > > > > > >
> > > > > > >
> > > > >
> > https://github.com/aerogear/aerogear-unifiedpush-server/blob/2aabd073aaaafa79943ea41d2651f6f0c5e4248e/server/src/main/webapp/WEB-INF/web.xml#L42-L53
> > > > > > >
> > > > > > > That would be best as that would mean no API change at all, and
> > our
> > > > > > > client-registration and sender SDKs could stay as they are.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >>
> > > > > > >> My two cents is the fact that we should use bearer tokens only,
> > > > > instead
> > > > > > >> of mix both auth methods in a single app ? now that we have KC.
> > > > > > >> And discuss the changes into our clients rather sooner than
> > later.
> > > > > > >>
> > > > > > >> But I'm open for whatever you guys think it's the best.
> > > > > > >>
> > > > > > >>
> > > > > > >> >
> > > > > > >> > -Matthias
> > > > > > >> >
> > > > > > >> >
> > > > > > >> >
> > > > > > >> >
> > > > > > >> >
> > > > > > >> > >
> > > > > > >> > > The consequence of this is the basic form being presented
> > when
> > > > > you try
> > > > > > >> > > to send push notifications[3]. The problem didn't occur
> > before,
> > > > > > >> because
> > > > > > >> > > we were just using Basic authentication[4] instead of Bearer
> > > > > tokens.
> > > > > > >> > >
> > > > > > >> > > Possible solutions:
> > > > > > >> > >
> > > > > > >> > > 1- After the removal of Basic authentication, move
> > > > > _PushApplicationID_
> > > > > > >> > > and _MasterSecret to http headers like:
> > > > > > >> > >
> > > > > > >> > > -H "PushApplicationID: XXXXXX" -H "MasterSecret: 42"
> > > > > > >> > >
> > > > > > >> > > IMO it sounds correct and reasonable for me.
> > > > > > >> > >
> > > > > > >> > > 2. Create a role specific for the sender like
> > > > > > >> > > _push-applications_
> > > > > and
> > > > > > >> > > dinamically add _PushApplicationID_ and _MasterSecret on
> > > > > > >> > > Keycloak
> > > > > > >> where:
> > > > > > >> > >
> > > > > > >> > > username: _PushApplicationID_
> > > > > > >> > > password: _MasterSecret_
> > > > > > >> > >
> > > > > > >> > > The implications of this alternative is the fact of have to
> > > > > > >> > > manage
> > > > > > >> those
> > > > > > >> > > credentials on the server side inclusion/exclusion/login
> > > > > > >> > >
> > > > > > >> > > 3. Implement another authentication provider specifically
> > for
> > > > > > >> > > the
> > > > > > >> sender
> > > > > > >> > > and Basic authentication[5]
> > > > > > >> > >
> > > > > > >> > > 4. Do nothing. The consequences of this alternative is to
> > > > > implement
> > > > > > >> > > everything already done by Keycloak.js and manage session
> > tokens
> > > > > by
> > > > > > >> hand
> > > > > > >> > > on the admin-ui.
> > > > > > >> > >
> > > > > > >> > > To me the first alternative seems to be more simple, but I
> > > > > > >> > > really
> > > > > want
> > > > > > >> > > your feedback on it, once it affects the whole project.
> > > > > > >> > >
> > > > > > >> > > [1] -
> > > > > > >> > >
> > > > > > >> > >
> > > > > > >>
> > > > >
> > https://github.com/aerogear/aerogear-unifiedpush-server/blob/6c1a0d3fedea8fb6ba918009fd8e9785779c151f/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/sender/PushNotificationSenderEndpoint.java#L56
> > > > > > >> > >
> > > > > > >> > > [2] -
> > > > > > >> > >
> > > > > > >>
> > > > >
> > https://github.com/abstractj/aerogear-unifiedpush-server/tree/keycloak.js
> > > > > > >> > > [3] -
> > > > > > >> > >
> > > > > > >> > >
> > > > > > >>
> > > > >
> > http://photon.abstractj.org/AeroGear_UnifiedPush_Server_2014-06-17_10-00-09_2014-06-17_10-00-12.jpg
> > > > > > >> > >
> > > > > > >> > > [4] -
> > > > > > >> > >
> > > > > > >> > >
> > > > > > >>
> > > > >
> > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/server/src/main/webapp/WEB-INF/web.xml#L57
> > > > > > >> > >
> > > > > > >> > > [5] -
> > > > > > >> > >
> > > > > > >>
> > > > >
> > https://github.com/keycloak/keycloak/tree/master/examples/providers/authentication-properties
> > > > > > >> > >
> > > > > > >> > > --
> > > > > > >> > >
> > > > > > >> > > abstractj
> > > > > > >> > > _______________________________________________
> > > > > > >> > > aerogear-dev mailing list
> > > > > > >> > > aerogear-dev at lists.jboss.org <javascript:;>
> > > > > > >> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > > > > >> > >
> > > > > > >> >
> > > > > > >> >
> > > > > > >> >
> > > > > > >> > --
> > > > > > >> > Matthias Wessendorf
> > > > > > >> >
> > > > > > >> > blog: http://matthiaswessendorf.wordpress.com/
> > > > > > >> > sessions: http://www.slideshare.net/mwessendorf
> > > > > > >> > twitter: http://twitter.com/mwessendorf
> > > > > > >>
> > > > > > >> > _______________________________________________
> > > > > > >> > aerogear-dev mailing list
> > > > > > >> > aerogear-dev at lists.jboss.org <javascript:;>
> > > > > > >> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > > > > >>
> > > > > > >>
> > > > > > >> --
> > > > > > >>
> > > > > > >> abstractj
> > > > > > >> _______________________________________________
> > > > > > >> aerogear-dev mailing list
> > > > > > >> aerogear-dev at lists.jboss.org <javascript:;>
> > > > > > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > > > > >>
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Matthias Wessendorf
> > > > > > >
> > > > > > > blog: http://matthiaswessendorf.wordpress.com/
> > > > > > > sessions: http://www.slideshare.net/mwessendorf
> > > > > > > twitter: http://twitter.com/mwessendorf
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Matthias Wessendorf
> > > > > >
> > > > > > blog: http://matthiaswessendorf.wordpress.com/
> > > > > > sessions: http://www.slideshare.net/mwessendorf
> > > > > > twitter: http://twitter.com/mwessendorf
> > > > >
> > > > > > _______________________________________________
> > > > > > aerogear-dev mailing list
> > > > > > aerogear-dev at lists.jboss.org <javascript:;>
> > > > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > > >
> > > > >
> > > > > --
> > > > >
> > > > > abstractj
> > > > > _______________________________________________
> > > > > aerogear-dev mailing list
> > > > > aerogear-dev at lists.jboss.org <javascript:;>
> > > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Matthias Wessendorf
> > > >
> > > > blog: http://matthiaswessendorf.wordpress.com/
> > > > sessions: http://www.slideshare.net/mwessendorf
> > > > twitter: http://twitter.com/mwessendorf
> > >
> > > > _______________________________________________
> > > > aerogear-dev mailing list
> > > > aerogear-dev at lists.jboss.org <javascript:;>
> > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > >
> > >
> > > --
> > >
> > > abstractj
> > > _______________________________________________
> > > aerogear-dev mailing list
> > > aerogear-dev at lists.jboss.org <javascript:;>
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org <javascript:;>
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> --
> Sent from Gmail Mobile

> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


--

abstractj

From keith at kdmooreconsulting.com  Fri Jun 20 10:35:48 2014
From: keith at kdmooreconsulting.com (keithdmoore94)
Date: Fri, 20 Jun 2014 07:35:48 -0700 (PDT)
Subject: [aerogear-dev] aerogear cordova push plugin android
	registration problem
In-Reply-To: <1403169513165-8206.post@n5.nabble.com>
References: <1403169513165-8206.post@n5.nabble.com>
Message-ID: <1403274948874-8211.post@n5.nabble.com>

Did you do this at the root of the application folder ?

cordova plugin add org.jboss.aerogear.cordova.push

You might also try to remove and add the android or ios platform.



--
View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-cordova-push-plugin-android-registration-problem-tp8206p8211.html
Sent from the aerogear-dev mailing list archive at Nabble.com.

From keith at kdmooreconsulting.com  Fri Jun 20 10:42:19 2014
From: keith at kdmooreconsulting.com (keithdmoore94)
Date: Fri, 20 Jun 2014 07:42:19 -0700 (PDT)
Subject: [aerogear-dev] aerogear cordova push plugin android
	registration problem
In-Reply-To: <1403169513165-8206.post@n5.nabble.com>
References: <1403169513165-8206.post@n5.nabble.com>
Message-ID: <1403275339037-8212.post@n5.nabble.com>

Just realized what the problem is.  I think the docs: 
http://aerogear.org/docs/guides/aerogear-push-cordova-android/cordova-android-app/
<http://aerogear.org/docs/guides/aerogear-push-cordova-android/cordova-android-app/>  
need to be updated.


        var pushConfig = {
    	    pushServerURL: PUSH_SERVER,
    	    alias: '' + alias,
    	    android: {
    	      senderID:  ANDROID_PROJECT_NUMBER,
    	      variantID: ANDROID_VARIANT_ID,
    	      variantSecret: ANDROID_VARIANT_SECRET
    	    },
    	    ios: {
    	      variantID: IOS_VARIANT_ID,
    	      variantSecret: IOS_VARIANT_SECRET
    	    }
        };
        push.register(onNotification, registerSuccessHandler,
registerErrorHandler, pushConfig);  



--
View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-cordova-push-plugin-android-registration-problem-tp8206p8212.html
Sent from the aerogear-dev mailing list archive at Nabble.com.

From mohamed_el_amine.belmokhtar at univ-lr.fr  Fri Jun 20 11:11:56 2014
From: mohamed_el_amine.belmokhtar at univ-lr.fr (lb44)
Date: Fri, 20 Jun 2014 08:11:56 -0700 (PDT)
Subject: [aerogear-dev] aerogear cordova push plugin android
	registration problem
In-Reply-To: <1403274948874-8211.post@n5.nabble.com>
References: <1403169513165-8206.post@n5.nabble.com>
	<1403274948874-8211.post@n5.nabble.com>
Message-ID: <1403277116002-8213.post@n5.nabble.com>

Thanks for your response ! 

I have solved the problem, my application included phonegap.js and
cordova.js... and i think that was the origin of the problem because now
there is no error message but the situation is not better, because the
application still doesn't receive notification.

I have a grunt task which make creates a phonegap directory, I enter into
this directory, and i make "phonegap local plugin add
https://github.com/aerogear/aerogear-pushplugin-cordova". After I execute
"phonegap run android" and I have read somewhere that the "phonegap run xxx" 
command line made a phonegap build so i didn't think that would solve the
problem but I tried but as expected, it didn't change anything.



--
View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-cordova-push-plugin-android-registration-problem-tp8206p8213.html
Sent from the aerogear-dev mailing list archive at Nabble.com.

From mohamed_el_amine.belmokhtar at univ-lr.fr  Fri Jun 20 11:24:19 2014
From: mohamed_el_amine.belmokhtar at univ-lr.fr (lb44)
Date: Fri, 20 Jun 2014 08:24:19 -0700 (PDT)
Subject: [aerogear-dev] aerogear cordova push plugin android
	registration problem
In-Reply-To: <1403275339037-8212.post@n5.nabble.com>
References: <1403169513165-8206.post@n5.nabble.com>
	<1403275339037-8212.post@n5.nabble.com>
Message-ID: <1403277859078-8214.post@n5.nabble.com>

I followed the doc and the problem does not come from there, I have set the
parameters in the correct order.
In Aerogear push plugin Version 0.0.3, the order of parameters is :
push.register (successCallback, errorCallback, options);
In Aerogear push plugin Version 0.0.3, the order of parameters is :
push.register (onNotification, successCallback, errorCallback, options);

And the syntax of push Config variable can be written exclusively for ios or
android like this : 


var pushConfig = {
            senderID: "579452721219",
            pushServerURL: "http://10.13.3.240:8080/ag-push/",
            variantID: "c18946ae-a559-4f57-aa03-31322dc54763",
            variantSecret: "02af9898-01d8-4134-8709-3d80b6a30c17",
            alias:"mohamed"
            };

I tried it in a very simple application and work fine.



--
View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-cordova-push-plugin-android-registration-problem-tp8206p8214.html
Sent from the aerogear-dev mailing list archive at Nabble.com.

From mohamed_el_amine.belmokhtar at univ-lr.fr  Fri Jun 20 11:46:13 2014
From: mohamed_el_amine.belmokhtar at univ-lr.fr (lb44)
Date: Fri, 20 Jun 2014 08:46:13 -0700 (PDT)
Subject: [aerogear-dev] Problems sending notifications Cordova
In-Reply-To: <1398739303203-7611.post@n5.nabble.com>
References: <53581A98.9080702@abstractj.org>
	<1398333062008-7566.post@n5.nabble.com>
	<CAAg5f2SDEbdVX3b8Rc=p6YYM+KiKL98XQUdnHLGJR0hhp71RZg@mail.gmail.com>
	<1398490253386-7583.post@n5.nabble.com>
	<CAAg5f2TOYmB46q5WCpm29i9XsS81-z-ZXUhSg8P5m1ix7-FV9w@mail.gmail.com>
	<1398547466903-7587.post@n5.nabble.com>
	<1398554371318-7589.post@n5.nabble.com>
	<1398632938043-7592.post@n5.nabble.com>
	<CAAg5f2Sb1xS8f6xPMHai2KvMDut3Oj2cAN+3Bhj1bq0EHRp6ZQ@mail.gmail.com>
	<1398739303203-7611.post@n5.nabble.com>
Message-ID: <1403279173731-8215.post@n5.nabble.com>

I'm working a nexus 7 too. I'm on android 4.4.3, some application receives
notifications but not all, I thought that i have the same problem like you
but I restarted my UPS, created a new application, a new variant, a new
google project but the application never can receive push notification.



--
View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Problems-sending-notifications-Cordova-tp7515p8215.html
Sent from the aerogear-dev mailing list archive at Nabble.com.

From keith at kdmooreconsulting.com  Fri Jun 20 12:42:13 2014
From: keith at kdmooreconsulting.com (keithdmoore94)
Date: Fri, 20 Jun 2014 09:42:13 -0700 (PDT)
Subject: [aerogear-dev] Problems sending notifications Cordova
In-Reply-To: <1403279173731-8215.post@n5.nabble.com>
References: <1398333062008-7566.post@n5.nabble.com>
	<CAAg5f2SDEbdVX3b8Rc=p6YYM+KiKL98XQUdnHLGJR0hhp71RZg@mail.gmail.com>
	<1398490253386-7583.post@n5.nabble.com>
	<CAAg5f2TOYmB46q5WCpm29i9XsS81-z-ZXUhSg8P5m1ix7-FV9w@mail.gmail.com>
	<1398547466903-7587.post@n5.nabble.com>
	<1398554371318-7589.post@n5.nabble.com>
	<1398632938043-7592.post@n5.nabble.com>
	<CAAg5f2Sb1xS8f6xPMHai2KvMDut3Oj2cAN+3Bhj1bq0EHRp6ZQ@mail.gmail.com>
	<1398739303203-7611.post@n5.nabble.com>
	<1403279173731-8215.post@n5.nabble.com>
Message-ID: <1403282533965-8216.post@n5.nabble.com>

Recently, I unregistered the device. Then deleted the app from the Nexus 7
and restarted the device.  I then redeployed the app and registered the
device.  It then started receiving again.  I have also had to delete and
recreated the variant to prevent duplicate messages from being sent.  I have
had to do similar things from my Samsung Tab3 but not nearly as often.



--
View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Problems-sending-notifications-Cordova-tp7515p8216.html
Sent from the aerogear-dev mailing list archive at Nabble.com.

From keith at kdmooreconsulting.com  Fri Jun 20 12:45:58 2014
From: keith at kdmooreconsulting.com (keithdmoore94)
Date: Fri, 20 Jun 2014 09:45:58 -0700 (PDT)
Subject: [aerogear-dev] aerogear cordova push plugin android
	registration problem
In-Reply-To: <1403277859078-8214.post@n5.nabble.com>
References: <1403169513165-8206.post@n5.nabble.com>
	<1403275339037-8212.post@n5.nabble.com>
	<1403277859078-8214.post@n5.nabble.com>
Message-ID: <1403282758706-8217.post@n5.nabble.com>

Ok.  I thought that the way you set the config might have been the problem. 
I use cordova so I cant speak to any of the phonegap issues.



--
View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-cordova-push-plugin-android-registration-problem-tp8206p8217.html
Sent from the aerogear-dev mailing list archive at Nabble.com.

From matzew at apache.org  Fri Jun 20 17:18:29 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Fri, 20 Jun 2014 23:18:29 +0200
Subject: [aerogear-dev] Problems sending notifications Cordova
In-Reply-To: <1403282533965-8216.post@n5.nabble.com>
References: <1398333062008-7566.post@n5.nabble.com>
	<CAAg5f2SDEbdVX3b8Rc=p6YYM+KiKL98XQUdnHLGJR0hhp71RZg@mail.gmail.com>
	<1398490253386-7583.post@n5.nabble.com>
	<CAAg5f2TOYmB46q5WCpm29i9XsS81-z-ZXUhSg8P5m1ix7-FV9w@mail.gmail.com>
	<1398547466903-7587.post@n5.nabble.com>
	<1398554371318-7589.post@n5.nabble.com>
	<1398632938043-7592.post@n5.nabble.com>
	<CAAg5f2Sb1xS8f6xPMHai2KvMDut3Oj2cAN+3Bhj1bq0EHRp6ZQ@mail.gmail.com>
	<1398739303203-7611.post@n5.nabble.com>
	<1403279173731-8215.post@n5.nabble.com>
	<1403282533965-8216.post@n5.nabble.com>
Message-ID: <CAAg5f2S6YdcY1OzPs4dZKDyZtw5NrLMLKpCYLcDEq3s7PO56NA@mail.gmail.com>

Hello Keith,

A few questions:
* did the unregister from your app remove the installation from the variant
? (Should be visible on the AdminUI)
* is that "only" Cordova-Android? Or Cordova-iOS as well?
* did you notice the duplicate message being sent on "native" Android, or
just Cordova?

Thanks,
Matthias

On Friday, June 20, 2014, keithdmoore94 <keith at kdmooreconsulting.com> wrote:

> Recently, I unregistered the device. Then deleted the app from the Nexus 7
> and restarted the device.  I then redeployed the app and registered the
> device.  It then started receiving again.  I have also had to delete and
> recreated the variant to prevent duplicate messages from being sent.  I
> have
> had to do similar things from my Samsung Tab3 but not nearly as often.
>
>
>
> --
> View this message in context:
> http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Problems-sending-notifications-Cordova-tp7515p8216.html
> Sent from the aerogear-dev mailing list archive at Nabble.com.
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org <javascript:;>
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>


-- 
Sent from Gmail Mobile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140620/78340748/attachment.html 

From matzew at apache.org  Mon Jun 23 05:08:50 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Mon, 23 Jun 2014 11:08:50 +0200
Subject: [aerogear-dev] UPS branch for testing KC beta3
In-Reply-To: <20140618191550.GC62889@abstractj.org>
References: <20140618191550.GC62889@abstractj.org>
Message-ID: <CAAg5f2S2=CMraMiDuziygzv82_8q9Maq_Js0CXxtsNbTrHGCOQ@mail.gmail.com>

+1


On Wed, Jun 18, 2014 at 9:15 PM, Bruno Oliveira <bruno at abstractj.org> wrote:

> Good morning,
>
> If you want to try Keycloak beta3, I created a new branch called
> keycloak-beta3 for testing and already rebased against the master
> (
> https://github.com/aerogear/aerogear-unifiedpush-server/tree/keycloak-beta3
> ).
> Nexus repository was included until KC release be available on Maven
> central.
>
> Note: This branch does not include the integration with keycloak.js
>
> --
>
> abstractj
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140623/166b18dd/attachment.html 

From g.sciacca at glauco.it  Wed Jun 25 10:24:30 2014
From: g.sciacca at glauco.it (Giuseppe Sciacca)
Date: Wed, 25 Jun 2014 14:24:30 +0000
Subject: [aerogear-dev] Aerogear - The UnifiedPush Server on Glassfish
Message-ID: <51758cf68f9d4974a019e3a147ee4d93@ServerMail2.ids-unitelm.it>

Hi,
   sorry for my english :P

"The UnifiedPush Server on Glassfish"

it's possible ?
is there some tutorial?


thank's a lot

GiuScia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140625/c115c1f8/attachment-0001.html 

From matzew at apache.org  Wed Jun 25 10:30:43 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Wed, 25 Jun 2014 10:30:43 -0400
Subject: [aerogear-dev] Aerogear - The UnifiedPush Server on Glassfish
In-Reply-To: <51758cf68f9d4974a019e3a147ee4d93@ServerMail2.ids-unitelm.it>
References: <51758cf68f9d4974a019e3a147ee4d93@ServerMail2.ids-unitelm.it>
Message-ID: <CAAg5f2QrzGsUAAT4LitvzP95s=DrbuBBa4HsdYNx+fRsDP8HoQ@mail.gmail.com>

hello Giuseppe!

thanks for the interest in the UnifiedPush Server. Since it is standard
JavaEE, it should be working in Glassfish.
However you need to configure a datasource (e.g. MySQL) inside of
Glassfish. Here is the details about our DS name:
https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/model/jpa/src/main/resources/META-INF/persistence.xml#L23


Did you give it a try? If there are any issues, please report them here, so
that we can help :)

Greetings,
Matthias



On Wed, Jun 25, 2014 at 10:24 AM, Giuseppe Sciacca <g.sciacca at glauco.it>
wrote:

>  Hi,
>
>    sorry for my english :P
>
>
>
> ?The UnifiedPush Server on Glassfish?
>
>
>
> it?s possible ?
>
> is there some tutorial?
>
>
>
>
>
> thank?s a lot
>
>
>
> GiuScia
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140625/b26bb8b8/attachment.html 

From keith at kdmooreconsulting.com  Wed Jun 25 10:34:29 2014
From: keith at kdmooreconsulting.com (keithdmoore94)
Date: Wed, 25 Jun 2014 07:34:29 -0700 (PDT)
Subject: [aerogear-dev] Problems sending notifications Cordova
In-Reply-To: <CAAg5f2S6YdcY1OzPs4dZKDyZtw5NrLMLKpCYLcDEq3s7PO56NA@mail.gmail.com>
References: <1398490253386-7583.post@n5.nabble.com>
	<CAAg5f2TOYmB46q5WCpm29i9XsS81-z-ZXUhSg8P5m1ix7-FV9w@mail.gmail.com>
	<1398547466903-7587.post@n5.nabble.com>
	<1398554371318-7589.post@n5.nabble.com>
	<1398632938043-7592.post@n5.nabble.com>
	<CAAg5f2Sb1xS8f6xPMHai2KvMDut3Oj2cAN+3Bhj1bq0EHRp6ZQ@mail.gmail.com>
	<1398739303203-7611.post@n5.nabble.com>
	<1403279173731-8215.post@n5.nabble.com>
	<1403282533965-8216.post@n5.nabble.com>
	<CAAg5f2S6YdcY1OzPs4dZKDyZtw5NrLMLKpCYLcDEq3s7PO56NA@mail.gmail.com>
Message-ID: <1403706869094-8222.post@n5.nabble.com>

My responses to the questions below:

* did the unregister from your app remove the installation from the variant
? (Should be visible on the AdminUI)

KDM: It did NOT remove it.  I wonder if the device generated a new regID
which would possibly explain why it didn't unregister.  Also, I didn't get
an error message with the unregister. 

* is that "only" Cordova-Android? Or Cordova-iOS as well?
KDM:  "only" Cordova-Android has these problems.  Seems to happen more with
my Nexus 7.  Maybe because its the device I use to test the most.

* did you notice the duplicate message being sent on "native" Android, or
just Cordova?
KDM: I am only using "Cordova"



--
View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Problems-sending-notifications-Cordova-tp7515p8222.html
Sent from the aerogear-dev mailing list archive at Nabble.com.

From mohamed_el_amine.belmokhtar at univ-lr.fr  Wed Jun 25 10:47:07 2014
From: mohamed_el_amine.belmokhtar at univ-lr.fr (lb44)
Date: Wed, 25 Jun 2014 07:47:07 -0700 (PDT)
Subject: [aerogear-dev] aerogear cordova push plugin android
	registration problem
In-Reply-To: <1403282758706-8217.post@n5.nabble.com>
References: <1403169513165-8206.post@n5.nabble.com>
	<1403275339037-8212.post@n5.nabble.com>
	<1403277859078-8214.post@n5.nabble.com>
	<1403282758706-8217.post@n5.nabble.com>
Message-ID: <1403707627887-8223.post@n5.nabble.com>

I have found the origin of my problem.

Firstly, my application was including phonegap.js and cordova.js... it was a
bad idea.
Secondly, I think that when I create a projet in google console and activate
notifcation push. After I had sent a notification, google server registers
the hash of my application. Why I think that, it's cause of whenever I
change my source code, the application no longer receives notifications.
Whenever I have to create a new application in google console and create a
new application and a new variant in UPS.




--
View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-cordova-push-plugin-android-registration-problem-tp8206p8223.html
Sent from the aerogear-dev mailing list archive at Nabble.com.

From mmurray at redhat.com  Thu Jun 26 03:06:13 2014
From: mmurray at redhat.com (Michelle Murray)
Date: Thu, 26 Jun 2014 03:06:13 -0400 (EDT)
Subject: [aerogear-dev] Aerogear slide decks and videos
In-Reply-To: <1271931635.30692564.1403766264788.JavaMail.zimbra@redhat.com>
References: <1271931635.30692564.1403766264788.JavaMail.zimbra@redhat.com>
Message-ID: <292531261.30693098.1403766373388.JavaMail.zimbra@redhat.com>

Hello, 

The Mobile Docs team is trying to gather resources from which to learn about aerogear and the unified push server. 

We've already looked at the aerogear push 101 youtube video and the docs on the aerogear website. 

Does anyone have any slide decks or more recent videos that we could learn from? 

Thanks, 
Michelle 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140626/34402ab0/attachment.html 

From g.sciacca at glauco.it  Thu Jun 26 03:54:12 2014
From: g.sciacca at glauco.it (Giuseppe Sciacca)
Date: Thu, 26 Jun 2014 07:54:12 +0000
Subject: [aerogear-dev] Aerogear - The UnifiedPush Server on Glassfish
Message-ID: <64b09d313cac4d468b7da713918d3897@ServerMail2.ids-unitelm.it>

Hi Matthias,


   thank's for all.

this is a part of my log :(




[#|2014-06-26T09:39:19.315+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=45;_ThreadName=Thread-2;|Exception while visiting org/jboss/aerogear/security/auth/AuthenticationManager.class of size 335
java.lang.NullPointerException
            at org.glassfish.hk2.classmodel.reflect.impl.TypesImpl.getType(TypesImpl.java:78)
            at org.glassfish.hk2.classmodel.reflect.impl.ModelClassVisitor.visit(ModelClassVisitor.java:119)
            at org.objectweb.asm.ClassReader.accept(Unknown Source)
            at org.objectweb.asm.ClassReader.accept(Unknown Source)
            at org.glassfish.hk2.classmodel.reflect.Parser$5.on(Parser.java:363)
            at com.sun.enterprise.v3.server.ReadableArchiveScannerAdapter.handleEntry(ReadableArchiveScannerAdapter.java:171)
            at com.sun.enterprise.v3.server.ReadableArchiveScannerAdapter.onSelectedEntries(ReadableArchiveScannerAdapter.java:133)
            at org.glassfish.hk2.classmodel.reflect.Parser.doJob(Parser.java:348)
            at org.glassfish.hk2.classmodel.reflect.Parser.access$300(Parser.java:70)
            at org.glassfish.hk2.classmodel.reflect.Parser$3.call(Parser.java:307)
            at org.glassfish.hk2.classmodel.reflect.Parser$3.call(Parser.java:296)
            at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
            at java.util.concurrent.FutureTask.run(FutureTask.java:166)
            at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
            at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
            at java.lang.Thread.run(Thread.java:722)

......


[#|2014-06-26T09:39:22.564+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=44;_ThreadName=Thread-2;|Exception [EclipseLink-28018] (Eclipse Persistence Services - 2.3.2.v20111125-r10461): org.eclipse.persistence.exceptions.EntityManagerSetupException
Exception Description: Predeployment of PersistenceUnit [picketlink-default] failed.
Internal Exception: Exception [EclipseLink-7212] (Eclipse Persistence Services - 2.3.2.v20111125-r10461): org.eclipse.persistence.exceptions.ValidationException
Exception Description: The attribute [expiryDate] from the entity class [class org.picketlink.idm.jpa.model.sample.simple.AbstractCredentialTypeEntity] does not specify a temporal type. A temporal type must be specified for persistent fields or properties of type java.util.Date and java.util.Calendar.
javax.persistence.PersistenceException: Exception [EclipseLink-28018] (Eclipse Persistence Services - 2.3.2.v20111125-r10461): org.eclipse.persistence.exceptions.EntityManagerSetupException
Exception Description: Predeployment of PersistenceUnit [picketlink-default] failed.
Internal Exception: Exception [EclipseLink-7212] (Eclipse Persistence Services - 2.3.2.v20111125-r10461): org.eclipse.persistence.exceptions.ValidationException
Exception Description: The attribute [expiryDate] from the entity class [class org.picketlink.idm.jpa.model.sample.simple.AbstractCredentialTypeEntity] does not specify a temporal type. A temporal type must be specified for persistent fields or properties of type java.util.Date and java.util.Calendar.
            at org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.predeploy(EntityManagerSetupImpl.java:1402)
            at org.eclipse.persistence.jpa.PersistenceProvider.createContainerEntityManagerFactory(PersistenceProvider.java:208)
            at org.glassfish.persistence.jpa.PersistenceUnitLoader.loadPU(PersistenceUnitLoader.java:206)
            at org.glassfish.persistence.jpa.PersistenceUnitLoader.<init>(PersistenceUnitLoader.java:120)
....



Greetings,
Giuseppe









hello Giuseppe!

thanks for the interest in the UnifiedPush Server. Since it is standard JavaEE, it should be working in Glassfish.
However you need to configure a datasource (e.g. MySQL) inside of Glassfish. Here is the details about our DS name:
https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/model/jpa/src/main/resources/META-INF/persistence.xml#L23


Did you give it a try? If there are any issues, please report them here, so that we can help :)

Greetings,
Matthias


On Wed, Jun 25, 2014 at 10:24 AM, Giuseppe Sciacca <g.sciacca at glauco.it<mailto:g.sciacca at glauco.it>> wrote:
Hi,
   sorry for my english :P

"The UnifiedPush Server on Glassfish"

it's possible ?
is there some tutorial?


thank's a lot

GiuScia

_______________________________________________
aerogear-dev mailing list
aerogear-dev at lists.jboss.org<mailto:aerogear-dev at lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf

_______________________________________________
aerogear-dev mailing list
aerogear-dev at lists.jboss.org<mailto:aerogear-dev at lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140626/0efc7c24/attachment-0001.html 

From matzew at apache.org  Thu Jun 26 07:37:06 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Thu, 26 Jun 2014 07:37:06 -0400
Subject: [aerogear-dev] Aerogear - The UnifiedPush Server on Glassfish
In-Reply-To: <64b09d313cac4d468b7da713918d3897@ServerMail2.ids-unitelm.it>
References: <64b09d313cac4d468b7da713918d3897@ServerMail2.ids-unitelm.it>
Message-ID: <CAAg5f2TS5kBbYrqujSa5=eyVWwJT4mY152cNg7BOysHVmyH2Vw@mail.gmail.com>

Hello Giuseppe!

thanks for reporting the issue. In the 0.10.x series we are using
Picketlink for security (mainly auth of the user), but it looks like the
version we are using has an issue w/ EclipseLink that is used as
Glassfish's JPA Provider. I will report that issue to the Picketlink team.
Perhaps there is a way to get a patched version of the 0.10x series. We
will keep you posted.


On the master branch (0.11.x) series we are no longer using Picketlink, we
are using Keycloak, but I don't see a Glassfish adapter for Keycloak at the
moment.


Besides these issues, there is still an option to use the UnifiedPush
Server:
* On the cloud, via OpenShift (it's free to get an OpenShift account)
* Via JBoss AS / EAP

Hope that helps for now

-Matthias





On Thu, Jun 26, 2014 at 3:54 AM, Giuseppe Sciacca <g.sciacca at glauco.it>
wrote:

>  Hi Matthias,
>
>
>
>
>
>    thank?s for all.
>
>
>
> this is a part of my log :(
>
>
>
>
>
>
>
>
>
> [#|2014-06-26T09:39:19.315+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=45;_ThreadName=Thread-2;|Exception
> while visiting org/jboss/aerogear/security/auth/AuthenticationManager.class
> of size 335
>
> java.lang.NullPointerException
>
>             at
> org.glassfish.hk2.classmodel.reflect.impl.TypesImpl.getType(TypesImpl.java:78)
>
>             at
> org.glassfish.hk2.classmodel.reflect.impl.ModelClassVisitor.visit(ModelClassVisitor.java:119)
>
>             at org.objectweb.asm.ClassReader.accept(Unknown Source)
>
>             at org.objectweb.asm.ClassReader.accept(Unknown Source)
>
>             at
> org.glassfish.hk2.classmodel.reflect.Parser$5.on(Parser.java:363)
>
>             at
> com.sun.enterprise.v3.server.ReadableArchiveScannerAdapter.handleEntry(ReadableArchiveScannerAdapter.java:171)
>
>             at
> com.sun.enterprise.v3.server.ReadableArchiveScannerAdapter.onSelectedEntries(ReadableArchiveScannerAdapter.java:133)
>
>             at
> org.glassfish.hk2.classmodel.reflect.Parser.doJob(Parser.java:348)
>
>             at
> org.glassfish.hk2.classmodel.reflect.Parser.access$300(Parser.java:70)
>
>             at
> org.glassfish.hk2.classmodel.reflect.Parser$3.call(Parser.java:307)
>
>             at
> org.glassfish.hk2.classmodel.reflect.Parser$3.call(Parser.java:296)
>
>             at
> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
>
>             at java.util.concurrent.FutureTask.run(FutureTask.java:166)
>
>             at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
>
>             at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
>
>             at java.lang.Thread.run(Thread.java:722)
>
>
>
> ......
>
>
>
>
>
> [#|2014-06-26T09:39:22.564+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=44;_ThreadName=Thread-2;|Exception
> [EclipseLink-28018] (Eclipse Persistence Services -
> 2.3.2.v20111125-r10461):
> org.eclipse.persistence.exceptions.EntityManagerSetupException
>
> Exception Description: Predeployment of PersistenceUnit
> [picketlink-default] failed.
>
> Internal Exception: Exception [EclipseLink-7212] (Eclipse Persistence
> Services - 2.3.2.v20111125-r10461):
> org.eclipse.persistence.exceptions.ValidationException
>
> Exception Description: The attribute [expiryDate] from the entity class
> [class
> org.picketlink.idm.jpa.model.sample.simple.AbstractCredentialTypeEntity]
> does not specify a temporal type. A temporal type must be specified for
> persistent fields or properties of type java.util.Date and
> java.util.Calendar.
>
> javax.persistence.PersistenceException: Exception [EclipseLink-28018]
> (Eclipse Persistence Services - 2.3.2.v20111125-r10461):
> org.eclipse.persistence.exceptions.EntityManagerSetupException
>
> Exception Description: Predeployment of PersistenceUnit
> [picketlink-default] failed.
>
> Internal Exception: Exception [EclipseLink-7212] (Eclipse Persistence
> Services - 2.3.2.v20111125-r10461):
> org.eclipse.persistence.exceptions.ValidationException
>
> Exception Description: The attribute [expiryDate] from the entity class
> [class
> org.picketlink.idm.jpa.model.sample.simple.AbstractCredentialTypeEntity]
> does not specify a temporal type. A temporal type must be specified for
> persistent fields or properties of type java.util.Date and
> java.util.Calendar.
>
>             at
> org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.predeploy(EntityManagerSetupImpl.java:1402)
>
>             at
> org.eclipse.persistence.jpa.PersistenceProvider.createContainerEntityManagerFactory(PersistenceProvider.java:208)
>
>             at
> org.glassfish.persistence.jpa.PersistenceUnitLoader.loadPU(PersistenceUnitLoader.java:206)
>
>             at
> org.glassfish.persistence.jpa.PersistenceUnitLoader.<init>(PersistenceUnitLoader.java:120)
>
> ....
>
>
>
>
>
>
>
> Greetings,
>
> Giuseppe
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> hello Giuseppe!
>
>
>
> thanks for the interest in the UnifiedPush Server. Since it is standard
> JavaEE, it should be working in Glassfish.
>
> However you need to configure a datasource (e.g. MySQL) inside of
> Glassfish. Here is the details about our DS name:
>
>
> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/model/jpa/src/main/resources/META-INF/persistence.xml#L23
>
>
>
>
>
> Did you give it a try? If there are any issues, please report them here,
> so that we can help :)
>
>
>
> Greetings,
>
> Matthias
>
>
>
>
>
> On Wed, Jun 25, 2014 at 10:24 AM, Giuseppe Sciacca <g.sciacca at glauco.it
> > wrote:
>
> Hi,
>
>    sorry for my english :P
>
>
>
> ?The UnifiedPush Server on Glassfish?
>
>
>
> it?s possible ?
>
> is there some tutorial?
>
>
>
>
>
> thank?s a lot
>
>
>
> GiuScia
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140626/9bc7f30c/attachment-0001.html 

From matzew at apache.org  Thu Jun 26 07:55:25 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Thu, 26 Jun 2014 07:55:25 -0400
Subject: [aerogear-dev] Aerogear - The UnifiedPush Server on Glassfish
In-Reply-To: <CAAg5f2TS5kBbYrqujSa5=eyVWwJT4mY152cNg7BOysHVmyH2Vw@mail.gmail.com>
References: <64b09d313cac4d468b7da713918d3897@ServerMail2.ids-unitelm.it>
	<CAAg5f2TS5kBbYrqujSa5=eyVWwJT4mY152cNg7BOysHVmyH2Vw@mail.gmail.com>
Message-ID: <CAAg5f2QB2M9k5DoanbjZ=ujXuYPpQF691DGWc5oKd55uf5VRPw@mail.gmail.com>

Hello Giuseppe,

here is the PicketLink bug:
https://issues.jboss.org/browse/PLINK-514

-Matthias



On Thu, Jun 26, 2014 at 7:37 AM, Matthias Wessendorf <matzew at apache.org>
wrote:

> Hello Giuseppe!
>
> thanks for reporting the issue. In the 0.10.x series we are using
> Picketlink for security (mainly auth of the user), but it looks like the
> version we are using has an issue w/ EclipseLink that is used as
> Glassfish's JPA Provider. I will report that issue to the Picketlink team.
> Perhaps there is a way to get a patched version of the 0.10x series. We
> will keep you posted.
>
>
> On the master branch (0.11.x) series we are no longer using Picketlink, we
> are using Keycloak, but I don't see a Glassfish adapter for Keycloak at the
> moment.
>
>
> Besides these issues, there is still an option to use the UnifiedPush
> Server:
> * On the cloud, via OpenShift (it's free to get an OpenShift account)
> * Via JBoss AS / EAP
>
> Hope that helps for now
>
> -Matthias
>
>
>
>
>
> On Thu, Jun 26, 2014 at 3:54 AM, Giuseppe Sciacca <g.sciacca at glauco.it>
> wrote:
>
>>  Hi Matthias,
>>
>>
>>
>>
>>
>>    thank?s for all.
>>
>>
>>
>> this is a part of my log :(
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> [#|2014-06-26T09:39:19.315+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=45;_ThreadName=Thread-2;|Exception
>> while visiting org/jboss/aerogear/security/auth/AuthenticationManager.class
>> of size 335
>>
>> java.lang.NullPointerException
>>
>>             at
>> org.glassfish.hk2.classmodel.reflect.impl.TypesImpl.getType(TypesImpl.java:78)
>>
>>             at
>> org.glassfish.hk2.classmodel.reflect.impl.ModelClassVisitor.visit(ModelClassVisitor.java:119)
>>
>>             at org.objectweb.asm.ClassReader.accept(Unknown Source)
>>
>>             at org.objectweb.asm.ClassReader.accept(Unknown Source)
>>
>>             at
>> org.glassfish.hk2.classmodel.reflect.Parser$5.on(Parser.java:363)
>>
>>             at
>> com.sun.enterprise.v3.server.ReadableArchiveScannerAdapter.handleEntry(ReadableArchiveScannerAdapter.java:171)
>>
>>             at
>> com.sun.enterprise.v3.server.ReadableArchiveScannerAdapter.onSelectedEntries(ReadableArchiveScannerAdapter.java:133)
>>
>>             at
>> org.glassfish.hk2.classmodel.reflect.Parser.doJob(Parser.java:348)
>>
>>             at
>> org.glassfish.hk2.classmodel.reflect.Parser.access$300(Parser.java:70)
>>
>>             at
>> org.glassfish.hk2.classmodel.reflect.Parser$3.call(Parser.java:307)
>>
>>             at
>> org.glassfish.hk2.classmodel.reflect.Parser$3.call(Parser.java:296)
>>
>>             at
>> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
>>
>>             at java.util.concurrent.FutureTask.run(FutureTask.java:166)
>>
>>             at
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
>>
>>             at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
>>
>>             at java.lang.Thread.run(Thread.java:722)
>>
>>
>>
>> ......
>>
>>
>>
>>
>>
>> [#|2014-06-26T09:39:22.564+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=44;_ThreadName=Thread-2;|Exception
>> [EclipseLink-28018] (Eclipse Persistence Services -
>> 2.3.2.v20111125-r10461):
>> org.eclipse.persistence.exceptions.EntityManagerSetupException
>>
>> Exception Description: Predeployment of PersistenceUnit
>> [picketlink-default] failed.
>>
>> Internal Exception: Exception [EclipseLink-7212] (Eclipse Persistence
>> Services - 2.3.2.v20111125-r10461):
>> org.eclipse.persistence.exceptions.ValidationException
>>
>> Exception Description: The attribute [expiryDate] from the entity class
>> [class
>> org.picketlink.idm.jpa.model.sample.simple.AbstractCredentialTypeEntity]
>> does not specify a temporal type. A temporal type must be specified for
>> persistent fields or properties of type java.util.Date and
>> java.util.Calendar.
>>
>> javax.persistence.PersistenceException: Exception [EclipseLink-28018]
>> (Eclipse Persistence Services - 2.3.2.v20111125-r10461):
>> org.eclipse.persistence.exceptions.EntityManagerSetupException
>>
>> Exception Description: Predeployment of PersistenceUnit
>> [picketlink-default] failed.
>>
>> Internal Exception: Exception [EclipseLink-7212] (Eclipse Persistence
>> Services - 2.3.2.v20111125-r10461):
>> org.eclipse.persistence.exceptions.ValidationException
>>
>> Exception Description: The attribute [expiryDate] from the entity class
>> [class
>> org.picketlink.idm.jpa.model.sample.simple.AbstractCredentialTypeEntity]
>> does not specify a temporal type. A temporal type must be specified for
>> persistent fields or properties of type java.util.Date and
>> java.util.Calendar.
>>
>>             at
>> org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.predeploy(EntityManagerSetupImpl.java:1402)
>>
>>             at
>> org.eclipse.persistence.jpa.PersistenceProvider.createContainerEntityManagerFactory(PersistenceProvider.java:208)
>>
>>             at
>> org.glassfish.persistence.jpa.PersistenceUnitLoader.loadPU(PersistenceUnitLoader.java:206)
>>
>>             at
>> org.glassfish.persistence.jpa.PersistenceUnitLoader.<init>(PersistenceUnitLoader.java:120)
>>
>> ....
>>
>>
>>
>>
>>
>>
>>
>> Greetings,
>>
>> Giuseppe
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> hello Giuseppe!
>>
>>
>>
>> thanks for the interest in the UnifiedPush Server. Since it is standard
>> JavaEE, it should be working in Glassfish.
>>
>> However you need to configure a datasource (e.g. MySQL) inside of
>> Glassfish. Here is the details about our DS name:
>>
>>
>> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/model/jpa/src/main/resources/META-INF/persistence.xml#L23
>>
>>
>>
>>
>>
>> Did you give it a try? If there are any issues, please report them here,
>> so that we can help :)
>>
>>
>>
>> Greetings,
>>
>> Matthias
>>
>>
>>
>>
>>
>> On Wed, Jun 25, 2014 at 10:24 AM, Giuseppe Sciacca <g.sciacca at glauco.it
>> > wrote:
>>
>> Hi,
>>
>>    sorry for my english :P
>>
>>
>>
>> ?The UnifiedPush Server on Glassfish?
>>
>>
>>
>> it?s possible ?
>>
>> is there some tutorial?
>>
>>
>>
>>
>>
>> thank?s a lot
>>
>>
>>
>> GiuScia
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> sessions: http://www.slideshare.net/mwessendorf
>> twitter: http://twitter.com/mwessendorf
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>



-- 
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-dev/attachments/20140626/ad95c722/attachment-0001.html 

From giuseppe.sciacca at gmail.com  Thu Jun 26 10:22:40 2014
From: giuseppe.sciacca at gmail.com (Giuseppe Sciacca)
Date: Thu, 26 Jun 2014 16:22:40 +0200
Subject: [aerogear-dev] Aerogear - The UnifiedPush Server on Glassfish
In-Reply-To: <CAAg5f2QB2M9k5DoanbjZ=ujXuYPpQF691DGWc5oKd55uf5VRPw@mail.gmail.com>
References: <64b09d313cac4d468b7da713918d3897@ServerMail2.ids-unitelm.it>
	<CAAg5f2TS5kBbYrqujSa5=eyVWwJT4mY152cNg7BOysHVmyH2Vw@mail.gmail.com>
	<CAAg5f2QB2M9k5DoanbjZ=ujXuYPpQF691DGWc5oKd55uf5VRPw@mail.gmail.com>
Message-ID: <CAGKt_JEaDVLccAsXYVtUNmSk7b0t33fRYjuGSor6+G6-8iODaQ@mail.gmail.com>

thank's

Giuseppe.

2014-06-26 13:55 GMT+02:00 Matthias Wessendorf <matzew at apache.org>:
> Hello Giuseppe,
>
> here is the PicketLink bug:
> https://issues.jboss.org/browse/PLINK-514
>
> -Matthias
>
>
>
> On Thu, Jun 26, 2014 at 7:37 AM, Matthias Wessendorf <matzew at apache.org>
> wrote:
>>
>> Hello Giuseppe!
>>
>> thanks for reporting the issue. In the 0.10.x series we are using
>> Picketlink for security (mainly auth of the user), but it looks like the
>> version we are using has an issue w/ EclipseLink that is used as Glassfish's
>> JPA Provider. I will report that issue to the Picketlink team. Perhaps there
>> is a way to get a patched version of the 0.10x series. We will keep you
>> posted.
>>
>>
>> On the master branch (0.11.x) series we are no longer using Picketlink, we
>> are using Keycloak, but I don't see a Glassfish adapter for Keycloak at the
>> moment.
>>
>>
>> Besides these issues, there is still an option to use the UnifiedPush
>> Server:
>> * On the cloud, via OpenShift (it's free to get an OpenShift account)
>> * Via JBoss AS / EAP
>>
>> Hope that helps for now
>>
>> -Matthias
>>
>>
>>
>>
>>
>> On Thu, Jun 26, 2014 at 3:54 AM, Giuseppe Sciacca <g.sciacca at glauco.it>
>> wrote:
>>>
>>> Hi Matthias,
>>>
>>>
>>>
>>>
>>>
>>>    thank's for all.
>>>
>>>
>>>
>>> this is a part of my log :(
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> [#|2014-06-26T09:39:19.315+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=45;_ThreadName=Thread-2;|Exception
>>> while visiting org/jboss/aerogear/security/auth/AuthenticationManager.class
>>> of size 335
>>>
>>> java.lang.NullPointerException
>>>
>>>             at
>>> org.glassfish.hk2.classmodel.reflect.impl.TypesImpl.getType(TypesImpl.java:78)
>>>
>>>             at
>>> org.glassfish.hk2.classmodel.reflect.impl.ModelClassVisitor.visit(ModelClassVisitor.java:119)
>>>
>>>             at org.objectweb.asm.ClassReader.accept(Unknown Source)
>>>
>>>             at org.objectweb.asm.ClassReader.accept(Unknown Source)
>>>
>>>             at
>>> org.glassfish.hk2.classmodel.reflect.Parser$5.on(Parser.java:363)
>>>
>>>             at
>>> com.sun.enterprise.v3.server.ReadableArchiveScannerAdapter.handleEntry(ReadableArchiveScannerAdapter.java:171)
>>>
>>>             at
>>> com.sun.enterprise.v3.server.ReadableArchiveScannerAdapter.onSelectedEntries(ReadableArchiveScannerAdapter.java:133)
>>>
>>>             at
>>> org.glassfish.hk2.classmodel.reflect.Parser.doJob(Parser.java:348)
>>>
>>>             at
>>> org.glassfish.hk2.classmodel.reflect.Parser.access$300(Parser.java:70)
>>>
>>>             at
>>> org.glassfish.hk2.classmodel.reflect.Parser$3.call(Parser.java:307)
>>>
>>>             at
>>> org.glassfish.hk2.classmodel.reflect.Parser$3.call(Parser.java:296)
>>>
>>>             at
>>> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
>>>
>>>             at java.util.concurrent.FutureTask.run(FutureTask.java:166)
>>>
>>>             at
>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
>>>
>>>             at
>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
>>>
>>>             at java.lang.Thread.run(Thread.java:722)
>>>
>>>
>>>
>>> ......
>>>
>>>
>>>
>>>
>>>
>>>
>>> [#|2014-06-26T09:39:22.564+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=44;_ThreadName=Thread-2;|Exception
>>> [EclipseLink-28018] (Eclipse Persistence Services - 2.3.2.v20111125-r10461):
>>> org.eclipse.persistence.exceptions.EntityManagerSetupException
>>>
>>> Exception Description: Predeployment of PersistenceUnit
>>> [picketlink-default] failed.
>>>
>>> Internal Exception: Exception [EclipseLink-7212] (Eclipse Persistence
>>> Services - 2.3.2.v20111125-r10461):
>>> org.eclipse.persistence.exceptions.ValidationException
>>>
>>> Exception Description: The attribute [expiryDate] from the entity class
>>> [class
>>> org.picketlink.idm.jpa.model.sample.simple.AbstractCredentialTypeEntity]
>>> does not specify a temporal type. A temporal type must be specified for
>>> persistent fields or properties of type java.util.Date and
>>> java.util.Calendar.
>>>
>>> javax.persistence.PersistenceException: Exception [EclipseLink-28018]
>>> (Eclipse Persistence Services - 2.3.2.v20111125-r10461):
>>> org.eclipse.persistence.exceptions.EntityManagerSetupException
>>>
>>> Exception Description: Predeployment of PersistenceUnit
>>> [picketlink-default] failed.
>>>
>>> Internal Exception: Exception [EclipseLink-7212] (Eclipse Persistence
>>> Services - 2.3.2.v20111125-r10461):
>>> org.eclipse.persistence.exceptions.ValidationException
>>>
>>> Exception Description: The attribute [expiryDate] from the entity class
>>> [class
>>> org.picketlink.idm.jpa.model.sample.simple.AbstractCredentialTypeEntity]
>>> does not specify a temporal type. A temporal type must be specified for
>>> persistent fields or properties of type java.util.Date and
>>> java.util.Calendar.
>>>
>>>             at
>>> org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.predeploy(EntityManagerSetupImpl.java:1402)
>>>
>>>             at
>>> org.eclipse.persistence.jpa.PersistenceProvider.createContainerEntityManagerFactory(PersistenceProvider.java:208)
>>>
>>>             at
>>> org.glassfish.persistence.jpa.PersistenceUnitLoader.loadPU(PersistenceUnitLoader.java:206)
>>>
>>>             at
>>> org.glassfish.persistence.jpa.PersistenceUnitLoader.<init>(PersistenceUnitLoader.java:120)
>>>
>>> ....
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Greetings,
>>>
>>> Giuseppe
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> hello Giuseppe!
>>>
>>>
>>>
>>> thanks for the interest in the UnifiedPush Server. Since it is standard
>>> JavaEE, it should be working in Glassfish.
>>>
>>> However you need to configure a datasource (e.g. MySQL) inside of
>>> Glassfish. Here is the details about our DS name:
>>>
>>>
>>> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/model/jpa/src/main/resources/META-INF/persistence.xml#L23
>>>
>>>
>>>
>>>
>>>
>>> Did you give it a try? If there are any issues, please report them here,
>>> so that we can help :)
>>>
>>>
>>>
>>> Greetings,
>>>
>>> Matthias
>>>
>>>
>>>
>>>
>>>
>>> On Wed, Jun 25, 2014 at 10:24 AM, Giuseppe Sciacca <g.sciacca at glauco.it>
>>> wrote:
>>>
>>> Hi,
>>>
>>>    sorry for my english :P
>>>
>>>
>>>
>>> "The UnifiedPush Server on Glassfish"
>>>
>>>
>>>
>>> it's possible ?
>>>
>>> is there some tutorial?
>>>
>>>
>>>
>>>
>>>
>>> thank's a lot
>>>
>>>
>>>
>>> GiuScia
>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Matthias Wessendorf
>>>
>>> blog: http://matthiaswessendorf.wordpress.com/
>>> sessions: http://www.slideshare.net/mwessendorf
>>> twitter: http://twitter.com/mwessendorf
>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> sessions: http://www.slideshare.net/mwessendorf
>> twitter: http://twitter.com/mwessendorf
>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev



-- 
Giuseppe Sciacca

From matzew at apache.org  Thu Jun 26 19:24:57 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Thu, 26 Jun 2014 19:24:57 -0400
Subject: [aerogear-dev] aerogear cordova push plugin android
	registration problem
In-Reply-To: <1403707627887-8223.post@n5.nabble.com>
References: <1403169513165-8206.post@n5.nabble.com>
	<1403275339037-8212.post@n5.nabble.com>
	<1403277859078-8214.post@n5.nabble.com>
	<1403282758706-8217.post@n5.nabble.com>
	<1403707627887-8223.post@n5.nabble.com>
Message-ID: <CAAg5f2Rbmh9WfrxdQt2-z+ds_-s_Ch2msXAthYNm-N317-yj9A@mail.gmail.com>

On Wed, Jun 25, 2014 at 10:47 AM, lb44 <
mohamed_el_amine.belmokhtar at univ-lr.fr> wrote:

> I have found the origin of my problem.
>
> Firstly, my application was including phonegap.js and cordova.js... it was
> a
> bad idea.
> Secondly, I think that when I create a projet in google console and
> activate
> notifcation push. After I had sent a notification, google server registers
> the hash of my application. Why I think that, it's cause of whenever I
> change my source code, the application no longer receives notifications.
> Whenever I have to create a new application in google console and create a
> new application and a new variant in UPS.
>

Not sure I follow, you are all set now, or is there still an issue on your
side?

-Matthias



>
>
>
>
> --
> View this message in context:
> http://aerogear-dev.1069024.n5.nabble.com/aerogear-cordova-push-plugin-android-registration-problem-tp8206p8223.html
> Sent from the aerogear-dev mailing list archive at Nabble.com.
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140626/209186b9/attachment.html 

From daniel.bevenius at gmail.com  Mon Jun 30 02:09:40 2014
From: daniel.bevenius at gmail.com (Daniel Bevenius)
Date: Mon, 30 Jun 2014 08:09:40 +0200
Subject: [aerogear-dev] Team meeting
Message-ID: <CAFJm-3G8RwoqGMmSS5q5-CK+pzS88X-3WUbE5-jvYV8PGExSog@mail.gmail.com>

Not sure there is much to discuss today as we had our face-to-face meeting
last week but just in case here is an agenda:
http://oksoclap.com/p/aerogear-team-mgt-20140630
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140630/ddd67695/attachment.html 

From matzew at apache.org  Mon Jun 30 04:00:38 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Mon, 30 Jun 2014 04:00:38 -0400
Subject: [aerogear-dev] UPS 0.11
Message-ID: <CAAg5f2R=p7WSX-JwArdk0ynMVqWtbNKjH56MQh8Mg23yn=3jgA@mail.gmail.com>

Hello,

while waiting for my flight back home I was looking over the open PRs and
added a few comments:
* https://github.com/aerogear/aerogear-unifiedpush-server/pull/250
* https://github.com/aerogear/aerogear-unifiedpush-server/pull/249
* https://github.com/aerogear/aerogear-unifiedpush-server/pull/244
* https://github.com/aerogear/aerogear-unifiedpush-server/pull/243


Besides those, there are three open tickets, which I'd like to see fixed
for the 0.11:
https://issues.jboss.org/browse/AGPUSH/fixforversion/12321883/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-issues-panel

Any thoughts?
-Matthias




-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf


-- 
Sent from Gmail Mobile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140630/58d35088/attachment.html 

From scm.blanc at gmail.com  Mon Jun 30 06:48:57 2014
From: scm.blanc at gmail.com (Sebastien Blanc)
Date: Mon, 30 Jun 2014 12:48:57 +0200
Subject: [aerogear-dev] Team meeting
In-Reply-To: <CAFJm-3G8RwoqGMmSS5q5-CK+pzS88X-3WUbE5-jvYV8PGExSog@mail.gmail.com>
References: <CAFJm-3G8RwoqGMmSS5q5-CK+pzS88X-3WUbE5-jvYV8PGExSog@mail.gmail.com>
Message-ID: <CAD_dpu2g07MH0HMvxtJbUB6a_HYxOW1vTKyJ30agKQmHpvg79Q@mail.gmail.com>

Maybe we can do it tomorrow, that give us more time to debrief and work on
items for the agenda ?
Team ?



On Mon, Jun 30, 2014 at 8:09 AM, Daniel Bevenius <daniel.bevenius at gmail.com>
wrote:

> Not sure there is much to discuss today as we had our face-to-face meeting
> last week but just in case here is an agenda:
> http://oksoclap.com/p/aerogear-team-mgt-20140630
>
>
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140630/dfb6f53e/attachment.html 

From daniel.bevenius at gmail.com  Mon Jun 30 06:59:15 2014
From: daniel.bevenius at gmail.com (Daniel Bevenius)
Date: Mon, 30 Jun 2014 12:59:15 +0200
Subject: [aerogear-dev] Team meeting
In-Reply-To: <CAD_dpu2g07MH0HMvxtJbUB6a_HYxOW1vTKyJ30agKQmHpvg79Q@mail.gmail.com>
References: <CAFJm-3G8RwoqGMmSS5q5-CK+pzS88X-3WUbE5-jvYV8PGExSog@mail.gmail.com>
	<CAD_dpu2g07MH0HMvxtJbUB6a_HYxOW1vTKyJ30agKQmHpvg79Q@mail.gmail.com>
Message-ID: <CAFJm-3E4Gr3Q=43TAbKkHygBENEzw770_7aQ__gKDjbFWmOBGg@mail.gmail.com>

Sounds good to me.


On 30 June 2014 12:48, Sebastien Blanc <scm.blanc at gmail.com> wrote:

> Maybe we can do it tomorrow, that give us more time to debrief and work on
> items for the agenda ?
> Team ?
>
>
>
> On Mon, Jun 30, 2014 at 8:09 AM, Daniel Bevenius <
> daniel.bevenius at gmail.com> wrote:
>
>> Not sure there is much to discuss today as we had our face-to-face
>> meeting last week but just in case here is an agenda:
>> http://oksoclap.com/p/aerogear-team-mgt-20140630
>>
>>
>>
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140630/a57d835c/attachment-0001.html 

From corinnekrych at gmail.com  Mon Jun 30 08:22:14 2014
From: corinnekrych at gmail.com (Corinne Krych)
Date: Mon, 30 Jun 2014 14:22:14 +0200
Subject: [aerogear-dev] Team meeting
In-Reply-To: <CAFJm-3E4Gr3Q=43TAbKkHygBENEzw770_7aQ__gKDjbFWmOBGg@mail.gmail.com>
References: <CAFJm-3G8RwoqGMmSS5q5-CK+pzS88X-3WUbE5-jvYV8PGExSog@mail.gmail.com>
	<CAD_dpu2g07MH0HMvxtJbUB6a_HYxOW1vTKyJ30agKQmHpvg79Q@mail.gmail.com>
	<CAFJm-3E4Gr3Q=43TAbKkHygBENEzw770_7aQ__gKDjbFWmOBGg@mail.gmail.com>
Message-ID: <23D16730-E4DF-45F9-8617-8F3741CA5790@gmail.com>

+1
On 30 Jun 2014, at 12:59, Daniel Bevenius <daniel.bevenius at gmail.com> wrote:

> Sounds good to me.
> 
> 
> On 30 June 2014 12:48, Sebastien Blanc <scm.blanc at gmail.com> wrote:
> Maybe we can do it tomorrow, that give us more time to debrief and work on items for the agenda ?
> Team ? 
> 
> 
> 
> On Mon, Jun 30, 2014 at 8:09 AM, Daniel Bevenius <daniel.bevenius at gmail.com> wrote:
> Not sure there is much to discuss today as we had our face-to-face meeting last week but just in case here is an agenda: 
> http://oksoclap.com/p/aerogear-team-mgt-20140630
> 
> 
> 
> 
> 
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> 
> 
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> 
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev



From lholmqui at redhat.com  Mon Jun 30 08:25:40 2014
From: lholmqui at redhat.com (Luke Holmquist)
Date: Mon, 30 Jun 2014 08:25:40 -0400 (EDT)
Subject: [aerogear-dev] Team meeting
In-Reply-To: <CAD_dpu2g07MH0HMvxtJbUB6a_HYxOW1vTKyJ30agKQmHpvg79Q@mail.gmail.com>
References: <CAFJm-3G8RwoqGMmSS5q5-CK+pzS88X-3WUbE5-jvYV8PGExSog@mail.gmail.com>
	<CAD_dpu2g07MH0HMvxtJbUB6a_HYxOW1vTKyJ30agKQmHpvg79Q@mail.gmail.com>
Message-ID: <AAB1D8F2-7819-4F48-A551-0401BD3631DB@redhat.com>

+1


Sent from my iPhone

> On Jun 30, 2014, at 6:50 AM, Sebastien Blanc <scm.blanc at gmail.com> wrote:
> 
> Maybe we can do it tomorrow, that give us more time to debrief and work on items for the agenda ?
> Team ? 
> 
> 
> 
>> On Mon, Jun 30, 2014 at 8:09 AM, Daniel Bevenius <daniel.bevenius at gmail.com> wrote:
>> Not sure there is much to discuss today as we had our face-to-face meeting last week but just in case here is an agenda: 
>> http://oksoclap.com/p/aerogear-team-mgt-20140630
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> 
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140630/0feeb61f/attachment.html 

From bruno at abstractj.org  Mon Jun 30 08:27:55 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Mon, 30 Jun 2014 08:27:55 -0400
Subject: [aerogear-dev] Team meeting
In-Reply-To: <23D16730-E4DF-45F9-8617-8F3741CA5790@gmail.com>
References: <CAFJm-3G8RwoqGMmSS5q5-CK+pzS88X-3WUbE5-jvYV8PGExSog@mail.gmail.com>
	<CAD_dpu2g07MH0HMvxtJbUB6a_HYxOW1vTKyJ30agKQmHpvg79Q@mail.gmail.com>
	<CAFJm-3E4Gr3Q=43TAbKkHygBENEzw770_7aQ__gKDjbFWmOBGg@mail.gmail.com>
	<23D16730-E4DF-45F9-8617-8F3741CA5790@gmail.com>
Message-ID: <20140630122755.GA1605@abstractj.org>

Please, let's do it tomorrow.

On 2014-06-30, Corinne Krych wrote:
> +1
> On 30 Jun 2014, at 12:59, Daniel Bevenius <daniel.bevenius at gmail.com> wrote:
>
> > Sounds good to me.
> >
> >
> > On 30 June 2014 12:48, Sebastien Blanc <scm.blanc at gmail.com> wrote:
> > Maybe we can do it tomorrow, that give us more time to debrief and work on items for the agenda ?
> > Team ?
> >
> >
> >
> > On Mon, Jun 30, 2014 at 8:09 AM, Daniel Bevenius <daniel.bevenius at gmail.com> wrote:
> > Not sure there is much to discuss today as we had our face-to-face meeting last week but just in case here is an agenda:
> > http://oksoclap.com/p/aerogear-team-mgt-20140630
> >
> >
> >
> >
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev

--

abstractj

From jbalunas at redhat.com  Mon Jun 30 08:48:35 2014
From: jbalunas at redhat.com (Jay Balunas)
Date: Mon, 30 Jun 2014 08:48:35 -0400
Subject: [aerogear-dev] Team meeting
In-Reply-To: <20140630122755.GA1605@abstractj.org>
References: <CAFJm-3G8RwoqGMmSS5q5-CK+pzS88X-3WUbE5-jvYV8PGExSog@mail.gmail.com>
	<CAD_dpu2g07MH0HMvxtJbUB6a_HYxOW1vTKyJ30agKQmHpvg79Q@mail.gmail.com>
	<CAFJm-3E4Gr3Q=43TAbKkHygBENEzw770_7aQ__gKDjbFWmOBGg@mail.gmail.com>
	<23D16730-E4DF-45F9-8617-8F3741CA5790@gmail.com>
	<20140630122755.GA1605@abstractj.org>
Message-ID: <39CF4D44-D667-4377-986F-538CCFD217D6@redhat.com>

+1 - I'll shift it on the project calendar

On Jun 30, 2014, at 8:27 AM, Bruno Oliveira <bruno at abstractj.org> wrote:

> Please, let's do it tomorrow.
> 
> On 2014-06-30, Corinne Krych wrote:
>> +1
>> On 30 Jun 2014, at 12:59, Daniel Bevenius <daniel.bevenius at gmail.com> wrote:
>> 
>>> Sounds good to me.
>>> 
>>> 
>>> On 30 June 2014 12:48, Sebastien Blanc <scm.blanc at gmail.com> wrote:
>>> Maybe we can do it tomorrow, that give us more time to debrief and work on items for the agenda ?
>>> Team ?
>>> 
>>> 
>>> 
>>> On Mon, Jun 30, 2014 at 8:09 AM, Daniel Bevenius <daniel.bevenius at gmail.com> wrote:
>>> Not sure there is much to discuss today as we had our face-to-face meeting last week but just in case here is an agenda:
>>> http://oksoclap.com/p/aerogear-team-mgt-20140630
>>> 
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>> 
>>> 
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>> 
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> 
>> 
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> 
> --
> 
> abstractj
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev



From lukas.fryc at gmail.com  Mon Jun 30 11:35:44 2014
From: lukas.fryc at gmail.com (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=)
Date: Mon, 30 Jun 2014 11:35:44 -0400
Subject: [aerogear-dev] UPS 0.11
In-Reply-To: <CAAg5f2R=p7WSX-JwArdk0ynMVqWtbNKjH56MQh8Mg23yn=3jgA@mail.gmail.com>
References: <CAAg5f2R=p7WSX-JwArdk0ynMVqWtbNKjH56MQh8Mg23yn=3jgA@mail.gmail.com>
Message-ID: <CAEroY36RtYfNPha5WrfhBq_uSjW9v+vBtzmHSoiw4C7dvNSRNw@mail.gmail.com>

Hey Matthias,

all the UnifiedPush-admin issues were either resolved or they are waiting
to be merged.

Thanks goes mainly to Erik.

~ Lukas


On Mon, Jun 30, 2014 at 4:00 AM, Matthias Wessendorf <matzew at apache.org>
wrote:

> Hello,
>
> while waiting for my flight back home I was looking over the open PRs and
> added a few comments:
> * https://github.com/aerogear/aerogear-unifiedpush-server/pull/250
> * https://github.com/aerogear/aerogear-unifiedpush-server/pull/249
> * https://github.com/aerogear/aerogear-unifiedpush-server/pull/244
> * https://github.com/aerogear/aerogear-unifiedpush-server/pull/243
>
>
> Besides those, there are three open tickets, which I'd like to see fixed
> for the 0.11:
>
> https://issues.jboss.org/browse/AGPUSH/fixforversion/12321883/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-issues-panel
>
> Any thoughts?
> -Matthias
>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>
>
> --
> Sent from Gmail Mobile
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140630/632e708d/attachment.html 

From bruno at abstractj.org  Mon Jun 30 12:14:44 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Mon, 30 Jun 2014 13:14:44 -0300
Subject: [aerogear-dev] UPS 0.11
In-Reply-To: <CAAg5f2R=p7WSX-JwArdk0ynMVqWtbNKjH56MQh8Mg23yn=3jgA@mail.gmail.com>
References: <CAAg5f2R=p7WSX-JwArdk0ynMVqWtbNKjH56MQh8Mg23yn=3jgA@mail.gmail.com>
Message-ID: <20140630161444.GA14602@abstractj.org>

Hi Matthias, I think we're in a good shape. We have 3 PR to be reviewed:

- https://github.com/aerogear/aerogear-unifiedpush-server/pull/154
I would vote to postpone it for further releases

- https://github.com/aerogear/aerogear-unifiedpush-server/pull/250
It seems like ready to go

- https://github.com/aerogear/aerogear-unifiedpush-server/pull/253
Need some feedback

Regarding the Keycloak integration, I reasssigned AGPUSH-568 to myself,
but let me know if you want to be in charge of it.

On 2014-06-30, Matthias Wessendorf wrote:
> Hello,
>
> while waiting for my flight back home I was looking over the open PRs and
> added a few comments:
> * https://github.com/aerogear/aerogear-unifiedpush-server/pull/250
> * https://github.com/aerogear/aerogear-unifiedpush-server/pull/249
> * https://github.com/aerogear/aerogear-unifiedpush-server/pull/244
> * https://github.com/aerogear/aerogear-unifiedpush-server/pull/243
>
>
> Besides those, there are three open tickets, which I'd like to see fixed
> for the 0.11:
> https://issues.jboss.org/browse/AGPUSH/fixforversion/12321883/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-issues-panel
>
> Any thoughts?
> -Matthias
>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>
>
> --
> Sent from Gmail Mobile

> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


--

abstractj

From scm.blanc at gmail.com  Mon Jun 30 19:20:41 2014
From: scm.blanc at gmail.com (Sebastien Blanc)
Date: Tue, 1 Jul 2014 01:20:41 +0200
Subject: [aerogear-dev] UPS 0.11
In-Reply-To: <20140630161444.GA14602@abstractj.org>
References: <CAAg5f2R=p7WSX-JwArdk0ynMVqWtbNKjH56MQh8Mg23yn=3jgA@mail.gmail.com>
	<20140630161444.GA14602@abstractj.org>
Message-ID: <CAD_dpu3CKrVY5cihrLRnKB9CFSS2pnjnWB5=+FP8t9D_F+mUtg@mail.gmail.com>

On Mon, Jun 30, 2014 at 6:14 PM, Bruno Oliveira <bruno at abstractj.org> wrote:

> Hi Matthias, I think we're in a good shape. We have 3 PR to be reviewed:
>
> - https://github.com/aerogear/aerogear-unifiedpush-server/pull/154
> I would vote to postpone it for further releases
>
+1

>
> - https://github.com/aerogear/aerogear-unifiedpush-server/pull/250
> It seems like ready to go
>
+1 (just a small ui thing that could be better but we can see that later)

>
> - https://github.com/aerogear/aerogear-unifiedpush-server/pull/253
> Need some feedback
>
feedback given

>
> Regarding the Keycloak integration, I reasssigned AGPUSH-568 to myself,
> but let me know if you want to be in charge of it.
>
> On 2014-06-30, Matthias Wessendorf wrote:
> > Hello,
> >
> > while waiting for my flight back home I was looking over the open PRs and
> > added a few comments:
> > * https://github.com/aerogear/aerogear-unifiedpush-server/pull/250
> > * https://github.com/aerogear/aerogear-unifiedpush-server/pull/249
> > * https://github.com/aerogear/aerogear-unifiedpush-server/pull/244
> > * https://github.com/aerogear/aerogear-unifiedpush-server/pull/243
> >
> >
> > Besides those, there are three open tickets, which I'd like to see fixed
> > for the 0.11:
> >
> https://issues.jboss.org/browse/AGPUSH/fixforversion/12321883/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-issues-panel
> >
> > Any thoughts?
> > -Matthias
> >
> >
> >
> >
> > --
> > Matthias Wessendorf
> >
> > blog: http://matthiaswessendorf.wordpress.com/
> > sessions: http://www.slideshare.net/mwessendorf
> > twitter: http://twitter.com/mwessendorf
> >
> >
> > --
> > Sent from Gmail Mobile
>
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> --
>
> abstractj
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140701/ef8a59d3/attachment-0001.html