From daniel.bevenius at gmail.com Mon Dec 2 03:38:15 2013 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Mon, 2 Dec 2013 09:38:15 +0100 Subject: [aerogear-dev] Team Meeting Agenda Message-ID: http://oksoclap.com/p/aerogear-team-mgt-20131202 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20131202/cc8ef723/attachment.html From scm.blanc at gmail.com Mon Dec 2 10:23:09 2013 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Mon, 2 Dec 2013 16:23:09 +0100 Subject: [aerogear-dev] Team Meeting Agenda In-Reply-To: References: Message-ID: Et voila : (04:22:37 PM) jbott: Meeting ended Mon Dec 2 15:14:41 2013 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) (04:22:37 PM) jbott: Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2013/aerogear.2013-12-02-14.53.html (04:22:37 PM) jbott: Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2013/aerogear.2013-12-02-14.53.txt (04:22:37 PM) jbott: Log: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2013/aerogear.2013-12-02-14.53.log.html On Mon, Dec 2, 2013 at 9:38 AM, Daniel Bevenius wrote: > http://oksoclap.com/p/aerogear-team-mgt-20131202 > > > > _______________________________________________ > 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/20131202/7e6447f1/attachment.html From daniel at passos.me Mon Dec 2 12:09:20 2013 From: daniel at passos.me (Daniel Passos) Date: Mon, 2 Dec 2013 15:09:20 -0200 Subject: [aerogear-dev] [aerogear-android] Skip SQLStoreTest when running on OSX and Java 1.7 In-Reply-To: <1B6AF825-071D-4190-B865-01FC4EE6161D@redhat.com> References: <1B6AF825-071D-4190-B865-01FC4EE6161D@redhat.com> Message-ID: I'm not sure if this is the best solution but agreed with workaround for now. --? Daniel Passos On November 22, 2013 at 3:41:23 PM, Tadeas Kriz (tkriz at redhat.com) wrote: Hey, I?ve been investigating the issue with SQLStore testing through Robolectric and this is what I?ve found. Those tests run correctly on linux with both Java 1.6 and Java 1.7 and also works on Mac OS X with Java 1.6. This unfortunately doesn?t apply for the Java 1.7 on Mac and the test is failing. And because I think that this test should definitely not be @Ignore-d all the time, I?ve come up with following solution. In JUnit, there?s a way to decide whether to run a test or not in runtime, based on org.junit.Assume. This way, we could easily ignore the SQLStoreTest when running on Mac OS X with Java 1.7, but leave it on other platforms. I?ve already taken the liberty to write this down and I?ve bundled it into the PR [1] which is fixing the doubly-called Callback#onSuccess bug (AGDROID-150). What do you guys think about this solution, or should I say workaround? Of course it?s not perfect, it would be cool if we could run even the SQLStoreTest on all platforms without any difference, but right now it seems to be a incompatibility of SQLite with Mac?s Java 1.7. 1 -?https://github.com/aerogear/aerogear-android/pull/120 ? Tadeas Kriz tkriz at redhat.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/20131202/986e5082/attachment.html From qmx at qmx.me Mon Dec 2 21:21:31 2013 From: qmx at qmx.me (Douglas Campos) Date: Tue, 3 Dec 2013 00:21:31 -0200 Subject: [aerogear-dev] Data Sync braindump Message-ID: <20131203022131.GD2140@rohan.local> Howdy! Since we're starting the data-sync sprint, I'd like to bring some of the ideas that born from the research I've been doing. Note that those are only ideas that will be validated by a PoC or something like this (which I'm planning to continue working on after I'm back from PTO) I envision a layered approach: 1) CouchDB Sync Protocol This is an approach that I really like a lot - it has lots of common things with git (keeping SHAs of the document's state and history of changes (until you compact your history)). The main advantage is that we can re-use all the nice algorithms we already have on the git lands to solve conflicts. 2) OT/EC This is really nice & well-known, but I think it would apply better for individual fields into a document. 3) Crypto signatures We could have ed25519 signatures on the changes, making it potentially safer to decide who should win a change conflict based on rules that goes beyond simple merging strategies (business roles?) All this 3 layers could live on top of a very simple JSON protocol, which would allow us to evolve it gradually (I know this is prone to not be super efficient, but I don't want to optimize prematurely, and JSON compresses really well) Thoughts? Don't forget to read Summer's thread on this. (can someone reply with the link?) -- qmx -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 527 bytes Desc: not available Url : http://lists.jboss.org/pipermail/aerogear-dev/attachments/20131203/b5fdf23b/attachment.bin From scm.blanc at gmail.com Tue Dec 3 02:39:01 2013 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Tue, 3 Dec 2013 08:39:01 +0100 Subject: [aerogear-dev] Data Sync braindump In-Reply-To: <20131203022131.GD2140@rohan.local> References: <20131203022131.GD2140@rohan.local> Message-ID: Thanks Qmx for starting this thread. Here the link to Summer's thread : http://lists.jboss.org/pipermail/aerogear-dev/2013-March/002090.html On Tue, Dec 3, 2013 at 3:21 AM, Douglas Campos wrote: > Howdy! > > Since we're starting the data-sync sprint, I'd like to bring some of the > ideas that born from the research I've been doing. > > Note that those are only ideas that will be validated by a PoC or > something like this (which I'm planning to continue working on after I'm > back from PTO) > > I envision a layered approach: > > 1) CouchDB Sync Protocol > > This is an approach that I really like a lot - it has lots of common > things with git (keeping SHAs of the document's state and history of > changes (until you compact your history)). The main advantage is that we > can re-use all the nice algorithms we already have on the git lands to > solve conflicts. > > 2) OT/EC > > This is really nice & well-known, but I think it would apply better for > individual fields into a document. > > 3) Crypto signatures > > We could have ed25519 signatures on the changes, making it potentially > safer to decide who should win a change conflict based on rules that > goes beyond simple merging strategies (business roles?) > > All this 3 layers could live on top of a very simple JSON protocol, > which would allow us to evolve it gradually (I know this is prone to not > be super efficient, but I don't want to optimize prematurely, and JSON > compresses really well) > > Thoughts? > > Don't forget to read Summer's thread on this. (can someone reply with > the link?) > > -- > qmx > _______________________________________________ > 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/20131203/eff8e347/attachment.html From edewit at redhat.com Tue Dec 3 04:37:53 2013 From: edewit at redhat.com (Erik Jan de Wit) Date: Tue, 3 Dec 2013 10:37:53 +0100 Subject: [aerogear-dev] Data Sync braindump In-Reply-To: References: <20131203022131.GD2140@rohan.local> Message-ID: <193C375A-DDAD-4EB4-A78C-936CF042DE75@redhat.com> Hi, I like the topic of this thread so just wanted to add my 2 cents. As you know when I was with Errai we have implemented operation transforms and data sync and we have had a lot of discussions around these. OT/EC is really nice, but it's a totally different use case then offline sync. The idea is that you only send your operations something like Insert[0, "x"] meaning on position 0 insert a x as you can see this will only work well if you have a very current version of the document that you are editing. The sync from Errai is based on JPA and does merging based upon fields in the Entity on the server. By doing this the chance of conflicts is smaller but still there can be conflicts and those must be handled by a user. So we need to build a way to sent the different states back to the user. We could also create something that does a peer to peer sync (eliminating the need for a central server) couchDB has a protocol that does that I think. Maybe we should think of use cases that we want to support like in Summer's thread and maybe we need more then one solution. Cheers, Erik Jan On 3 Dec,2013, at 8:39 , Sebastien Blanc wrote: > Thanks Qmx for starting this thread. > Here the link to Summer's thread : > http://lists.jboss.org/pipermail/aerogear-dev/2013-March/002090.html > > > > On Tue, Dec 3, 2013 at 3:21 AM, Douglas Campos wrote: > Howdy! > > Since we're starting the data-sync sprint, I'd like to bring some of the > ideas that born from the research I've been doing. > > Note that those are only ideas that will be validated by a PoC or > something like this (which I'm planning to continue working on after I'm > back from PTO) > > I envision a layered approach: > > 1) CouchDB Sync Protocol > > This is an approach that I really like a lot - it has lots of common > things with git (keeping SHAs of the document's state and history of > changes (until you compact your history)). The main advantage is that we > can re-use all the nice algorithms we already have on the git lands to > solve conflicts. > > 2) OT/EC > > This is really nice & well-known, but I think it would apply better for > individual fields into a document. > > 3) Crypto signatures > > We could have ed25519 signatures on the changes, making it potentially > safer to decide who should win a change conflict based on rules that > goes beyond simple merging strategies (business roles?) > > All this 3 layers could live on top of a very simple JSON protocol, > which would allow us to evolve it gradually (I know this is prone to not > be super efficient, but I don't want to optimize prematurely, and JSON > compresses really well) > > Thoughts? > > Don't forget to read Summer's thread on this. (can someone reply with > the link?) > > -- > qmx > _______________________________________________ > 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/20131203/55696c91/attachment-0001.html From scm.blanc at gmail.com Tue Dec 3 05:54:14 2013 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Tue, 3 Dec 2013 11:54:14 +0100 Subject: [aerogear-dev] UPS User Management - Reloaded Message-ID: Hi, I wanted to start a fresh new thread about user management in the Unified Push Server, please check below the proposition I made for the next release (0.10.0) , feel free to comment / ask questions etc ... (https://gist.github.com/sebastienblanc/6547605) User Management for the Aerogear Unfied Push Server Introduction The goal of this document is to describe how the User Management will be implemented in the Unified Push Server. Currently there is only one user created by default when installing UPS. Having the possibility to create multiple users is a "Must Have" and should be manageable from the Admin Console. Some roles should also be introduced Roles / Permissions There will be 3 different roles in this first version : - *Admin* : The Admin is like the super-user, it can access all the features of UPS including the creation of users. - *Developer* : The developer can create/read/update and delete Applications/variants. - *viewer* : Can only 'Read', can be useful for monitoring apps (or for the future UPS Forge Plugin). Role / actionCreateUpdateReadDeleteReset pwdUser MngtAdminXXXXXXDeveloperXXX XXViewer X User management flow An Admin can create new user by providing a loginName. This will be possible through : - The console - The REST service Password Management At creation, the user will have a default password , i.e 123. First Login When logging in for this first time, the new created user will be prompted to change his password. Reset Password Instruction If a user wants to reset his password, he has to request it manually (email, post pigeon ...) to an admin. The password will be again the default one and the user will have to change it again when logging in. Scope of the current permissions Currently, a authenticated user can see all the applications / variants / installations, no matter he is the author or not. There is also no concept of groups, that may come in the future releases. Security Implementation Currently, it would be possible to implement this using Aerogear-Security-Picketlink and with some raw Picketlink : - Login / Logout / Registration : AG-Security offers all we need - Roles and permissions : AG-Security offers a secures annotation that can be used to protect the endpoints. I know there are some concerns about this last points (Role escalation etc ...) and would like to have advice / feedback on what is acceptable / doable for the 0.10.0 release (15/01). -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20131203/44963987/attachment.html From bruno at abstractj.org Tue Dec 3 06:21:25 2013 From: bruno at abstractj.org (Bruno Oliveira) Date: Tue, 3 Dec 2013 09:21:25 -0200 Subject: [aerogear-dev] UPS User Management - Reloaded In-Reply-To: References: Message-ID: Hi Sebi, few comments inline. On December 3, 2013 at 8:54:22 AM, Sebastien Blanc (scm.blanc at gmail.com) wrote: > >Hi, >I wanted to start a fresh new thread about user management in the Unified >Push Server, please check below the proposition I made for the next release >(0.10.0) , feel free to comment / ask questions etc ... > >(https://gist.github.com/sebastienblanc/6547605) >User Management for the Aerogear Unfied Push >Server >Introduction > >The goal of this document is to describe how the User Management will be >implemented in the Unified Push Server. Currently there is only one user >created by default when installing UPS. Having the possibility to create >multiple users is a "Must Have" and should be manageable from the Admin >Console. Some roles should also be introduced >Roles / >Permissions > >There will be 3 different roles in this first version : > >- *Admin* : The Admin is like the super-user, it can access all the >features of UPS including the creation of users. >- *Developer* : The developer can create/read/update and delete >Applications/variants. >- *viewer* : Can only 'Read', can be useful for monitoring apps (or for >the future UPS Forge Plugin). Here the Developer role will be able to reset user?s password? Or his own password? > >Role / actionCreateUpdateReadDeleteReset pwdUser MngtAdminXXXXXXDeveloperXXX >XXViewer X >User >management flow > >An Admin can create new user by providing a loginName. This will be >possible through : > >- The console >- The REST service > >Password >Management > >At creation, the user will have a default password , i.e 123. I think here is the problem which we can?t delay anymore. At the creation we should probably send an e-mail with the encrypted url for the password setup. Is not the same thing, but the url approach can be something similar to what SP does to register channels. >First Login > >When logging in for this first time, the new created user will be prompted >to change his password. Same thing there, I think users should be able to reset their own password. >Reset >Password Instruction > >If a user wants to reset his password, he has to request it manually >(email, post pigeon ...) to an admin. The password will be again the >default one and the user will have to change it again when logging in. >Scope >of the current permissions > >Currently, a authenticated user can see all the applications / variants / >installations, no matter he is the author or not. There is also no concept >of groups, that may come in the future releases. >Security >Implementation > >Currently, it would be possible to implement this using >Aerogear-Security-Picketlink and with some raw Picketlink : > >- Login / Logout / Registration : AG-Security offers all we need >- Roles and permissions : AG-Security offers a secures annotation that >can be used to protect the endpoints. > >I know there are some concerns about this last points (Role escalation etc >...) and would like to have advice / feedback on what is acceptable / >doable for the 0.10.0 release (15/01). >_______________________________________________ >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 Dec 3 06:32:51 2013 From: bruno at abstractj.org (Bruno Oliveira) Date: Tue, 3 Dec 2013 09:32:51 -0200 Subject: [aerogear-dev] Data Sync braindump In-Reply-To: <20131203022131.GD2140@rohan.local> References: <20131203022131.GD2140@rohan.local> Message-ID: My 2 cents here, ed25519 is the best choice and we could do it with kalium (https://github.com/abstractj/kalium), but that would require the installation of C library, IMO a drawback. Another alternative would be to implement ed25519 on top of ECDSA, because the only curves supported by BouncyCastle are http://www.bouncycastle.org/wiki/display/JA1/Supported+Curves+(ECDSA+and+ECGOST). So my suggestion is: start simple with the curves supported by BC, slow or not. Improve later.? On December 3, 2013 at 12:21:41 AM, Douglas Campos (qmx at qmx.me) wrote: > 3) Crypto signatures > > We could have ed25519 signatures on the changes, making it potentially > safer to decide who should win a change conflict based on rules that > goes beyond simple merging strategies (business roles?) --? abstractj From hbons at redhat.com Tue Dec 3 06:47:58 2013 From: hbons at redhat.com (Hylke Bons) Date: Tue, 03 Dec 2013 11:47:58 +0000 Subject: [aerogear-dev] UPS User Management - Reloaded In-Reply-To: References: Message-ID: <529DC4EE.3050506@redhat.com> > > At creation, the user will have a default password , i.e 123. Can't we have a "create password for admin user" dialogue on first use? This saves a step in having people to having to read and remember something from another page, and i don't think it's any more or less secure. Hylke From bruno at abstractj.org Tue Dec 3 07:02:26 2013 From: bruno at abstractj.org (Bruno Oliveira) Date: Tue, 3 Dec 2013 10:02:26 -0200 Subject: [aerogear-dev] Data Sync braindump In-Reply-To: References: <20131203022131.GD2140@rohan.local> Message-ID: Hi, the following branch was started to track the ideas about data sync and goals to the next release:?https://github.com/aerogear/aerogear.org/tree/data-sync On December 3, 2013 at 5:39:10 AM, Sebastien Blanc (scm.blanc at gmail.com) wrote: > Thanks Qmx for starting this thread. > Here the link to Summer's thread : > http://lists.jboss.org/pipermail/aerogear-dev/2013-March/002090.html --? abstractj From lholmqui at redhat.com Tue Dec 3 09:42:53 2013 From: lholmqui at redhat.com (Lucas Holmquist) Date: Tue, 3 Dec 2013 09:42:53 -0500 Subject: [aerogear-dev] UPS User Management - Reloaded In-Reply-To: References: Message-ID: On Dec 3, 2013, at 6:21 AM, Bruno Oliveira wrote: > Hi Sebi, few comments inline. > > On December 3, 2013 at 8:54:22 AM, Sebastien Blanc (scm.blanc at gmail.com) wrote: >> >> Hi, >> I wanted to start a fresh new thread about user management in the Unified >> Push Server, please check below the proposition I made for the next release >> (0.10.0) , feel free to comment / ask questions etc ... >> >> (https://gist.github.com/sebastienblanc/6547605) >> User Management for the Aerogear Unfied Push >> Server >> Introduction >> >> The goal of this document is to describe how the User Management will be >> implemented in the Unified Push Server. Currently there is only one user >> created by default when installing UPS. Having the possibility to create >> multiple users is a "Must Have" and should be manageable from the Admin >> Console. Some roles should also be introduced >> Roles / >> Permissions >> >> There will be 3 different roles in this first version : >> >> - *Admin* : The Admin is like the super-user, it can access all the >> features of UPS including the creation of users. >> - *Developer* : The developer can create/read/update and delete >> Applications/variants. >> - *viewer* : Can only 'Read', can be useful for monitoring apps (or for >> the future UPS Forge Plugin). > > Here the Developer role will be able to reset user?s password? Or his own password? > >> >> Role / actionCreateUpdateReadDeleteReset pwdUser MngtAdminXXXXXXDeveloperXXX >> XXViewer X >> User >> management flow >> >> An Admin can create new user by providing a loginName. This will be >> possible through : >> >> - The console >> - The REST service >> >> Password >> Management >> >> At creation, the user will have a default password , i.e 123. > > I think here is the problem which we can?t delay anymore. At the creation we should probably send an e-mail with the encrypted url for the password setup. > > Is not the same thing, but the url approach can be something similar to what SP does to register channels. i'm not sure we should put the email functionality in the UPS, but we could have a "create a secure link" option that the admin can then email out > >> First Login >> >> When logging in for this first time, the new created user will be prompted >> to change his password. > > Same thing there, I think users should be able to reset their own password. > >> Reset >> Password Instruction >> >> If a user wants to reset his password, he has to request it manually >> (email, post pigeon ...) to an admin. The password will be again the >> default one and the user will have to change it again when logging in. >> Scope >> of the current permissions >> >> Currently, a authenticated user can see all the applications / variants / >> installations, no matter he is the author or not. There is also no concept >> of groups, that may come in the future releases. >> Security >> Implementation >> >> Currently, it would be possible to implement this using >> Aerogear-Security-Picketlink and with some raw Picketlink : >> >> - Login / Logout / Registration : AG-Security offers all we need >> - Roles and permissions : AG-Security offers a secures annotation that >> can be used to protect the endpoints. >> >> I know there are some concerns about this last points (Role escalation etc >> ...) and would like to have advice / feedback on what is acceptable / >> doable for the 0.10.0 release (15/01). >> _______________________________________________ >> 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 edewit at redhat.com Wed Dec 4 04:09:30 2013 From: edewit at redhat.com (Erik Jan de Wit) Date: Wed, 4 Dec 2013 10:09:30 +0100 Subject: [aerogear-dev] how about this API for sync? Message-ID: Just to get some discussions going and have something to talk about I?ve drafted some API, so what do you think? // [option 1 fully automatic we create a pipe and add the posibilty to add a store for failover and sync just happens at on- and offline events] // and because merging can fail users can add a conflict handlers Builder builder = Builder.createPipe(pipeConfig).addFailoverStore(storeConfig); Pipe pipe = builder.pipe(Car.class); pipe.addConfictHandler(new ConflictHandler() { public void conflict(Field originalField, Field newField) { // user interaction } }); // [option 2 explicit let the user specify when to sync and what to sync] SyncedPipe pipe = SyncPipeBuilder.build(options); // SyncPipe Store and Pipe togheter // or we only use a store to sync and tell the sync manager where to sync to SyncManager syncManager = new SyncManger(); syncManger.filter(readFilter); // maybe we don't want to sync all data but just some part syncManager.addConnectionHandler(new ConnectionHandler() { public void onConnection() { syncManger.sync(pipe); } }); syncManger.addConfictHandler(new ConflictHandler() { public void conflict(Field original, Field new) { // user interaction } }); Cheers, Erik Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20131204/8b237919/attachment.html From scm.blanc at gmail.com Wed Dec 4 09:02:40 2013 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Wed, 4 Dec 2013 15:02:40 +0100 Subject: [aerogear-dev] UPS User Management - Reloaded In-Reply-To: References: Message-ID: On Tue, Dec 3, 2013 at 12:21 PM, Bruno Oliveira wrote: > Hi Sebi, few comments inline. > > On December 3, 2013 at 8:54:22 AM, Sebastien Blanc (scm.blanc at gmail.com) > wrote: > > > >Hi, > >I wanted to start a fresh new thread about user management in the Unified > >Push Server, please check below the proposition I made for the next > release > >(0.10.0) , feel free to comment / ask questions etc ... > > > >(https://gist.github.com/sebastienblanc/6547605) > >User Management for the Aerogear Unfied Push > >Server > >Introduction > > > >The goal of this document is to describe how the User Management will be > >implemented in the Unified Push Server. Currently there is only one user > >created by default when installing UPS. Having the possibility to create > >multiple users is a "Must Have" and should be manageable from the Admin > >Console. Some roles should also be introduced > >Roles / > >Permissions > > > >There will be 3 different roles in this first version : > > > >- *Admin* : The Admin is like the super-user, it can access all the > >features of UPS including the creation of users. > >- *Developer* : The developer can create/read/update and delete > >Applications/variants. > >- *viewer* : Can only 'Read', can be useful for monitoring apps (or for > >the future UPS Forge Plugin). > > Here the Developer role will be able to reset user?s password? Or his own > password? > Sorry, I was not specific enough here, I meant reset the secret of an push applications or a variant not the password of the user (I updated the gist) > > > > >Role / actionCreateUpdateReadDeleteReset pwdUser > MngtAdminXXXXXXDeveloperXXX > >XXViewer X > >User > >management flow > > > >An Admin can create new user by providing a loginName. This will be > >possible through : > > > >- The console > >- The REST service > > > >Password > >Management > > > >At creation, the user will have a default password , i.e 123. > > I think here is the problem which we can?t delay anymore. At the creation > we should probably send an e-mail with the encrypted url for the password > setup. > > Is not the same thing, but the url approach can be something similar to > what SP does to register channels. > Agreed, but we must find a "email" solution that works both on a "custom" deployed UPS and on a UPS deployed through the openshift cartdridge. There are probably solutions but my idea was to have this simple solution for the 0.10.0 and the email flow for the 1.0 release. > > >First Login > > > >When logging in for this first time, the new created user will be prompted > >to change his password. > > Same thing there, I think users should be able to reset their own password. > Make sense but that would imply that an user can manage his account, again for 0.10.0 I'm not sure we can get it in (there is a lot of stuff open for UPS 0.10.0 beside user management). > > >Reset > >Password Instruction > > > >If a user wants to reset his password, he has to request it manually > >(email, post pigeon ...) to an admin. The password will be again the > >default one and the user will have to change it again when logging in. > >Scope > >of the current permissions > > > >Currently, a authenticated user can see all the applications / variants / > >installations, no matter he is the author or not. There is also no concept > >of groups, that may come in the future releases. > >Security > >Implementation > > > >Currently, it would be possible to implement this using > >Aerogear-Security-Picketlink and with some raw Picketlink : > > > >- Login / Logout / Registration : AG-Security offers all we need > >- Roles and permissions : AG-Security offers a secures annotation that > >can be used to protect the endpoints. > > > >I know there are some concerns about this last points (Role escalation etc > >...) and would like to have advice / feedback on what is acceptable / > >doable for the 0.10.0 release (15/01). > >_______________________________________________ > >aerogear-dev mailing list > >aerogear-dev at lists.jboss.org > >https://lists.jboss.org/mailman/listinfo/aerogear-dev > > -- > abstractj > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20131204/612e3391/attachment-0001.html From scm.blanc at gmail.com Wed Dec 4 09:09:14 2013 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Wed, 4 Dec 2013 15:09:14 +0100 Subject: [aerogear-dev] UPS User Management - Reloaded In-Reply-To: References: Message-ID: On Tue, Dec 3, 2013 at 3:42 PM, Lucas Holmquist wrote: > > On Dec 3, 2013, at 6:21 AM, Bruno Oliveira wrote: > > > Hi Sebi, few comments inline. > > > > On December 3, 2013 at 8:54:22 AM, Sebastien Blanc (scm.blanc at gmail.com) > wrote: > >> > >> Hi, > >> I wanted to start a fresh new thread about user management in the > Unified > >> Push Server, please check below the proposition I made for the next > release > >> (0.10.0) , feel free to comment / ask questions etc ... > >> > >> (https://gist.github.com/sebastienblanc/6547605) > >> User Management for the Aerogear Unfied Push > >> Server > >> Introduction > >> > >> The goal of this document is to describe how the User Management will be > >> implemented in the Unified Push Server. Currently there is only one user > >> created by default when installing UPS. Having the possibility to create > >> multiple users is a "Must Have" and should be manageable from the Admin > >> Console. Some roles should also be introduced > >> Roles / > >> Permissions > >> > >> There will be 3 different roles in this first version : > >> > >> - *Admin* : The Admin is like the super-user, it can access all the > >> features of UPS including the creation of users. > >> - *Developer* : The developer can create/read/update and delete > >> Applications/variants. > >> - *viewer* : Can only 'Read', can be useful for monitoring apps (or for > >> the future UPS Forge Plugin). > > > > Here the Developer role will be able to reset user?s password? Or his > own password? > > > >> > >> Role / actionCreateUpdateReadDeleteReset pwdUser > MngtAdminXXXXXXDeveloperXXX > >> XXViewer X > >> User > >> management flow > >> > >> An Admin can create new user by providing a loginName. This will be > >> possible through : > >> > >> - The console > >> - The REST service > >> > >> Password > >> Management > >> > >> At creation, the user will have a default password , i.e 123. > > > > I think here is the problem which we can?t delay anymore. At the > creation we should probably send an e-mail with the encrypted url for the > password setup. > > > > Is not the same thing, but the url approach can be something similar to > what SP does to register channels. > > i'm not sure we should put the email functionality in the UPS, but we > could have a "create a secure link" option that the admin can then email out > Stop me if I'm completely wrong but could we use our own cryptobox for this, I was thinking of this : https://github.com/aerogear/aerogear-crypto-java/blob/master/src/test/java/org/jboss/aerogear/crypto/CryptoBoxTest.java#L111 Which could be (again pardon my newbiness) : //when generating the link CryptoBox cryptoBox = new CryptoBox(new PrivateKey(UPS_SECRET_KEY)); byte[] IV = HEX.decode(CRYPTOBOX_IV); byte[] cipherText = cryptoBox.encrypt(IV, loginName.getBytes()); return "http://blabla/ag-push/register?" + cipherText; //when the link is called CryptoBox pandora = new CryptoBox(new PrivateKey(UPS_SECRET_KEY)); byte[] message = pandora.decrypt(IV, cipherText); String loginName = RAW.encode(message); //Do stuff with the loginName Then the question is about the private key, how do I store it / generate it ? Should I use the Java Keystore class http://docs.oracle.com/javase/7/docs/api/java/security/KeyStore.html ? > > > >> First Login > >> > >> When logging in for this first time, the new created user will be > prompted > >> to change his password. > > > > Same thing there, I think users should be able to reset their own > password. > > > >> Reset > >> Password Instruction > >> > >> If a user wants to reset his password, he has to request it manually > >> (email, post pigeon ...) to an admin. The password will be again the > >> default one and the user will have to change it again when logging in. > >> Scope > >> of the current permissions > >> > >> Currently, a authenticated user can see all the applications / variants > / > >> installations, no matter he is the author or not. There is also no > concept > >> of groups, that may come in the future releases. > >> Security > >> Implementation > >> > >> Currently, it would be possible to implement this using > >> Aerogear-Security-Picketlink and with some raw Picketlink : > >> > >> - Login / Logout / Registration : AG-Security offers all we need > >> - Roles and permissions : AG-Security offers a secures annotation that > >> can be used to protect the endpoints. > >> > >> I know there are some concerns about this last points (Role escalation > etc > >> ...) and would like to have advice / feedback on what is acceptable / > >> doable for the 0.10.0 release (15/01). > >> _______________________________________________ > >> 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/20131204/ca7eaa14/attachment.html From bruno at abstractj.org Wed Dec 4 11:32:27 2013 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 4 Dec 2013 14:32:27 -0200 Subject: [aerogear-dev] UPS User Management - Reloaded In-Reply-To: References: Message-ID: I?m on it and will send a basic idea soon, cryptobox doesn?t make too much sense into this scenario, because we must use one-way hash. On December 4, 2013 at 12:09:21 PM, Sebastien Blanc (scm.blanc at gmail.com) wrote: > >On Tue, Dec 3, 2013 at 3:42 PM, Lucas Holmquist wrote: > >> >> On Dec 3, 2013, at 6:21 AM, Bruno Oliveira wrote: >> >> > Hi Sebi, few comments inline. >> > >> > On December 3, 2013 at 8:54:22 AM, Sebastien Blanc (scm.blanc at gmail.com) >> wrote: >> >> >> >> Hi, >> >> I wanted to start a fresh new thread about user management in the >> Unified >> >> Push Server, please check below the proposition I made for the next >> release >> >> (0.10.0) , feel free to comment / ask questions etc ... >> >> >> >> (https://gist.github.com/sebastienblanc/6547605) >> >> User Management for the Aerogear Unfied Push >> >> Server >> >> Introduction >> >> >> >> The goal of this document is to describe how the User Management will be >> >> implemented in the Unified Push Server. Currently there is only one user >> >> created by default when installing UPS. Having the possibility to create >> >> multiple users is a "Must Have" and should be manageable from the Admin >> >> Console. Some roles should also be introduced >> >> Roles / >> >> Permissions >> >> >> >> There will be 3 different roles in this first version : >> >> >> >> - *Admin* : The Admin is like the super-user, it can access all the >> >> features of UPS including the creation of users. >> >> - *Developer* : The developer can create/read/update and delete >> >> Applications/variants. >> >> - *viewer* : Can only 'Read', can be useful for monitoring apps (or for >> >> the future UPS Forge Plugin). >> > >> > Here the Developer role will be able to reset user?s password? Or his >> own password? >> > >> >> >> >> Role / actionCreateUpdateReadDeleteReset pwdUser >> MngtAdminXXXXXXDeveloperXXX >> >> XXViewer X >> >> User >> >> management flow >> >> >> >> An Admin can create new user by providing a loginName. This will be >> >> possible through : >> >> >> >> - The console >> >> - The REST service >> >> >> >> Password >> >> Management >> >> >> >> At creation, the user will have a default password , i.e 123. >> > >> > I think here is the problem which we can?t delay anymore. At the >> creation we should probably send an e-mail with the encrypted url for the >> password setup. >> > >> > Is not the same thing, but the url approach can be something similar to >> what SP does to register channels. >> >> i'm not sure we should put the email functionality in the UPS, but we >> could have a "create a secure link" option that the admin can then email out >> > > > > >Stop me if I'm completely wrong but could we use our own cryptobox for >this, I was thinking of this : >https://github.com/aerogear/aerogear-crypto-java/blob/master/src/test/java/org/jboss/aerogear/crypto/CryptoBoxTest.java#L111 > >Which could be (again pardon my newbiness) : > >//when generating the link >CryptoBox cryptoBox = new CryptoBox(new PrivateKey(UPS_SECRET_KEY)); >byte[] IV = HEX.decode(CRYPTOBOX_IV); >byte[] cipherText = cryptoBox.encrypt(IV, loginName.getBytes()); > >return "http://blabla/ag-push/register?" + cipherText; > > >//when the link is called >CryptoBox pandora = new CryptoBox(new PrivateKey(UPS_SECRET_KEY)); >byte[] message = pandora.decrypt(IV, cipherText); >String loginName = RAW.encode(message); > > >//Do stuff with the loginName > > >Then the question is about the private key, how do I store it / generate >it ? Should I use the Java Keystore class >http://docs.oracle.com/javase/7/docs/api/java/security/KeyStore.html ? > > > > >> > >> >> First Login >> >> >> >> When logging in for this first time, the new created user will be >> prompted >> >> to change his password. >> > >> > Same thing there, I think users should be able to reset their own >> password. >> > >> >> Reset >> >> Password Instruction >> >> >> >> If a user wants to reset his password, he has to request it manually >> >> (email, post pigeon ...) to an admin. The password will be again the >> >> default one and the user will have to change it again when logging in. >> >> Scope >> >> of the current permissions >> >> >> >> Currently, a authenticated user can see all the applications / variants >> / >> >> installations, no matter he is the author or not. There is also no >> concept >> >> of groups, that may come in the future releases. >> >> Security >> >> Implementation >> >> >> >> Currently, it would be possible to implement this using >> >> Aerogear-Security-Picketlink and with some raw Picketlink : >> >> >> >> - Login / Logout / Registration : AG-Security offers all we need >> >> - Roles and permissions : AG-Security offers a secures annotation that >> >> can be used to protect the endpoints. >> >> >> >> I know there are some concerns about this last points (Role escalation >> etc >> >> ...) and would like to have advice / feedback on what is acceptable / >> >> doable for the 0.10.0 release (15/01). >> >> _______________________________________________ >> >> 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 Dec 5 06:38:40 2013 From: bruno at abstractj.org (Bruno Oliveira) Date: Thu, 5 Dec 2013 09:38:40 -0200 Subject: [aerogear-dev] Password reset Message-ID: Good morning slackland, here comes the basic idea about password reset: Some considerations to keep in mind: 1. E-mail in an insecure channel, for this reason we won?t build any functionality to ?remember? the password, only reset. ? 2. It must be provided over SSL 3. We are not NSA proof, so this is just a prototype to validate ideas. Details about the prototype: 1. The place to store the Token is totally up to the implementer: keystore, PicketLink or whatever database 2. The url to reset the password is built with PBKDF2 + authenticated one-way hash function (HMAC),?which means there?s no way you can pull the url id back out. Into this way we are avoiding 2 issues: rainbow table attacks and tampering, into other words an attacker will have a hard time to brute force it, as well trying to corrupt the message.? 3. This example doesn?t not validate e-mail address or have a login. - Token table -?id: the hashed message generated and encoded in Base64 (Is possible to be an hexadecimal) - sentAt: the date and time when the token was sent to someone else - expiration: token expiration. Default?s to 1 hour. - used: if the token was used or not. I implemented it into this way, but being paranoid I would suggest to just delete that record, if the token was used. - ExpirationTime class: just a class to deal with time and check if the Token has expired. - TokenService class: just a class to manipulate the tokens into the database - Endpoint workflow: - /rest/forgot 1. User input the e-mail 2. E-mail is validated against the database 3. An URL to reset the password is sent Ex:?curl -v -H "Accept: application/json" -H "Content-type: application/json" -d '{"email?:?john at doe.com"}' -X POST http://localhost:8080/password-reset/rest/forgot - /rest/reset 1. User sends an HTTP request with the token id 2. The id is validated against the database 3. User is redirected to the reset password page 4. The new password is configured 5. token id is destroyed into the database or disabled Ex:?curl -v -H "Accept: application/json" -H "Content-type: application/json" -X POST http://localhost:8080/password-reset/rest/reset\?id\=sQrYVLJvwQptgYAg46t%2B%2BfoLrWxaPmkMY6mmvCs%2F51M%3D Let me know what do you think and I can move forward implementing it. Note: To build the project please make use of this PR?https://github.com/aerogear/aerogear-crypto-java/pull/13. A bug was found on ag-crypto-java. --? abstractj From bruno at abstractj.org Thu Dec 5 06:43:44 2013 From: bruno at abstractj.org (Bruno Oliveira) Date: Thu, 5 Dec 2013 09:43:44 -0200 Subject: [aerogear-dev] Password reset Message-ID: Good morning slackland, here comes the basic idea about password reset:?https://github.com/abstractj/password-reset Some considerations to keep in mind:? 1. E-mail in an insecure channel, for this reason we won?t build any functionality to ?remember? the password, only reset. ?? 2. It must be provided over SSL? 3. We are not NSA proof, so this is just a prototype to validate ideas.? Details about the prototype:? 1. The place to store the Token is totally up to the implementer: keystore, PicketLink or whatever database? 2. The url to reset the password is built with PBKDF2 + authenticated one-way hash function (HMAC),?which means there?s no way you can pull the url id back out. Into this way we are avoiding 2 issues: rainbow table attacks and tampering, into other words an attacker will have a hard time to brute force it, as well trying to corrupt the message.?? 3. This example doesn?t not validate e-mail address or have a login.? - Token table? -?id: the hashed message generated and encoded in Base64 (Is possible to be an hexadecimal)? - sentAt: the date and time when the token was sent to someone else? - expiration: token expiration. Default?s to 1 hour.? - used: if the token was used or not. I implemented it into this way, but being paranoid I would suggest to just delete that record, if the token was used.? - ExpirationTime class: just a class to deal with time and check if the Token has expired.? - TokenService class: just a class to manipulate the tokens into the database? - Endpoint workflow:? - /rest/forgot? 1. User input the e-mail? 2. E-mail is validated against the database? 3. An URL to reset the password is sent? Ex:?curl -v -H "Accept: application/json" -H "Content-type: application/json" -d '{"email?:?john at doe.com"}' -X POST?http://localhost:8080/password-reset/rest/forgot? - /rest/reset? 1. User sends an HTTP request with the token id? 2. The id is validated against the database? 3. User is redirected to the reset password page? 4. The new password is configured? 5. token id is destroyed into the database or disabled? Ex:?curl -v -H "Accept: application/json" -H "Content-type: application/json" -X POST?http://localhost:8080/password-reset/rest/reset\?id\=sQrYVLJvwQptgYAg46t%2B%2BfoLrWxaPmkMY6mmvCs%2F51M%3D? --? abstractj From edewit at redhat.com Thu Dec 5 07:23:36 2013 From: edewit at redhat.com (Erik Jan de Wit) Date: Thu, 5 Dec 2013 13:23:36 +0100 Subject: [aerogear-dev] Password reset In-Reply-To: References: Message-ID: Sound good only one thing we could as an extra safety let the token time out after x minutes / days. On 5 Dec,2013, at 12:43 , Bruno Oliveira wrote: > Good morning slackland, here comes the basic idea about password reset: https://github.com/abstractj/password-reset > > Some considerations to keep in mind: > > 1. E-mail in an insecure channel, for this reason we won?t build any functionality to ?remember? the password, only reset. > 2. It must be provided over SSL > 3. We are not NSA proof, so this is just a prototype to validate ideas. > > > Details about the prototype: > > 1. The place to store the Token is totally up to the implementer: keystore, PicketLink or whatever database > 2. The url to reset the password is built with PBKDF2 + authenticated one-way hash function (HMAC), which means there?s no way you can pull the url id back out. Into this way we are avoiding 2 issues: rainbow table attacks and tampering, into other words an attacker will have a hard time to brute force it, as well trying to corrupt the message. > 3. This example doesn?t not validate e-mail address or have a login. > > - Token table > > - id: the hashed message generated and encoded in Base64 (Is possible to be an hexadecimal) > - sentAt: the date and time when the token was sent to someone else > - expiration: token expiration. Default?s to 1 hour. > - used: if the token was used or not. I implemented it into this way, but being paranoid I would suggest to just delete that record, if the token was used. > > - ExpirationTime class: just a class to deal with time and check if the Token has expired. > > - TokenService class: just a class to manipulate the tokens into the database > > - Endpoint workflow: > > - /rest/forgot > > 1. User input the e-mail > 2. E-mail is validated against the database > 3. An URL to reset the password is sent > > Ex: curl -v -H "Accept: application/json" -H "Content-type: application/json" -d '{"email?:?john at doe.com"}' -X POST http://localhost:8080/password-reset/rest/forgot > > - /rest/reset > > 1. User sends an HTTP request with the token id > 2. The id is validated against the database > 3. User is redirected to the reset password page > 4. The new password is configured > 5. token id is destroyed into the database or disabled > > Ex: curl -v -H "Accept: application/json" -H "Content-type: application/json" -X POST http://localhost:8080/password-reset/rest/reset\?id\=sQrYVLJvwQptgYAg46t%2B%2BfoLrWxaPmkMY6mmvCs%2F51M%3D > > > -- > abstractj > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From edewit at redhat.com Thu Dec 5 07:25:52 2013 From: edewit at redhat.com (Erik Jan de Wit) Date: Thu, 5 Dec 2013 13:25:52 +0100 Subject: [aerogear-dev] Password reset In-Reply-To: References: Message-ID: oops silly me you have that already On 5 Dec,2013, at 13:23 , Erik Jan de Wit wrote: > Sound good only one thing we could as an extra safety let the token time out after x minutes / days. > > On 5 Dec,2013, at 12:43 , Bruno Oliveira wrote: > >> Good morning slackland, here comes the basic idea about password reset: https://github.com/abstractj/password-reset >> >> Some considerations to keep in mind: >> >> 1. E-mail in an insecure channel, for this reason we won?t build any functionality to ?remember? the password, only reset. >> 2. It must be provided over SSL >> 3. We are not NSA proof, so this is just a prototype to validate ideas. >> >> >> Details about the prototype: >> >> 1. The place to store the Token is totally up to the implementer: keystore, PicketLink or whatever database >> 2. The url to reset the password is built with PBKDF2 + authenticated one-way hash function (HMAC), which means there?s no way you can pull the url id back out. Into this way we are avoiding 2 issues: rainbow table attacks and tampering, into other words an attacker will have a hard time to brute force it, as well trying to corrupt the message. >> 3. This example doesn?t not validate e-mail address or have a login. >> >> - Token table >> >> - id: the hashed message generated and encoded in Base64 (Is possible to be an hexadecimal) >> - sentAt: the date and time when the token was sent to someone else >> - expiration: token expiration. Default?s to 1 hour. >> - used: if the token was used or not. I implemented it into this way, but being paranoid I would suggest to just delete that record, if the token was used. >> >> - ExpirationTime class: just a class to deal with time and check if the Token has expired. >> >> - TokenService class: just a class to manipulate the tokens into the database >> >> - Endpoint workflow: >> >> - /rest/forgot >> >> 1. User input the e-mail >> 2. E-mail is validated against the database >> 3. An URL to reset the password is sent >> >> Ex: curl -v -H "Accept: application/json" -H "Content-type: application/json" -d '{"email?:?john at doe.com"}' -X POST http://localhost:8080/password-reset/rest/forgot >> >> - /rest/reset >> >> 1. User sends an HTTP request with the token id >> 2. The id is validated against the database >> 3. User is redirected to the reset password page >> 4. The new password is configured >> 5. token id is destroyed into the database or disabled >> >> Ex: curl -v -H "Accept: application/json" -H "Content-type: application/json" -X POST http://localhost:8080/password-reset/rest/reset\?id\=sQrYVLJvwQptgYAg46t%2B%2BfoLrWxaPmkMY6mmvCs%2F51M%3D >> >> >> -- >> 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 abstractj at redhat.com Thu Dec 5 07:32:54 2013 From: abstractj at redhat.com (Bruno Oliveira) Date: Thu, 5 Dec 2013 10:32:54 -0200 Subject: [aerogear-dev] TODO app abandon - continues.... Message-ID: Good morning peeps, regarding this thread?http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-TODO-app-abandoning-td4576.html. Somehow we agreed in the past to no longer support this app?http://transcripts.jboss.org/channel/irc.freenode.org/%23aerogear/2013/%23aerogear.2013-01-28.log. I?ve been chatting with Christos about my concern around this app: - This app still make use of ag-controller and outdated versions of ag security - Maintain it is very time consuming - We need to monitor OpenShift because after a period of inactivity the app will be disabled That said I vote for just drop or no longer maintain this app and update our integration tests. But before move forward with it, I would like to hear the concerns from the team about it. If I don?t hear anything, the application will be dropped from OpenShift. If the team agree on maintain it, we need a call for arms to do it. --? abstractj JBoss, a division of Red Hat From daniel.bevenius at gmail.com Thu Dec 5 07:34:28 2013 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Thu, 5 Dec 2013 13:34:28 +0100 Subject: [aerogear-dev] TODO app abandon - continues.... In-Reply-To: References: Message-ID: +1 On dropping it. On 5 December 2013 13:32, Bruno Oliveira wrote: > Good morning peeps, regarding this thread > http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-TODO-app-abandoning-td4576.html. > Somehow we agreed in the past to no longer support this app > http://transcripts.jboss.org/channel/irc.freenode.org/%23aerogear/2013/%23aerogear.2013-01-28.log > . > > I?ve been chatting with Christos about my concern around this app: > > - This app still make use of ag-controller and outdated versions of ag > security > - Maintain it is very time consuming > - We need to monitor OpenShift because after a period of inactivity the > app will be disabled > > That said I vote for just drop or no longer maintain this app and update > our integration tests. But before move forward with it, I would like to > hear the concerns from the team about it. > > If I don?t hear anything, the application will be dropped from OpenShift. > If the team agree on maintain it, we need a call for arms to do it. > > -- > abstractj > > JBoss, a division of Red Hat > > > > _______________________________________________ > 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/20131205/bf48d742/attachment.html From aemmanou at redhat.com Thu Dec 5 07:42:23 2013 From: aemmanou at redhat.com (Apostolos Emmanouilidis) Date: Thu, 05 Dec 2013 13:42:23 +0100 Subject: [aerogear-dev] Password reset In-Reply-To: References: Message-ID: <1386247343.1848.26.camel@dhcp129-205.brq.redhat.com> sounds good to me Just wanted to add that the /rest/forgot endpoint response must return the same answer regardless of whether the given e-mail is successfully validated against the database or not. The client should not be able to find out if an e-mail address exists in our DB. On Thu, 2013-12-05 at 09:43 -0200, Bruno Oliveira wrote: > Good morning slackland, here comes the basic idea about password reset: https://github.com/abstractj/password-reset > > Some considerations to keep in mind: > > 1. E-mail in an insecure channel, for this reason we won?t build any functionality to ?remember? the password, only reset. > 2. It must be provided over SSL > 3. We are not NSA proof, so this is just a prototype to validate ideas. > > > Details about the prototype: > > 1. The place to store the Token is totally up to the implementer: keystore, PicketLink or whatever database > 2. The url to reset the password is built with PBKDF2 + authenticated one-way hash function (HMAC), which means there?s no way you can pull the url id back out. Into this way we are avoiding 2 issues: rainbow table attacks and tampering, into other words an attacker will have a hard time to brute force it, as well trying to corrupt the message. > 3. This example doesn?t not validate e-mail address or have a login. > > - Token table > > - id: the hashed message generated and encoded in Base64 (Is possible to be an hexadecimal) > - sentAt: the date and time when the token was sent to someone else > - expiration: token expiration. Default?s to 1 hour. > - used: if the token was used or not. I implemented it into this way, but being paranoid I would suggest to just delete that record, if the token was used. > > - ExpirationTime class: just a class to deal with time and check if the Token has expired. > > - TokenService class: just a class to manipulate the tokens into the database > > - Endpoint workflow: > > - /rest/forgot > > 1. User input the e-mail > 2. E-mail is validated against the database > 3. An URL to reset the password is sent > > Ex: curl -v -H "Accept: application/json" -H "Content-type: application/json" -d '{"email?:?john at doe.com"}' -X POST http://localhost:8080/password-reset/rest/forgot > > - /rest/reset > > 1. User sends an HTTP request with the token id > 2. The id is validated against the database > 3. User is redirected to the reset password page > 4. The new password is configured > 5. token id is destroyed into the database or disabled > > Ex: curl -v -H "Accept: application/json" -H "Content-type: application/json" -X POST http://localhost:8080/password-reset/rest/reset\?id\=sQrYVLJvwQptgYAg46t%2B%2BfoLrWxaPmkMY6mmvCs%2F51M%3D > > > -- > 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/20131205/abd93174/attachment-0001.html From scm.blanc at gmail.com Thu Dec 5 07:48:07 2013 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Thu, 5 Dec 2013 13:48:07 +0100 Subject: [aerogear-dev] Password reset In-Reply-To: References: Message-ID: Thanks for having working this out ! Some comments inline On Thu, Dec 5, 2013 at 12:38 PM, Bruno Oliveira wrote: > Good morning slackland, here comes the basic idea about password reset: > > Some considerations to keep in mind: > > 1. E-mail in an insecure channel, for this reason we won?t build any > functionality to ?remember? the password, only reset. > 2. It must be provided over SSL > 3. We are not NSA proof, so this is just a prototype to validate ideas. > > > Details about the prototype: > > 1. The place to store the Token is totally up to the implementer: > keystore, PicketLink or whatever database > Okay but in the case of Unified Push Server what would be your advice (PicketLink ? since we alreadu using it _ > 2. The url to reset the password is built with PBKDF2 + authenticated > one-way hash function (HMAC), which means there?s no way you can pull the > url id back out. Into this way we are avoiding 2 issues: rainbow table > attacks and tampering, into other words an attacker will have a hard time > to brute force it, as well trying to corrupt the message. > 3. This example doesn?t not validate e-mail address or have a login. > > - Token table > > - id: the hashed message generated and encoded in Base64 (Is > possible to be an hexadecimal) > - sentAt: the date and time when the token was sent to someone else > - expiration: token expiration. Default?s to 1 hour. > - used: if the token was used or not. I implemented it into this > way, but being paranoid I would suggest to just delete that record, if the > token was used. > > - ExpirationTime class: just a class to deal with time and check if the > Token has expired. > > - TokenService class: just a class to manipulate the tokens into the > database > > - Endpoint workflow: > > - /rest/forgot > 1. User input the e-mail > 2. E-mail is validated against the database > 3. An URL to reset the password is sent > > Ex: curl -v -H "Accept: application/json" -H "Content-type: > application/json" -d '{"email?:?john at doe.com"}' -X POST > http://localhost:8080/password-reset/rest/forgot For first registrations, I presume it uses the same endpoint ? I'm thinking of this scenario : - An admin creates a new users just by providing a loginName. - The backend creates the user and returns the url as explained above. - Admin sends the link to the user. - User click the link and set his password. > > > - /rest/reset > 1. User sends an HTTP request with the token id > 2. The id is validated against the database > 3. User is redirected to the reset password page > 4. The new password is configured > 5. token id is destroyed into the database or disabled > Ex: curl -v -H "Accept: application/json" -H "Content-type: > application/json" -X POST > http://localhost:8080/password-reset/rest/reset\?id\=sQrYVLJvwQptgYAg46t%2B%2BfoLrWxaPmkMY6mmvCs%2F51M%3D > > > Let me know what do you think and I can move forward implementing it. > Go Go Go ! > > Note: To build the project please make use of this PR > https://github.com/aerogear/aerogear-crypto-java/pull/13. A bug was found > on ag-crypto-java. > > > > > -- > 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/20131205/fde0b3c5/attachment.html From bruno at abstractj.org Thu Dec 5 07:49:03 2013 From: bruno at abstractj.org (Bruno Oliveira) Date: Thu, 5 Dec 2013 10:49:03 -0200 Subject: [aerogear-dev] Password reset In-Reply-To: <1386247343.1848.26.camel@dhcp129-205.brq.redhat.com> References: <1386247343.1848.26.camel@dhcp129-205.brq.redhat.com> Message-ID: Not sure if I?m following but we have 2 scenarios: 1. An attacker ask to reset: john at doe.com which exists into the database. Into this case my solo idea is: HTTP Response: ?An e-mail with the reset instructions was sent? That example returns the URL, because I?m not taking into consideration e-mail validation and etc 2. An attacker ask to reset: meggie at doe.com which doesn?t exist into the database. Into this scenario, same thing: HTTP Response: ?An e-mail with the reset instructions was sent? It might sound silly at first glance, but the idea is to not give any clue if some data exists or not into the database. Is that your idea? That example returns the URL, because I?m not taking into consideration e-mail validation and etc. On December 5, 2013 at 10:42:34 AM, Apostolos Emmanouilidis (aemmanou at redhat.com) wrote: > Just wanted to add that the /rest/forgot endpoint response must return the same answer regardless of whether the given e-mail is successfully validated against the database or not. The client should not be able to find out if an e-mail address exists in our DB. --? abstractj From scm.blanc at gmail.com Thu Dec 5 07:50:04 2013 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Thu, 5 Dec 2013 13:50:04 +0100 Subject: [aerogear-dev] TODO app abandon - continues.... In-Reply-To: References: Message-ID: +1 And IMO if we need some specific features for testing it should be implemented here : https://github.com/aerogear/aerogear-jaxrs-demo On Thu, Dec 5, 2013 at 1:34 PM, Daniel Bevenius wrote: > +1 On dropping it. > > > On 5 December 2013 13:32, Bruno Oliveira wrote: > >> Good morning peeps, regarding this thread >> http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-TODO-app-abandoning-td4576.html. >> Somehow we agreed in the past to no longer support this app >> http://transcripts.jboss.org/channel/irc.freenode.org/%23aerogear/2013/%23aerogear.2013-01-28.log >> . >> >> I?ve been chatting with Christos about my concern around this app: >> >> - This app still make use of ag-controller and outdated versions of ag >> security >> - Maintain it is very time consuming >> - We need to monitor OpenShift because after a period of inactivity the >> app will be disabled >> >> That said I vote for just drop or no longer maintain this app and update >> our integration tests. But before move forward with it, I would like to >> hear the concerns from the team about it. >> >> If I don?t hear anything, the application will be dropped from OpenShift. >> If the team agree on maintain it, we need a call for arms to do it. >> >> -- >> abstractj >> >> JBoss, a division of Red Hat >> >> >> >> _______________________________________________ >> 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/20131205/2e0a5c80/attachment.html From corinnekrych at gmail.com Thu Dec 5 07:51:59 2013 From: corinnekrych at gmail.com (Corinne Krych) Date: Thu, 5 Dec 2013 13:51:59 +0100 Subject: [aerogear-dev] TODO app abandon - continues.... In-Reply-To: References: Message-ID: <992E420B-EFE9-4A97-B9CF-F3340E5EB132@gmail.com> I understand the issues and problems but that brings the topic how are we going to demo, let's say in iOS cookbook features that involved server part? TODO app were used to demo Pipe. I cross reference TODO app in here: https://github.com/aerogear/aerogear-ios-cookbook#table-of-content Something raised in this thread http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Android-multipart-cookbook-component-td3553.html ++ Corinne On Dec 5, 2013, at 1:34 PM, Daniel Bevenius wrote: > +1 On dropping it. > > > On 5 December 2013 13:32, Bruno Oliveira wrote: > Good morning peeps, regarding this thread http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-TODO-app-abandoning-td4576.html. Somehow we agreed in the past to no longer support this app http://transcripts.jboss.org/channel/irc.freenode.org/%23aerogear/2013/%23aerogear.2013-01-28.log. > > I?ve been chatting with Christos about my concern around this app: > > - This app still make use of ag-controller and outdated versions of ag security > - Maintain it is very time consuming > - We need to monitor OpenShift because after a period of inactivity the app will be disabled > > That said I vote for just drop or no longer maintain this app and update our integration tests. But before move forward with it, I would like to hear the concerns from the team about it. > > If I don?t hear anything, the application will be dropped from OpenShift. If the team agree on maintain it, we need a call for arms to do it. > > -- > abstractj > > JBoss, a division of Red Hat > > > > _______________________________________________ > 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 Thu Dec 5 07:52:21 2013 From: lholmqui at redhat.com (Luke Holmquist) Date: Thu, 5 Dec 2013 07:52:21 -0500 (EST) Subject: [aerogear-dev] TODO app abandon - continues.... In-Reply-To: References: Message-ID: Drop it like its hooooot http://wifflegif.com/gifs/325554-drop-it-like-its-hot-snoop-dogg-gif Sent from my iPhone > On Dec 5, 2013, at 7:34 AM, Daniel Bevenius wrote: > > +1 On dropping it. > > >> On 5 December 2013 13:32, Bruno Oliveira wrote: >> Good morning peeps, regarding this thread http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-TODO-app-abandoning-td4576.html. Somehow we agreed in the past to no longer support this app http://transcripts.jboss.org/channel/irc.freenode.org/%23aerogear/2013/%23aerogear.2013-01-28.log. >> >> I?ve been chatting with Christos about my concern around this app: >> >> - This app still make use of ag-controller and outdated versions of ag security >> - Maintain it is very time consuming >> - We need to monitor OpenShift because after a period of inactivity the app will be disabled >> >> That said I vote for just drop or no longer maintain this app and update our integration tests. But before move forward with it, I would like to hear the concerns from the team about it. >> >> If I don?t hear anything, the application will be dropped from OpenShift. If the team agree on maintain it, we need a call for arms to do it. >> >> -- >> abstractj >> >> JBoss, a division of Red Hat >> >> >> >> _______________________________________________ >> 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/20131205/0371351d/attachment-0001.html From corinnekrych at gmail.com Thu Dec 5 07:52:40 2013 From: corinnekrych at gmail.com (Corinne Krych) Date: Thu, 5 Dec 2013 13:52:40 +0100 Subject: [aerogear-dev] TODO app abandon - continues.... In-Reply-To: <992E420B-EFE9-4A97-B9CF-F3340E5EB132@gmail.com> References: <992E420B-EFE9-4A97-B9CF-F3340E5EB132@gmail.com> Message-ID: <616A8F11-B52D-41C9-BE7D-F4D22623D3DA@gmail.com> oki seb answers my question then On Dec 5, 2013, at 1:51 PM, Corinne Krych wrote: > I understand the issues and problems but that brings the topic how are we going to demo, let's say in iOS cookbook features that involved server part? > TODO app were used to demo Pipe. I cross reference TODO app in here: > https://github.com/aerogear/aerogear-ios-cookbook#table-of-content > > Something raised in this thread > http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Android-multipart-cookbook-component-td3553.html > > ++ > Corinne > > On Dec 5, 2013, at 1:34 PM, Daniel Bevenius wrote: > >> +1 On dropping it. >> >> >> On 5 December 2013 13:32, Bruno Oliveira wrote: >> Good morning peeps, regarding this thread http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-TODO-app-abandoning-td4576.html. Somehow we agreed in the past to no longer support this app http://transcripts.jboss.org/channel/irc.freenode.org/%23aerogear/2013/%23aerogear.2013-01-28.log. >> >> I?ve been chatting with Christos about my concern around this app: >> >> - This app still make use of ag-controller and outdated versions of ag security >> - Maintain it is very time consuming >> - We need to monitor OpenShift because after a period of inactivity the app will be disabled >> >> That said I vote for just drop or no longer maintain this app and update our integration tests. But before move forward with it, I would like to hear the concerns from the team about it. >> >> If I don?t hear anything, the application will be dropped from OpenShift. If the team agree on maintain it, we need a call for arms to do it. >> >> -- >> abstractj >> >> JBoss, a division of Red Hat >> >> >> >> _______________________________________________ >> 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 Thu Dec 5 07:55:02 2013 From: bruno at abstractj.org (Bruno Oliveira) Date: Thu, 5 Dec 2013 10:55:02 -0200 Subject: [aerogear-dev] Password reset In-Reply-To: References: Message-ID: I think we can validate the whole example and check what?s missing and add PicketLink later. Do you think is a great idea to be ?storage? agnostic? On December 5, 2013 at 10:48:15 AM, Sebastien Blanc (scm.blanc at gmail.com) wrote: > For first registrations, I presume it uses the same endpoint ? I'm thinking of this scenario :? The same endpoint? Not following you on it. > - An admin creates a new users just by providing a loginName. > - The backend creates the user and returns the url as explained above. > - Admin sends the link to the user. Here is the workflow which I really would like to change. When and admin sends the url to the user, we have some cons: - We have no control over it, if the admin is just sending it without SSL or not.? - An admin can generate thousands of urls - The process is completely manual My suggestion is to implement something with . Make sense? I?m not saying this is a top huge priority, but necessary. > - User click the link and set his password. --? abstractj From aemmanou at redhat.com Thu Dec 5 07:56:42 2013 From: aemmanou at redhat.com (Apostolos Emmanouilidis) Date: Thu, 05 Dec 2013 13:56:42 +0100 Subject: [aerogear-dev] Password reset In-Reply-To: References: <1386247343.1848.26.camel@dhcp129-205.brq.redhat.com> Message-ID: <1386248202.1848.28.camel@dhcp129-205.brq.redhat.com> +1 that's what I meant On Thu, 2013-12-05 at 10:49 -0200, Bruno Oliveira wrote: > Not sure if I?m following but we have 2 scenarios: > > 1. An attacker ask to reset: john at doe.com which exists into the database. Into this case my solo idea is: > > HTTP Response: ?An e-mail with the reset instructions was sent? > > That example returns the URL, because I?m not taking into consideration e-mail validation and etc > > 2. An attacker ask to reset: meggie at doe.com which doesn?t exist into the database. Into this scenario, same thing: > > HTTP Response: ?An e-mail with the reset instructions was sent? > > It might sound silly at first glance, but the idea is to not give any clue if some data exists or not into the database. Is that your idea? > > That example returns the URL, because I?m not taking into consideration e-mail validation and etc. > > On December 5, 2013 at 10:42:34 AM, Apostolos Emmanouilidis (aemmanou at redhat.com) wrote: > > Just wanted to add that the /rest/forgot endpoint response must return the same answer regardless of whether the given e-mail is successfully validated against the database or not. The client should not be able to find out if an e-mail address exists in our DB. > -- > abstractj From cvasilak at gmail.com Thu Dec 5 08:08:03 2013 From: cvasilak at gmail.com (Christos Vasilakis) Date: Thu, 5 Dec 2013 15:08:03 +0200 Subject: [aerogear-dev] TODO app abandon - continues.... In-Reply-To: References: Message-ID: Thanks Bruno, +1 to drop (have looked at our integration-tests that exercise the TODO app but as I said on the IRC my view is that these tests that exist can be removed) - Christos On Dec 5, 2013, at 2:32 PM, Bruno Oliveira wrote: > Good morning peeps, regarding this thread http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-TODO-app-abandoning-td4576.html. Somehow we agreed in the past to no longer support this app http://transcripts.jboss.org/channel/irc.freenode.org/%23aerogear/2013/%23aerogear.2013-01-28.log. > > I?ve been chatting with Christos about my concern around this app: > > - This app still make use of ag-controller and outdated versions of ag security > - Maintain it is very time consuming > - We need to monitor OpenShift because after a period of inactivity the app will be disabled > > That said I vote for just drop or no longer maintain this app and update our integration tests. But before move forward with it, I would like to hear the concerns from the team about it. > > If I don?t hear anything, the application will be dropped from OpenShift. If the team agree on maintain it, we need a call for arms to do it. > > -- > abstractj > > JBoss, a division of Red Hat > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From daniel at passos.me Thu Dec 5 08:29:48 2013 From: daniel at passos.me (Daniel Passos) Date: Thu, 5 Dec 2013 11:29:48 -0200 Subject: [aerogear-dev] TODO app abandon - continues.... In-Reply-To: <992E420B-EFE9-4A97-B9CF-F3340E5EB132@gmail.com> References: <992E420B-EFE9-4A97-B9CF-F3340E5EB132@gmail.com> Message-ID: Hi Corinne, My idea is move all we need to example apps and integration test for a new server project or use aerogear-jaxrs-demo --? Daniel Passos On December 5, 2013 at 10:52:12 AM, Corinne Krych (corinnekrych at gmail.com) wrote: I understand the issues and problems but that brings the topic how are we going to demo, let's say in iOS cookbook features that involved server part? TODO app were used to demo Pipe. I cross reference TODO app in here: https://github.com/aerogear/aerogear-ios-cookbook#table-of-content Something raised in this thread http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Android-multipart-cookbook-component-td3553.html ++ Corinne On Dec 5, 2013, at 1:34 PM, Daniel Bevenius wrote: > +1 On dropping it. > > > On 5 December 2013 13:32, Bruno Oliveira wrote: > Good morning peeps, regarding this thread http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-TODO-app-abandoning-td4576.html. Somehow we agreed in the past to no longer support this app http://transcripts.jboss.org/channel/irc.freenode.org/%23aerogear/2013/%23aerogear.2013-01-28.log. > > I?ve been chatting with Christos about my concern around this app: > > - This app still make use of ag-controller and outdated versions of ag security > - Maintain it is very time consuming > - We need to monitor OpenShift because after a period of inactivity the app will be disabled > > That said I vote for just drop or no longer maintain this app and update our integration tests. But before move forward with it, I would like to hear the concerns from the team about it. > > If I don?t hear anything, the application will be dropped from OpenShift. If the team agree on maintain it, we need a call for arms to do it. > > -- > abstractj > > JBoss, a division of Red Hat > > > > _______________________________________________ > 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/20131205/8f4e1fb6/attachment.html From corinnekrych at gmail.com Thu Dec 5 08:36:03 2013 From: corinnekrych at gmail.com (Corinne Krych) Date: Thu, 5 Dec 2013 14:36:03 +0100 Subject: [aerogear-dev] TODO app abandon - continues.... In-Reply-To: References: <992E420B-EFE9-4A97-B9CF-F3340E5EB132@gmail.com> Message-ID: <539BB716-AF06-4B03-8FB8-4B6BBE4A7FBA@gmail.com> #agreed I've just created this JIRA for iOS: https://issues.jboss.org/browse/AGIOS-132 https://issues.jboss.org/browse/AGIOS-133 ++ Corinne On Dec 5, 2013, at 2:29 PM, Daniel Passos wrote: > Hi Corinne, > > My idea is move all we need to example apps and integration test for a new server project or use aerogear-jaxrs-demo > > -- > Daniel Passos > > On December 5, 2013 at 10:52:12 AM, Corinne Krych (corinnekrych at gmail.com) wrote: > >> I understand the issues and problems but that brings the topic how are we going to demo, let's say in iOS cookbook features that involved server part? >> TODO app were used to demo Pipe. I cross reference TODO app in here: >> https://github.com/aerogear/aerogear-ios-cookbook#table-of-content >> >> Something raised in this thread >> http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Android-multipart-cookbook-component-td3553.html >> >> ++ >> Corinne >> >> On Dec 5, 2013, at 1:34 PM, Daniel Bevenius wrote: >> >> > +1 On dropping it. >> > >> > >> > On 5 December 2013 13:32, Bruno Oliveira wrote: >> > Good morning peeps, regarding this thread http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-TODO-app-abandoning-td4576.html. Somehow we agreed in the past to no longer support this app http://transcripts.jboss.org/channel/irc.freenode.org/%23aerogear/2013/%23aerogear.2013-01-28.log. >> > >> > I?ve been chatting with Christos about my concern around this app: >> > >> > - This app still make use of ag-controller and outdated versions of ag security >> > - Maintain it is very time consuming >> > - We need to monitor OpenShift because after a period of inactivity the app will be disabled >> > >> > That said I vote for just drop or no longer maintain this app and update our integration tests. But before move forward with it, I would like to hear the concerns from the team about it. >> > >> > If I don?t hear anything, the application will be dropped from OpenShift. If the team agree on maintain it, we need a call for arms to do it. >> > >> > -- >> > abstractj >> > >> > JBoss, a division of Red Hat >> > >> > >> > >> > _______________________________________________ >> > 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 From cvasilak at gmail.com Thu Dec 5 08:38:15 2013 From: cvasilak at gmail.com (Christos Vasilakis) Date: Thu, 5 Dec 2013 15:38:15 +0200 Subject: [aerogear-dev] TODO app abandon - continues.... In-Reply-To: References: <992E420B-EFE9-4A97-B9CF-F3340E5EB132@gmail.com> Message-ID: <2834E8F1-1782-48BD-B124-C6028B01CED1@gmail.com> On Dec 5, 2013, at 3:29 PM, Daniel Passos wrote: > Hi Corinne, > > My idea is move all we need to example apps and integration test for a new server project or use aerogear-jaxrs-demo +1 > > -- > Daniel Passos > > On December 5, 2013 at 10:52:12 AM, Corinne Krych (corinnekrych at gmail.com) wrote: > >> I understand the issues and problems but that brings the topic how are we going to demo, let's say in iOS cookbook features that involved server part? >> TODO app were used to demo Pipe. I cross reference TODO app in here: >> https://github.com/aerogear/aerogear-ios-cookbook#table-of-content >> >> Something raised in this thread >> http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Android-multipart-cookbook-component-td3553.html >> >> ++ >> Corinne >> >> On Dec 5, 2013, at 1:34 PM, Daniel Bevenius wrote: >> >> > +1 On dropping it. >> > >> > >> > On 5 December 2013 13:32, Bruno Oliveira wrote: >> > Good morning peeps, regarding this thread http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-TODO-app-abandoning-td4576.html. Somehow we agreed in the past to no longer support this app http://transcripts.jboss.org/channel/irc.freenode.org/%23aerogear/2013/%23aerogear.2013-01-28.log. >> > >> > I?ve been chatting with Christos about my concern around this app: >> > >> > - This app still make use of ag-controller and outdated versions of ag security >> > - Maintain it is very time consuming >> > - We need to monitor OpenShift because after a period of inactivity the app will be disabled >> > >> > That said I vote for just drop or no longer maintain this app and update our integration tests. But before move forward with it, I would like to hear the concerns from the team about it. >> > >> > If I don?t hear anything, the application will be dropped from OpenShift. If the team agree on maintain it, we need a call for arms to do it. >> > >> > -- >> > abstractj >> > >> > JBoss, a division of Red Hat >> > >> > >> > >> > _______________________________________________ >> > 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/20131205/47381d45/attachment.html From scm.blanc at gmail.com Thu Dec 5 09:18:31 2013 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Thu, 5 Dec 2013 15:18:31 +0100 Subject: [aerogear-dev] Password reset In-Reply-To: References: Message-ID: On Thu, Dec 5, 2013 at 1:55 PM, Bruno Oliveira wrote: > I think we can validate the whole example and check what?s missing and add > PicketLink later. Do you think is a great idea to be ?storage? agnostic? > +1 > > On December 5, 2013 at 10:48:15 AM, Sebastien Blanc (scm.blanc at gmail.com) > wrote: > > For first registrations, I presume it uses the same endpoint ? I'm > thinking of this scenario : > > The same endpoint? Not following you on it. > I mean a user who make a request because he forgot his password and an admin creating a new user will use the same service as the result will be the same : the encrypted email > > > - An admin creates a new users just by providing a loginName. > > - The backend creates the user and returns the url as explained above. > > - Admin sends the link to the user. > > Here is the workflow which I really would like to change. When and admin > sends the url to the user, we have some cons: > > - We have no control over it, if the admin is just sending it without SSL > or not. > - An admin can generate thousands of urls > - The process is completely manual > +1 but putting aside the "console" this process his mainly the responsability of the admin, UPS "just" offers endpoints > > My suggestion is to implement something with to send e-mails here>. Make sense? I?m not saying this is a top huge > priority, but necessary. > Indeed that will be the nicest but again there were already some discussions to have or not email functionality inside UPS and as you say it's not the top prio for the 0.10.0 release. For 0.10.0 the URI will just be returned to the admin, for future releases we could think of integrating that in UPS or calling a third service that handles the email. We have also to keep in mind that all this must work in a openshift instance (cartridge) > > > - User click the link and set his password. > -- > abstractj > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20131205/a3ee3463/attachment.html From lholmqui at redhat.com Thu Dec 5 10:35:21 2013 From: lholmqui at redhat.com (Lucas Holmquist) Date: Thu, 5 Dec 2013 10:35:21 -0500 Subject: [aerogear-dev] Password reset In-Reply-To: References: Message-ID: Sounds Good. +1 On Dec 5, 2013, at 6:43 AM, Bruno Oliveira wrote: > Good morning slackland, here comes the basic idea about password reset: https://github.com/abstractj/password-reset > > Some considerations to keep in mind: > > 1. E-mail in an insecure channel, for this reason we won?t build any functionality to ?remember? the password, only reset. > 2. It must be provided over SSL > 3. We are not NSA proof, so this is just a prototype to validate ideas. > > > Details about the prototype: > > 1. The place to store the Token is totally up to the implementer: keystore, PicketLink or whatever database > 2. The url to reset the password is built with PBKDF2 + authenticated one-way hash function (HMAC), which means there?s no way you can pull the url id back out. Into this way we are avoiding 2 issues: rainbow table attacks and tampering, into other words an attacker will have a hard time to brute force it, as well trying to corrupt the message. > 3. This example doesn?t not validate e-mail address or have a login. > > - Token table > > - id: the hashed message generated and encoded in Base64 (Is possible to be an hexadecimal) > - sentAt: the date and time when the token was sent to someone else > - expiration: token expiration. Default?s to 1 hour. > - used: if the token was used or not. I implemented it into this way, but being paranoid I would suggest to just delete that record, if the token was used. > > - ExpirationTime class: just a class to deal with time and check if the Token has expired. > > - TokenService class: just a class to manipulate the tokens into the database > > - Endpoint workflow: > > - /rest/forgot > > 1. User input the e-mail > 2. E-mail is validated against the database > 3. An URL to reset the password is sent > > Ex: curl -v -H "Accept: application/json" -H "Content-type: application/json" -d '{"email?:?john at doe.com"}' -X POST http://localhost:8080/password-reset/rest/forgot > > - /rest/reset > > 1. User sends an HTTP request with the token id > 2. The id is validated against the database > 3. User is redirected to the reset password page > 4. The new password is configured > 5. token id is destroyed into the database or disabled > > Ex: curl -v -H "Accept: application/json" -H "Content-type: application/json" -X POST http://localhost:8080/password-reset/rest/reset\?id\=sQrYVLJvwQptgYAg46t%2B%2BfoLrWxaPmkMY6mmvCs%2F51M%3D > > > -- > 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 Dec 5 12:59:42 2013 From: bruno at abstractj.org (Bruno Oliveira) Date: Thu, 5 Dec 2013 15:59:42 -0200 Subject: [aerogear-dev] Password reset In-Reply-To: References: Message-ID: Correct On December 5, 2013 at 12:18:32 PM, Sebastien Blanc (scm.blanc at gmail.com) wrote: > I mean a user who make a request because he forgot his password and an admin creating a new user will use the same service as the result will be the same : the encrypted ema --? abstractj From lholmqui at redhat.com Thu Dec 5 15:21:11 2013 From: lholmqui at redhat.com (Lucas Holmquist) Date: Thu, 5 Dec 2013 15:21:11 -0500 Subject: [aerogear-dev] AG JS 1.3.1 Message-ID: <8C51AADD-1DEC-4D65-90DF-07243ED34D08@redhat.com> Hot on the heels of 1.3.0, i am hoping to release 1.3.1 next week. Here is a list of the JIRA's associated with it https://issues.jboss.org/issues/?jql=project%20%3D%20AGJS%20AND%20fixVersion%20%3D%20%221.3.1%22%20ORDER%20BY%20updated%20DESC%2C%20priority%20DESC%2C%20created%20ASC There was some bug fixes and test/documentation updates, but there were 2 big option added in DataManager: 1. Auto Connect Since IndexedDB and WebSQL needed to both be "opened" before doing a read/save/remove/filter , i've added an option " auto" to the creation of a store. It will default to false, so it will not break any existing stuff. if set to true, then you can do the a read, for example and not have to worry about calling open. 2. Opt-Out of Fallback and "preferred" this new option, 'fallback' will default to true, so data manager will fallback to a support adapter by default, but if you want to make sure an error is thrown if an adapter is not supported then you can set fallback=false. there is also a new "preferred" option. By default when fallback is enabled, this is the order the adapters are tried [ "IndexedDB", "WebSQL", "SessionLocal", "Memory" ] now a user can specify a list of adapters they want to try, so they can do [ "Memory" ] if they only want to fallback to the memory adapter if lets say IndexedDB isn't available So give it a try -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20131205/739372e5/attachment-0001.html From supittma at redhat.com Fri Dec 6 12:14:44 2013 From: supittma at redhat.com (Summers Pittman) Date: Fri, 06 Dec 2013 12:14:44 -0500 Subject: [aerogear-dev] TODO app abandon - continues.... In-Reply-To: <2834E8F1-1782-48BD-B124-C6028B01CED1@gmail.com> References: <992E420B-EFE9-4A97-B9CF-F3340E5EB132@gmail.com> <2834E8F1-1782-48BD-B124-C6028B01CED1@gmail.com> Message-ID: <52A20604.1080209@redhat.com> Drop it, passos and I have been wishlisting making a server side thingie to run tests and cookbooks against for a while. Maybe we will actually do it one of the decades :) From a side perspective, I've been working on making a DevNexus app and I will be dog fooding a lot of Aerogear for it :) On Thu 05 Dec 2013 08:38:15 AM EST, Christos Vasilakis wrote: > > On Dec 5, 2013, at 3:29 PM, Daniel Passos > wrote: > >> Hi Corinne, >> >> My idea is move all we need to example apps and integration test for >> a new server project or use aerogear-jaxrs-demo > > +1 > > >> >> -- >> Daniel Passos >> >> On December 5, 2013 at 10:52:12 AM, Corinne Krych >> (corinnekrych at gmail.com ) wrote: >> >>> I understand the issues and problems but that brings the topic how >>> are we going to demo, let's say in iOS cookbook features that >>> involved server part? >>> TODO app were used to demo Pipe. I cross reference TODO app in here: >>> https://github.com/aerogear/aerogear-ios-cookbook#table-of-content >>> >>> Something raised in this thread >>> http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Android-multipart-cookbook-component-td3553.html >>> >>> >>> ++ >>> Corinne >>> >>> On Dec 5, 2013, at 1:34 PM, Daniel Bevenius >>> > wrote: >>> >>> > +1 On dropping it. >>> > >>> > >>> > On 5 December 2013 13:32, Bruno Oliveira > wrote: >>> > Good morning peeps, regarding this threadhttp://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-TODO-app-abandoning-td4576.html. >>> Somehow we agreed in the past to no longer support this app >>> http://transcripts.jboss.org/channel/irc.freenode.org/%23aerogear/2013/%23aerogear.2013-01-28.log. >>> >>> > >>> > I?ve been chatting with Christos about my concern around this app: >>> > >>> > - This app still make use of ag-controller and outdated versions of ag security >>> > - Maintain it is very time consuming >>> > - We need to monitor OpenShift because after a period of inactivity the app will be disabled >>> > >>> > That said I vote for just drop or no longer maintain this app and update our integration tests. But before move forward with it, I would like to hear the concerns from the team about it. >>> > >>> > If I don?t hear anything, the application will be dropped from OpenShift. If the team agree on maintain it, we need a call for arms to do it. >>> > >>> > -- >>> > abstractj >>> > >>> > JBoss, a division of Red Hat >>> > >>> > >>> > >>> > _______________________________________________ >>> > 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 From supittma at redhat.com Fri Dec 6 12:16:21 2013 From: supittma at redhat.com (Summers Pittman) Date: Fri, 06 Dec 2013 12:16:21 -0500 Subject: [aerogear-dev] how about this API for sync? In-Reply-To: References: Message-ID: <52A20665.8080800@redhat.com> One of the questions I have about this API is how are push events handled with sync or is this just an offline cache? IE how is data sent down to the client when things change (or is that not for this use case) On Wed 04 Dec 2013 04:09:30 AM EST, Erik Jan de Wit wrote: > Just to get some discussions going and have something to talk about > I?ve drafted some API, so what do you think? > > // [option 1 fully automatic we create a pipe and add the posibilty to > add a store for failover and sync just happens at on- and offline events] > // and because merging can fail users can add a conflict handlers > Builder builder = > Builder.createPipe(pipeConfig).addFailoverStore(storeConfig); > Pipe pipe = builder.pipe(Car.class); > pipe.addConfictHandler(new ConflictHandler() { > public void conflict(Field originalField, Field newField) { > // user interaction > } > }); > // [option 2 explicit let the user specify when to sync and what to sync] > SyncedPipe pipe = SyncPipeBuilder.build(options); // SyncPipe Store > and Pipe togheter > // or we only use a store to sync and tell the sync manager where to > sync to > SyncManager syncManager = new SyncManger(); > syncManger.filter(readFilter); // maybe we don't want to sync all data > but just some part > syncManager.addConnectionHandler(new ConnectionHandler() { > public void onConnection() { > syncManger.sync(pipe); > } > }); > syncManger.addConfictHandler(new ConflictHandler() { > public void conflict(Field original, Field new) { > // user interaction > } > }); > > Cheers, > Erik Jan > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From edewit at redhat.com Mon Dec 9 02:44:59 2013 From: edewit at redhat.com (Erik Jan de Wit) Date: Mon, 9 Dec 2013 08:44:59 +0100 Subject: [aerogear-dev] how about this API for sync? In-Reply-To: <52A20665.8080800@redhat.com> References: <52A20665.8080800@redhat.com> Message-ID: <44873EDC-1C3D-4F7D-ACC2-29B155F25D65@redhat.com> My idea was that when the client calls sync the server side state and the client side state get merged and the delta is send On 6 Dec,2013, at 18:16 , Summers Pittman wrote: > One of the questions I have about this API is how are push events handled with sync or is this just an offline cache? > > IE how is data sent down to the client when things change (or is that not for this use case) > From daniel.bevenius at gmail.com Mon Dec 9 02:57:15 2013 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Mon, 9 Dec 2013 08:57:15 +0100 Subject: [aerogear-dev] Team Meeting Message-ID: Agenda: http://oksoclap.com/p/aerogear-team-mgt-20131209 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20131209/504eb259/attachment.html From edewit at redhat.com Mon Dec 9 04:18:33 2013 From: edewit at redhat.com (Erik Jan de Wit) Date: Mon, 9 Dec 2013 10:18:33 +0100 Subject: [aerogear-dev] status Message-ID: <6C46F5AE-428D-421E-8FCF-D202CF6B43A6@redhat.com> Blockers: None Last Week: Created video of Cordova plugin with Push https://www.youtube.com/watch?v=ypJBOJrD7y4 Tested jboss tools Angular 2 way binding Android POC Learned grunt Hackergarten Sync API proposal This Week: Prepare presentation and keynote GWTCreate Integrate binding POC with AGPad demo -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20131209/41d5cb36/attachment.html From kpiwko at redhat.com Mon Dec 9 07:35:48 2013 From: kpiwko at redhat.com (Karel Piwko) Date: Mon, 9 Dec 2013 13:35:48 +0100 Subject: [aerogear-dev] TODO app abandon - continues.... In-Reply-To: References: Message-ID: <20131209133548.13db5988@kapy-ntb-x220> Drop seems fine from QE POV. We can temporarily use forked TODO app, yet is longer timeframe we'll migrate to use something jaxrs-demo based. Karel On Thu, 5 Dec 2013 10:32:54 -0200 Bruno Oliveira wrote: > Good morning peeps, regarding this > thread?http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-TODO-app-abandoning-td4576.html. > Somehow we agreed in the past to no longer support this > app?http://transcripts.jboss.org/channel/irc.freenode.org/%23aerogear/2013/%23aerogear.2013-01-28.log. > > I?ve been chatting with Christos about my concern around this app: > > - This app still make use of ag-controller and outdated versions of ag > security > - Maintain it is very time consuming > - We need to monitor OpenShift because after a period of inactivity the app > will be disabled > > That said I vote for just drop or no longer maintain this app and update our > integration tests. But before move forward with it, I would like to hear the > concerns from the team about it. > > If I don?t hear anything, the application will be dropped from OpenShift. If > the team agree on maintain it, we need a call for arms to do it. > > --? > abstractj > > JBoss, a division of Red Hat > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From supittma at redhat.com Mon Dec 9 08:27:14 2013 From: supittma at redhat.com (Summers Pittman) Date: Mon, 09 Dec 2013 08:27:14 -0500 Subject: [aerogear-dev] how about this API for sync? In-Reply-To: <44873EDC-1C3D-4F7D-ACC2-29B155F25D65@redhat.com> References: <52A20665.8080800@redhat.com> <44873EDC-1C3D-4F7D-ACC2-29B155F25D65@redhat.com> Message-ID: <52A5C532.9040908@redhat.com> On Mon 09 Dec 2013 02:44:59 AM EST, Erik Jan de Wit wrote: > My idea was that when the client calls sync the server side state and the client side state get merged and the delta is send So this would also require a server definition? > > On 6 Dec,2013, at 18:16 , Summers Pittman wrote: > >> One of the questions I have about this API is how are push events handled with sync or is this just an offline cache? >> >> IE how is data sent down to the client when things change (or is that not for this use case) >> > From scm.blanc at gmail.com Mon Dec 9 08:30:56 2013 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Mon, 9 Dec 2013 14:30:56 +0100 Subject: [aerogear-dev] how about this API for sync? In-Reply-To: <52A5C532.9040908@redhat.com> References: <52A20665.8080800@redhat.com> <44873EDC-1C3D-4F7D-ACC2-29B155F25D65@redhat.com> <52A5C532.9040908@redhat.com> Message-ID: On Mon, Dec 9, 2013 at 2:27 PM, Summers Pittman wrote: > On Mon 09 Dec 2013 02:44:59 AM EST, Erik Jan de Wit wrote: > > My idea was that when the client calls sync the server side state and > the client side state get merged and the delta is send > So this would also require a server definition? > I have the same interrogations, what do we want do deliver : - an Unified Synch Server ( USS ) - Client Libs (ios, android, web, cordova plugin) > > > On 6 Dec,2013, at 18:16 , Summers Pittman wrote: > > > >> One of the questions I have about this API is how are push events > handled with sync or is this just an offline cache? > >> > >> IE how is data sent down to the client when things change (or is that > not for this use case) > >> > > > > > _______________________________________________ > 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/20131209/f67ace56/attachment.html From edewit at redhat.com Mon Dec 9 09:56:52 2013 From: edewit at redhat.com (Erik Jan de Wit) Date: Mon, 9 Dec 2013 15:56:52 +0100 Subject: [aerogear-dev] how about this API for sync? In-Reply-To: References: <52A20665.8080800@redhat.com> <44873EDC-1C3D-4F7D-ACC2-29B155F25D65@redhat.com> <52A5C532.9040908@redhat.com> Message-ID: <7C6E47FF-0BFB-4183-9A91-A6E3D18F520B@redhat.com> This proposal is just java based client API, if we nail down how a user could build an app that has sync functionality, all other things will fall into place. I suggest we keep the protocol and the server implementation as simple as possible and like qmx also suggested. JSON based with a hash as revision number for merging. On 9 Dec,2013, at 14:30 , Sebastien Blanc wrote: > > > > On Mon, Dec 9, 2013 at 2:27 PM, Summers Pittman wrote: > On Mon 09 Dec 2013 02:44:59 AM EST, Erik Jan de Wit wrote: > > My idea was that when the client calls sync the server side state and the client side state get merged and the delta is send > So this would also require a server definition? > I have the same interrogations, what do we want do deliver : > > - an Unified Synch Server ( USS ) > - Client Libs (ios, android, web, cordova plugin) > > > > > On 6 Dec,2013, at 18:16 , Summers Pittman wrote: > > > >> One of the questions I have about this API is how are push events handled with sync or is this just an offline cache? > >> > >> IE how is data sent down to the client when things change (or is that not for this use case) > >> > > > > > _______________________________________________ > 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/20131209/dbd53cc6/attachment-0001.html From cvasilak at gmail.com Mon Dec 9 10:45:40 2013 From: cvasilak at gmail.com (Christos Vasilakis) Date: Mon, 9 Dec 2013 17:45:40 +0200 Subject: [aerogear-dev] Team Meeting In-Reply-To: References: Message-ID: fyi meeting minutes links: Meeting ended Mon Dec 9 15:36:47 2013 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) [5:44pm]jbott:Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2013/aerogear.2013-12-09-14.53.html [5:44pm]jbott:Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2013/aerogear.2013-12-09-14.53.txt [5:44pm]jbott:Log: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2013/aerogear.2013-12-09-14.53.log.html On Dec 9, 2013, at 9:57 AM, Daniel Bevenius wrote: > Agenda: > http://oksoclap.com/p/aerogear-team-mgt-20131209 > _______________________________________________ > 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/20131209/ddcf3d6d/attachment.html From supittma at redhat.com Mon Dec 9 11:06:47 2013 From: supittma at redhat.com (Summers Pittman) Date: Mon, 09 Dec 2013 11:06:47 -0500 Subject: [aerogear-dev] how about this API for sync? In-Reply-To: <7C6E47FF-0BFB-4183-9A91-A6E3D18F520B@redhat.com> References: <52A20665.8080800@redhat.com> <44873EDC-1C3D-4F7D-ACC2-29B155F25D65@redhat.com> <52A5C532.9040908@redhat.com> <7C6E47FF-0BFB-4183-9A91-A6E3D18F520B@redhat.com> Message-ID: <52A5EA97.8080003@redhat.com> On 12/09/2013 09:56 AM, Erik Jan de Wit wrote: > This proposal is just java based client API, if we nail down how a > user could build an app that has sync functionality, all other things > will fall into place. I suggest we keep the protocol and the server > implementation as simple as possible and like qmx also suggested. JSON > based with a hash as revision number for merging. For real time sync this is a great primer: https://neil.fraser.name/writing/sync/. The concepts can be expanded beyond text of course. I guess my question is do we want a really low level but universal protocol which requires server support, or several separate APIs which can handle legacy servers, servers with minor changes, or real time capable servers? As examples: Legacy Servers can be periodic pollers. Minor changes can be a sync on push type thing. And realtime, is well, real time. > > On 9 Dec,2013, at 14:30 , Sebastien Blanc > wrote: > >> >> >> >> On Mon, Dec 9, 2013 at 2:27 PM, Summers Pittman > > wrote: >> >> On Mon 09 Dec 2013 02:44:59 AM EST, Erik Jan de Wit wrote: >> > My idea was that when the client calls sync the server side >> state and the client side state get merged and the delta is send >> So this would also require a server definition? >> >> I have the same interrogations, what do we want do deliver : >> >> - an Unified Synch Server ( USS ) >> - Client Libs (ios, android, web, cordova plugin) >> >> > >> > On 6 Dec,2013, at 18:16 , Summers Pittman > > wrote: >> > >> >> One of the questions I have about this API is how are push >> events handled with sync or is this just an offline cache? >> >> >> >> IE how is data sent down to the client when things change (or >> is that not for this use case) >> >> >> > >> >> >> _______________________________________________ >> 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/20131209/1bef02d0/attachment.html From daniel at passos.me Mon Dec 9 17:20:06 2013 From: daniel at passos.me (Daniel Passos) Date: Mon, 9 Dec 2013 20:20:06 -0200 Subject: [aerogear-dev] AeroGear Android Root Document Message-ID: Summers and I tossed around?the idea?last week to create a 'root document' how to build AeroGear android lib and apps. The idea is write a simple document?that?looks?like ActionBar Sherlock doc?instead of having a huge doc with lots of repeated setup, have a setup docs?which?branch from there Publish it on aerogear.org and link all others (like README) with it My draft for it is here:?https://gist.github.com/danielpassos/4b4e694c1c71473b4f59 wdyt? --? Daniel Passos -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20131209/1cf10847/attachment.html From hbons at redhat.com Mon Dec 9 18:29:28 2013 From: hbons at redhat.com (Hylke Bons) Date: Tue, 10 Dec 2013 00:29:28 +0100 Subject: [aerogear-dev] Initial UPS user management wireframes Message-ID: <52A65258.4010406@redhat.com> Hey everyone, Let's discuss the wireframes: https://github.com/hbons/aerogear-design/blob/master/aerogear_unified_push_server_admin_ui_baseline.png based on https://gist.github.com/sebastienblanc/6547605. The mockup is getting a little big and confusing now, so I've marked the new parts in orange. :) Feature wise we should be there. Let me know if you have any comments or if things are unclear, so they can be improved. Thanks, Hylke From edewit at redhat.com Tue Dec 10 02:34:47 2013 From: edewit at redhat.com (Erik Jan de Wit) Date: Tue, 10 Dec 2013 08:34:47 +0100 Subject: [aerogear-dev] how about this API for sync? In-Reply-To: <52A5EA97.8080003@redhat.com> References: <52A20665.8080800@redhat.com> <44873EDC-1C3D-4F7D-ACC2-29B155F25D65@redhat.com> <52A5C532.9040908@redhat.com> <7C6E47FF-0BFB-4183-9A91-A6E3D18F520B@redhat.com> <52A5EA97.8080003@redhat.com> Message-ID: On 9 Dec,2013, at 17:06 , Summers Pittman wrote: > For real time sync this is a great primer: https://neil.fraser.name/writing/sync/. The concepts can be expanded beyond text of course. That is a great article, but all these techniques are only cool for documents. We could support documents of course, but I was thinking more about Pipes and syncing those when one has been offline for a while. So for example when you have a Car that has make Toyota and one changes it to Toiota and another changes it Toyotas merging these to changes to Toiotas is always wrong. We don?t need merge support we only need conflict resolution. > > I guess my question is do we want a really low level but universal protocol which requires server support, or several separate APIs which can handle legacy servers, servers with minor changes, or real time capable servers? Cool idea to connect a legacy backend and let the front-end deal with the sync. But we can?t support conflict resolution in this scenario. For example client1 and client2 change the same car object. Client1 changes the property colour from red to green and client2 changes it from red to blue. The change of client1 takes place first then the change of client2 will be a conflict. Now to detect that conflict we could fetch the entity again and check if the colour is still the same as our original value, but it could change in the mean time again. So there is no guarantee that the data will be consistent. Of course we could periodically fetch data from a legacy server and merge that with the client state, but I don?t think that this is super useful the power of sync is changing things to be able to work offline. So I think we need a protocol, can be really simple just versioned JSON, and a server that will compare the changes and return conflicts. > > As examples: > Legacy Servers can be periodic pollers. > Minor changes can be a sync on push type thing. > And realtime, is well, real time. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20131210/e207f470/attachment-0001.html From scm.blanc at gmail.com Tue Dec 10 02:45:02 2013 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Tue, 10 Dec 2013 08:45:02 +0100 Subject: [aerogear-dev] Initial UPS user management wireframes In-Reply-To: <52A65258.4010406@redhat.com> References: <52A65258.4010406@redhat.com> Message-ID: Great job Hylke, I think you captured all the things defined in the spec draft. Just 2 remarks : - When creating an user , you added a "tip" saying you can create multiple users by separate them ";" , could be a nice feature, not sure it will be included in the first version. - The "last seen/login" field : not sure if it's really useful, wdyt ? On Tue, Dec 10, 2013 at 12:29 AM, Hylke Bons wrote: > Hey everyone, > > Let's discuss the wireframes: > > https://github.com/hbons/aerogear-design/blob/master/aerogear_unified_push_server_admin_ui_baseline.png > based on https://gist.github.com/sebastienblanc/6547605. > > The mockup is getting a little big and confusing now, so I've marked the > new parts in orange. :) > > Feature wise we should be there. Let me know if you have any comments or > if things are unclear, so they can be improved. > > Thanks, > > Hylke > _______________________________________________ > 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/20131210/789a998c/attachment.html From corinnekrych at gmail.com Tue Dec 10 03:00:05 2013 From: corinnekrych at gmail.com (Corinne Krych) Date: Tue, 10 Dec 2013 09:00:05 +0100 Subject: [aerogear-dev] AeroGear Android Root Document In-Reply-To: References: Message-ID: <19FA4209-6688-43C5-9153-757EE34E9F4A@gmail.com> Hello Daniel I really buy into your idea. We definitively need more consistent documentation on AeroGear features with concrete and simple exemple (like we started in cookbook). Let's refactor our documentation together and meake suure we go in the same direction. See Hylke thread on it [1]. As suggested by Hylke, let's group our documentation per category/features: core, push, security, offline/sync. We could have a general description of what the features is, some link to specs etc.. Then the sample part. Each sample/recipe(from cookbook) should be well documented and follow a similar template like you gist shown it. I've done similar with iOS-cookbook. One central readme [1] which list all recipes. Each recipes [2] has is own documentation following the same template. We ca work on unifying the template. I like prerequisites section, install/build section common to both, you miss a short description of the app and some ui flow with pictures would be nice and then a last sec ion we we explain the main fatures we want ot demo. A couple of questions on implementation though: - Instead of just having links to cookbook, how can we embed in asciidoc or markdown? the sample documentation should belong to the cookbook repo. - How are we going to publish read me info from cookbook into aerogear.org repo? a build or some sort of automation will be good. ++ Corinne [1] http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Website-restructure-td5246.html [1] https://github.com/corinnekrych/aerogear-ios-cookbook/blob/master/README.md [2] https://github.com/corinnekrych/aerogear-ios-cookbook/blob/master/Xmas/Xmas.md On Dec 9, 2013, at 11:20 PM, Daniel Passos wrote: > Summers and I tossed around the idea last week to create a 'root document' how to build AeroGear android lib and apps. > > The idea is write a simple document that looks like ActionBar Sherlock doc instead of having a huge doc with lots of repeated setup, have a setup docs which branch from there > > Publish it on aerogear.org and link all others (like README) with it > > My draft for it is here: https://gist.github.com/danielpassos/4b4e694c1c71473b4f59 > > wdyt? > > -- Daniel Passos > > _______________________________________________ > 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 Dec 10 03:11:49 2013 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Tue, 10 Dec 2013 09:11:49 +0100 Subject: [aerogear-dev] how about this API for sync? In-Reply-To: References: <52A20665.8080800@redhat.com> <44873EDC-1C3D-4F7D-ACC2-29B155F25D65@redhat.com> <52A5C532.9040908@redhat.com> <7C6E47FF-0BFB-4183-9A91-A6E3D18F520B@redhat.com> <52A5EA97.8080003@redhat.com> Message-ID: On Tue, Dec 10, 2013 at 8:34 AM, Erik Jan de Wit wrote: > > On 9 Dec,2013, at 17:06 , Summers Pittman wrote: > > For real time sync this is a great primer: > https://neil.fraser.name/writing/sync/. The concepts can be expanded > beyond text of course. > > > That is a great article, but all these techniques are only cool for > documents. We could support documents of course, but I was thinking more > about Pipes and syncing those when one has been offline for a while. So for > example when you have a Car that has make Toyota and one changes it to > Toiota and another changes it Toyotas merging these to changes to Toiotas > is always wrong. We don?t need merge support we only need conflict > resolution. > +1 > > > I guess my question is do we want a really low level but universal > protocol which requires server support, or several separate APIs which can > handle legacy servers, servers with minor changes, or real time capable > servers? > > > Cool idea to connect a legacy backend and let the front-end deal with the > sync. But we can?t support conflict resolution in this scenario. For > example client1 and client2 change the same car object. Client1 changes the > property colour from red to green and client2 changes it from red to blue. > The change of client1 takes place first then the change of client2 will be > a conflict. Now to detect that conflict we could fetch the entity again and > check if the colour is still the same as our original value, but it could > change in the mean time again. So there is no guarantee that the data will > be consistent. > > Of course we could periodically fetch data from a legacy server and merge > that with the client state, but I don?t think that this is super useful the > power of sync is changing things to be able to work offline. So I think we > need a protocol, can be really simple just versioned JSON, and a server > that will compare the changes and return conflicts. > Yes, let's keep it simple for now. So, here in this situation the server just report the conflict, right ? He does not take action on the conflict itself. Do we state here that the client will always be responsible in resolving the conflict ? In your first message, you define a ConflictHandler interface, do we also want to provide some implementations of the ConflictHandler that covers most of the use cases ? > > > As examples: > Legacy Servers can be periodic pollers. > Minor changes can be a sync on push type thing. > And realtime, is well, real time. > > > > _______________________________________________ > 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/20131210/24da459a/attachment.html From edewit at redhat.com Tue Dec 10 04:32:29 2013 From: edewit at redhat.com (Erik Jan de Wit) Date: Tue, 10 Dec 2013 10:32:29 +0100 Subject: [aerogear-dev] how about this API for sync? In-Reply-To: References: <52A20665.8080800@redhat.com> <44873EDC-1C3D-4F7D-ACC2-29B155F25D65@redhat.com> <52A5C532.9040908@redhat.com> <7C6E47FF-0BFB-4183-9A91-A6E3D18F520B@redhat.com> <52A5EA97.8080003@redhat.com> Message-ID: > > Yes, let's keep it simple for now. So, here in this situation the server just report the conflict, right ? He does not take action on the conflict itself. Do we state here that the client will always be responsible in resolving the conflict ? +1 for keeping it simple, right the server will report a conflict and the user will in the most simple scenario decide which change to keep. That is why I introduced this ConflictHandler so the developer can present these conflicts to the user. > In your first message, you define a ConflictHandler interface, do we also want to provide some implementations of the ConflictHandler that covers most of the use cases ? Sure we could have a default implementation that just takes the newest as the new version, but we should keep other version as well. From scm.blanc at gmail.com Tue Dec 10 06:14:58 2013 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Tue, 10 Dec 2013 12:14:58 +0100 Subject: [aerogear-dev] AG JS 1.3.1 In-Reply-To: <8C51AADD-1DEC-4D65-90DF-07243ED34D08@redhat.com> References: <8C51AADD-1DEC-4D65-90DF-07243ED34D08@redhat.com> Message-ID: Yo ! So, I've been playing with all these new features and it all works as expected. To test the stuff, I've done just a little modification to the AeroDoc Web Client to store the accepted leads in an indexedDB adapter with autoconnect : https://github.com/sebastienblanc/aerogear-push-quickstart-backend/blob/agjs-tests/src/main/webapp/client/scripts/services/dataService.js#L42-L47 On Chrome/FireFox, it stores the stuff in indexedDB and thanks to the autoconnect , I just have to do myStore.save() /read() On Opera, it nicely fallback to Websql. I have also used the "preferred" setting with passing "memory", again on Opera it falls back to "Memory". So, you have my "Go!" for the release Seb On Thu, Dec 5, 2013 at 9:21 PM, Lucas Holmquist wrote: > Hot on the heels of 1.3.0, i am hoping to release 1.3.1 next week. > > Here is a list of the JIRA's associated with it > > > https://issues.jboss.org/issues/?jql=project%20%3D%20AGJS%20AND%20fixVersion%20%3D%20%221.3.1%22%20ORDER%20BY%20updated%20DESC%2C%20priority%20DESC%2C%20created%20ASC > > There was some bug fixes and test/documentation updates, but there were 2 > big option added in DataManager: > > 1. Auto Connect > > Since IndexedDB and WebSQL needed to both be "opened" before doing a > read/save/remove/filter , i've added an option " auto" to the creation of a > store. It will default to false, so it will not break any existing stuff. > if set to true, then you can do the a read, for example and not have to > worry about calling open. > > 2. Opt-Out of Fallback and "preferred" > > this new option, 'fallback' will default to true, so data manager will > fallback to a support adapter by default, but if you want to make sure an > error is thrown if an adapter is not supported then you can set > fallback=false. > > there is also a new "preferred" option. By default when fallback is > enabled, this is the order the adapters are tried [ "IndexedDB", > "WebSQL", "SessionLocal", "Memory" ] > > now a user can specify a list of adapters they want to try, so they can > do [ "Memory" ] if they only want to fallback to the memory adapter if lets > say IndexedDB isn't available > > > > So give it a try > > > > _______________________________________________ > 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/20131210/69be31aa/attachment-0001.html From lholmqui at redhat.com Tue Dec 10 08:48:31 2013 From: lholmqui at redhat.com (Lucas Holmquist) Date: Tue, 10 Dec 2013 08:48:31 -0500 Subject: [aerogear-dev] Initial UPS user management wireframes In-Reply-To: References: <52A65258.4010406@redhat.com> Message-ID: On Dec 10, 2013, at 2:45 AM, Sebastien Blanc wrote: > Great job Hylke, I think you captured all the things defined in the spec draft. > > Just 2 remarks : > > - When creating an user , you added a "tip" saying you can create multiple users by separate them ";" , could be a nice feature, not sure it will be included in the first version. yea, could be nice, but not for 1.0 > - The "last seen/login" field : not sure if it's really useful, wdyt ? > agree that it probably isn't useful > > > > On Tue, Dec 10, 2013 at 12:29 AM, Hylke Bons wrote: > Hey everyone, > > Let's discuss the wireframes: > https://github.com/hbons/aerogear-design/blob/master/aerogear_unified_push_server_admin_ui_baseline.png > based on https://gist.github.com/sebastienblanc/6547605. > > The mockup is getting a little big and confusing now, so I've marked the > new parts in orange. :) > > Feature wise we should be there. Let me know if you have any comments or > if things are unclear, so they can be improved. > > Thanks, > > Hylke > _______________________________________________ > 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/20131210/5c442d1c/attachment.html From supittma at redhat.com Tue Dec 10 10:13:49 2013 From: supittma at redhat.com (Summers Pittman) Date: Tue, 10 Dec 2013 10:13:49 -0500 Subject: [aerogear-dev] how about this API for sync? In-Reply-To: References: <52A20665.8080800@redhat.com> <44873EDC-1C3D-4F7D-ACC2-29B155F25D65@redhat.com> <52A5C532.9040908@redhat.com> <7C6E47FF-0BFB-4183-9A91-A6E3D18F520B@redhat.com> <52A5EA97.8080003@redhat.com> Message-ID: <52A72FAD.5080601@redhat.com> On 12/10/2013 02:34 AM, Erik Jan de Wit wrote: > > On 9 Dec,2013, at 17:06 , Summers Pittman > wrote: > >> For real time sync this is a great primer: >> https://neil.fraser.name/writing/sync/. The concepts can be expanded >> beyond text of course. > > That is a great article, but all these techniques are only cool for > documents. This technique is good for synced text. We've hooked our horse to the JSON cart pretty hard so we should be able to deal with that for a large number of cases. > We could support documents of course, but I was thinking more about > Pipes and syncing those when one has been offline for a while. So Pipes aren't data per se. They are a one way query mechanism (IE the pipe doesn't start spewing data all over your living room floor for no reason.) Pipes can be used by Sync to fetch data once a signal to refresh has been received however. > So for example when you have a Car that has make Toyota and one > changes it to Toiota and another changes it Toyotas merging these to > changes to Toiotas is always wrong. We don't need merge support we > only need conflict resolution. 'Toiotas' Yes, 'Toiotas' (no cap) no. That would actually be correct in patch diff merge. > >> >> I guess my question is do we want a really low level but universal >> protocol which requires server support, or several separate APIs >> which can handle legacy servers, servers with minor changes, or real >> time capable servers? > > Cool idea to connect a legacy backend and let the front-end deal with > the sync. But we can't support conflict resolution in this scenario. We can limit legacy servers to read only data (from a client perspective). > For example client1 and client2 change the same car object. Client1 > changes the property colour from red to green and client2 changes it > from red to blue. The change of client1 takes place first then the > change of client2 will be a conflict. Now to detect that conflict we > could fetch the entity again and check if the colour is still the same > as our original value, but it could change in the mean time again. So > there is no guarantee that the data will be consistent. > > Of course we could periodically fetch data from a legacy server and > merge that with the client state, but I don't think that this is super > useful the power of sync is changing things to be able to work offline. Of course, offline is just laggy sync. But lets take two separate but similar legacy use cases. Downloading the weather forecast based on your location and synchronizing a todo list. The weather data probably won't change during the day. So every night at midnight + jitter our sync can download the forecast from a restful URL and be done. There is no conflict because the client data can not / will not change. This is a very simple case to implement. Syncing a Todo list is more complicated because it can change from multiple clients. HOWEVER the application has a restriction that todo list items may only be added and removed but not reordered or edited. The flow for that could look like 1. User 1 on Android creates a TODO list. 2. Android app creates TODO list copy on server. 3. Android app registers a sync with the server for the todo list 4. User 1 adds item to TODO list. 5. Server syncs its list with Users list. returns OK. 6. User 1 access his list in web app. 7. Web App registers a sync on the server with the todo list. 8. User 1 Edits his list. 9. Web App applies edits and sends deltas to Android app. 10. repeate ad nausiem. In this case conflicts can only happen if a user deletes the same item (no practical conflict). So a conflict resolver will be trivial. > So I think we need a protocol, can be really simple just versioned > JSON, and a server that will compare the changes and return conflicts. Yeah. The more I poke and play with things the less certain I am that adding it to the pipe is a good idea. I think we need something separate. > >> >> As examples: >> Legacy Servers can be periodic pollers. >> Minor changes can be a sync on push type thing. >> And realtime, is well, real time. >> > > > > _______________________________________________ > 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/20131210/b22325bd/attachment.html From supittma at redhat.com Tue Dec 10 10:49:37 2013 From: supittma at redhat.com (Summers Pittman) Date: Tue, 10 Dec 2013 10:49:37 -0500 Subject: [aerogear-dev] More Sync Message-ID: <52A73811.5000102@redhat.com> So as I mentioned in the meeting I am dog fooding some sync ideas on Android in the form of a DevNexus app. Here are the two main interfaces that have precipitated out so far: https://gist.github.com/secondsun/df6724e89d7ae06cbb64 *Warning Android Gory Details begin here* I am working towards a PeriodicSyncAdapter that I mentioned in a previous email. Android has this type of functionality built in but it is VERY VERY heavy on boilerplate, XML, and complexity. I want to build something which is lighter. My current idea is to create a BroadcastReceiver which users can register. The SynchronicationConfigs (no code to share but they are just Key/Value Pojo's) will be instantiated into Synchronizers using a Sychcronize factory class (think Pipeline). The Sychcronize factory will tell the BroadcastReceiver about the Synchronizers, but the Sychronizers will be what does the data loading, saving, scheduleing, etc. The Synchronizer and BroadcastReceiver are separate classes. The BroadcastReceiver will be setup in the AndroidManifest.xml file and the Synchronizer will be managed by user code. The reason they BroadcastReceiver isn't managed by user code is because Android won't wake up code which isn't in the AndroidManifest. IE if a sync event happens while the app is not running then the sync will not happen. Summers -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20131210/d1ffd172/attachment.html From scm.blanc at gmail.com Tue Dec 10 11:16:36 2013 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Tue, 10 Dec 2013 17:16:36 +0100 Subject: [aerogear-dev] how about this API for sync? In-Reply-To: <52A72FAD.5080601@redhat.com> References: <52A20665.8080800@redhat.com> <44873EDC-1C3D-4F7D-ACC2-29B155F25D65@redhat.com> <52A5C532.9040908@redhat.com> <7C6E47FF-0BFB-4183-9A91-A6E3D18F520B@redhat.com> <52A5EA97.8080003@redhat.com> <52A72FAD.5080601@redhat.com> Message-ID: On Tue, Dec 10, 2013 at 4:13 PM, Summers Pittman wrote: > On 12/10/2013 02:34 AM, Erik Jan de Wit wrote: > > > On 9 Dec,2013, at 17:06 , Summers Pittman wrote: > > For real time sync this is a great primer: > https://neil.fraser.name/writing/sync/. The concepts can be expanded > beyond text of course. > > > That is a great article, but all these techniques are only cool for > documents. > > This technique is good for synced text. We've hooked our horse to the > JSON cart pretty hard so we should be able to deal with that for a large > number of cases. > > We could support documents of course, but I was thinking more about > Pipes and syncing those when one has been offline for a while. > > So Pipes aren't data per se. They are a one way query mechanism (IE the > pipe doesn't start spewing data all over your living room floor for no > reason.) Pipes can be used by Sync to fetch data once a signal to refresh > has been received however. > > So for example when you have a Car that has make Toyota and one changes > it to Toiota and another changes it Toyotas merging these to changes to > Toiotas is always wrong. We don?t need merge support we only need > conflict resolution. > > 'Toiotas' Yes, 'Toiotas' (no cap) no. That would actually be correct in > patch diff merge. > What's the difference between these 2 ? Bu the point of Erik was that we don't want this kind of merge, no ? > > > > > I guess my question is do we want a really low level but universal > protocol which requires server support, or several separate APIs which can > handle legacy servers, servers with minor changes, or real time capable > servers? > > > Cool idea to connect a legacy backend and let the front-end deal with > the sync. But we can?t support conflict resolution in this scenario. > > We can limit legacy servers to read only data (from a client perspective). > > For example client1 and client2 change the same car object. Client1 > changes the property colour from red to green and client2 changes it from > red to blue. The change of client1 takes place first then the change of > client2 will be a conflict. Now to detect that conflict we could fetch the > entity again and check if the colour is still the same as our original > value, but it could change in the mean time again. So there is no guarantee > that the data will be consistent. > > Of course we could periodically fetch data from a legacy server and > merge that with the client state, but I don?t think that this is super > useful the power of sync is changing things to be able to work offline. > > > Of course, offline is just laggy sync. > > But lets take two separate but similar legacy use cases. Downloading the > weather forecast based on your location and synchronizing a todo list. > > The weather data probably won't change during the day. So every night at > midnight + jitter our sync can download the forecast from a restful URL and > be done. There is no conflict because the client data can not / will not > change. This is a very simple case to implement. > > Syncing a Todo list is more complicated because it can change from > multiple clients. HOWEVER the application has a restriction that todo list > items may only be added and removed but not reordered or edited. > > The flow for that could look like > > 1. User 1 on Android creates a TODO list. > 2. Android app creates TODO list copy on server. > 3. Android app registers a sync with the server for the todo list > 4. User 1 adds item to TODO list. > 5. Server syncs its list with Users list. returns OK. > 6. User 1 access his list in web app. > 7. Web App registers a sync on the server with the todo list. > 8. User 1 Edits his list. > 9. Web App applies edits and sends deltas to Android app. > 10. repeate ad nausiem. > > In this case conflicts can only happen if a user deletes the same item (no > practical conflict). So a conflict resolver will be trivial. > > > So I think we need a protocol, can be really simple just versioned JSON, > and a server that will compare the changes and return conflicts. > > Yeah. The more I poke and play with things the less certain I am that > adding it to the pipe is a good idea. I think we need something separate. > > > > As examples: > Legacy Servers can be periodic pollers. > Minor changes can be a sync on push type thing. > And realtime, is well, real time. > > > > > _______________________________________________ > aerogear-dev mailing listaerogear-dev at lists.jboss.orghttps://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/20131210/148bdec7/attachment-0001.html From edewit at redhat.com Tue Dec 10 11:39:44 2013 From: edewit at redhat.com (Erik Jan de Wit) Date: Tue, 10 Dec 2013 17:39:44 +0100 Subject: [aerogear-dev] how about this API for sync? In-Reply-To: <52A72FAD.5080601@redhat.com> References: <52A20665.8080800@redhat.com> <44873EDC-1C3D-4F7D-ACC2-29B155F25D65@redhat.com> <52A5C532.9040908@redhat.com> <7C6E47FF-0BFB-4183-9A91-A6E3D18F520B@redhat.com> <52A5EA97.8080003@redhat.com> <52A72FAD.5080601@redhat.com> Message-ID: >> >> That is a great article, but all these techniques are only cool for documents. > This technique is good for synced text. We've hooked our horse to the JSON cart pretty hard so we should be able to deal with that for a large number of cases. Yes, synced text and yes JSON, is text as well, but it does not make sense to merge JSON because merging this data will always be wrong! I?ll use the car example one more time: one user wants to change from Toyotas to Toyota and another user wants to change from Toyotas to Toiotas when a system merges those changes to Toiota it (the system) made up it?s own change and really nobody wanted that to happen. If I would write a book and changed a paragraph and somebody else was writing a paragraph in the same book merging those would make sense. >> We could support documents of course, but I was thinking more about Pipes and syncing those when one has been offline for a while. > So Pipes aren't data per se. They are a one way query mechanism (IE the pipe doesn't start spewing data all over your living room floor for no reason.) Pipes can be used by Sync to fetch data once a signal to refresh has been received however. So you see no use case to make Pipes able to sync, because I think it would be a nice addition >> Cool idea to connect a legacy backend and let the front-end deal with the sync. But we can?t support conflict resolution in this scenario. > We can limit legacy servers to read only data (from a client perspective). So my idea of sync is to be able to work offline and then sync the data back to the server when I?m online again. Just getting data from a server periodically is not really what I had in mind for syncing, I think that it doesn?t need an API, one can just fetch data again in an OnlineEvent. From supittma at redhat.com Tue Dec 10 12:58:10 2013 From: supittma at redhat.com (Summers Pittman) Date: Tue, 10 Dec 2013 12:58:10 -0500 Subject: [aerogear-dev] how about this API for sync? In-Reply-To: References: <52A20665.8080800@redhat.com> <44873EDC-1C3D-4F7D-ACC2-29B155F25D65@redhat.com> <52A5C532.9040908@redhat.com> <7C6E47FF-0BFB-4183-9A91-A6E3D18F520B@redhat.com> <52A5EA97.8080003@redhat.com> <52A72FAD.5080601@redhat.com> Message-ID: <52A75632.1040406@redhat.com> On 12/10/2013 11:39 AM, Erik Jan de Wit wrote: >>> That is a great article, but all these techniques are only cool for documents. >> This technique is good for synced text. We've hooked our horse to the JSON cart pretty hard so we should be able to deal with that for a large number of cases. > Yes, synced text and yes JSON, is text as well, but it does not make sense to merge JSON because merging this data will always be wrong! I?ll use the car example one more time: one user wants to change from Toyotas to Toyota and another user wants to change from Toyotas to Toiotas when a system merges those changes to Toiota it (the system) made up it?s own change and really nobody wanted that to happen. Hi, diff merge patch covers your example without generating a conflict. https://neil.fraser.name/software/diff_match_patch/svn/trunk/demos/demo_patch.html > > If I would write a book and changed a paragraph and somebody else was writing a paragraph in the same book merging those would make sense. > >>> We could support documents of course, but I was thinking more about Pipes and syncing those when one has been offline for a while. >> So Pipes aren't data per se. They are a one way query mechanism (IE the pipe doesn't start spewing data all over your living room floor for no reason.) Pipes can be used by Sync to fetch data once a signal to refresh has been received however. > So you see no use case to make Pipes able to sync, because I think it would be a nice addition I don't feel like Pipes are the thing that does syncing. Does HTTP sync? Does SQL sync? The answer to both cases are no. But an applicaiton can use both HTTP and SQL to do what we are thinking of when we say sync. > >>> Cool idea to connect a legacy backend and let the front-end deal with the sync. But we can?t support conflict resolution in this scenario. >> We can limit legacy servers to read only data (from a client perspective). > So my idea of sync is to be able to work offline and then sync the data back to the server when I?m online again. Just getting data from a server periodically is not really what I had in mind for syncing, I think that it doesn?t need an API, one can just fetch data again in an OnlineEvent. It is still a valid use case for online support and there is a TON of work around just that with mobile. 1) adding a jitter to when you sync so the server doesn't get every user hitting it at the exact same time 2) retry and exponential backoff 3) notifying the external system of data changes 4) Managing and batching sync operations so that we don't kill the battery. Just because I want to start with a simple use case doesn't mean you can dismiss the use case. > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From supittma at redhat.com Tue Dec 10 12:59:39 2013 From: supittma at redhat.com (Summers Pittman) Date: Tue, 10 Dec 2013 12:59:39 -0500 Subject: [aerogear-dev] how about this API for sync? In-Reply-To: References: <52A20665.8080800@redhat.com> <44873EDC-1C3D-4F7D-ACC2-29B155F25D65@redhat.com> <52A5C532.9040908@redhat.com> <7C6E47FF-0BFB-4183-9A91-A6E3D18F520B@redhat.com> <52A5EA97.8080003@redhat.com> <52A72FAD.5080601@redhat.com> Message-ID: <52A7568B.7040607@redhat.com> On 12/10/2013 11:16 AM, Sebastien Blanc wrote: > > > > On Tue, Dec 10, 2013 at 4:13 PM, Summers Pittman > wrote: > > On 12/10/2013 02:34 AM, Erik Jan de Wit wrote: >> >> On 9 Dec,2013, at 17:06 , Summers Pittman > > wrote: >> >>> For real time sync this is a great primer: >>> https://neil.fraser.name/writing/sync/. The concepts can be >>> expanded beyond text of course. >> >> That is a great article, but all these techniques are only cool >> for documents. > This technique is good for synced text. We've hooked our horse to > the JSON cart pretty hard so we should be able to deal with that > for a large number of cases. >> We could support documents of course, but I was thinking more >> about Pipes and syncing those when one has been offline for a while. > So Pipes aren't data per se. They are a one way query mechanism > (IE the pipe doesn't start spewing data all over your living room > floor for no reason.) Pipes can be used by Sync to fetch data > once a signal to refresh has been received however. > >> So for example when you have a Car that has make Toyota and one >> changes it to Toiota and another changes it Toyotas merging these >> to changes to Toiotas is always wrong. We don't need merge >> support we only need conflict resolution. > 'Toiotas' Yes, 'Toiotas' (no cap) no. That would actually be > correct in patch diff merge. > > What's the difference between these 2 ? > Bu the point of Erik was that we don't want this kind of merge, no ? The difference is we have different opinions, use cases, and ideas of "correct". Our users will also have said ideas so our solution should make it possible for both to be supported (even if we only provide one). > > >> >>> >>> I guess my question is do we want a really low level but >>> universal protocol which requires server support, or several >>> separate APIs which can handle legacy servers, servers with >>> minor changes, or real time capable servers? >> >> Cool idea to connect a legacy backend and let the front-end deal >> with the sync. But we can't support conflict resolution in this >> scenario. > We can limit legacy servers to read only data (from a client > perspective). > >> For example client1 and client2 change the same car object. >> Client1 changes the property colour from red to green and client2 >> changes it from red to blue. The change of client1 takes place >> first then the change of client2 will be a conflict. Now to >> detect that conflict we could fetch the entity again and check if >> the colour is still the same as our original value, but it could >> change in the mean time again. So there is no guarantee that the >> data will be consistent. >> >> Of course we could periodically fetch data from a legacy server >> and merge that with the client state, but I don't think that this >> is super useful the power of sync is changing things to be able >> to work offline. > > Of course, offline is just laggy sync. > > But lets take two separate but similar legacy use cases. > Downloading the weather forecast based on your location and > synchronizing a todo list. > > The weather data probably won't change during the day. So every > night at midnight + jitter our sync can download the forecast from > a restful URL and be done. There is no conflict because the client > data can not / will not change. This is a very simple case to > implement. > > Syncing a Todo list is more complicated because it can change > from multiple clients. HOWEVER the application has a restriction > that todo list items may only be added and removed but not > reordered or edited. > > The flow for that could look like > > 1. User 1 on Android creates a TODO list. > 2. Android app creates TODO list copy on server. > 3. Android app registers a sync with the server for the todo list > 4. User 1 adds item to TODO list. > 5. Server syncs its list with Users list. returns OK. > 6. User 1 access his list in web app. > 7. Web App registers a sync on the server with the todo list. > 8. User 1 Edits his list. > 9. Web App applies edits and sends deltas to Android app. > 10. repeate ad nausiem. > > In this case conflicts can only happen if a user deletes the same > item (no practical conflict). So a conflict resolver will be > trivial. > > >> So I think we need a protocol, can be really simple just >> versioned JSON, and a server that will compare the changes and >> return conflicts. > Yeah. The more I poke and play with things the less certain I am > that adding it to the pipe is a good idea. I think we need > something separate. >> >>> >>> As examples: >>> Legacy Servers can be periodic pollers. >>> Minor changes can be a sync on push type thing. >>> And realtime, is well, real time. >>> >> >> >> >> _______________________________________________ >> 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/20131210/a5241882/attachment-0001.html From bruno at abstractj.org Tue Dec 10 14:45:30 2013 From: bruno at abstractj.org (Bruno Oliveira) Date: Tue, 10 Dec 2013 17:45:30 -0200 Subject: [aerogear-dev] how about this API for sync? In-Reply-To: <52A7568B.7040607@redhat.com> References: <52A20665.8080800@redhat.com> <44873EDC-1C3D-4F7D-ACC2-29B155F25D65@redhat.com> <52A5C532.9040908@redhat.com> <7C6E47FF-0BFB-4183-9A91-A6E3D18F520B@redhat.com> <52A5EA97.8080003@redhat.com> <52A72FAD.5080601@redhat.com> <52A7568B.7040607@redhat.com> Message-ID: Sorry because I got lost into this thread, but do we have any use case scenarios to understand which problem we are willing to solve? I think would be nice to start to enumerate at least 3 and choose 1 to stay focused. Thoughts? -- abstractj On December 10, 2013 at 3:59:45 PM, Summers Pittman (supittma at redhat.com) wrote: > > The difference is we have different opinions, use cases, and > ideas of "correct". Our users will also have said ideas so our > solution should make it possible for both to be supported (even > if we only provide one). From lholmqui at redhat.com Tue Dec 10 16:02:08 2013 From: lholmqui at redhat.com (Lucas Holmquist) Date: Tue, 10 Dec 2013 16:02:08 -0500 Subject: [aerogear-dev] AG JS 1.3.1 In-Reply-To: References: <8C51AADD-1DEC-4D65-90DF-07243ED34D08@redhat.com> Message-ID: <6F6474F9-B91A-4F2D-9870-C3FF368A46E0@redhat.com> On Dec 10, 2013, at 6:14 AM, Sebastien Blanc wrote: > Yo ! > So, I've been playing with all these new features and it all works as expected. To test the stuff, I've done just a little modification to the AeroDoc Web Client to store the accepted leads in an indexedDB adapter with autoconnect : https://github.com/sebastienblanc/aerogear-push-quickstart-backend/blob/agjs-tests/src/main/webapp/client/scripts/services/dataService.js#L42-L47 > > On Chrome/FireFox, it stores the stuff in indexedDB and thanks to the autoconnect , I just have to do myStore.save() /read() > On Opera, it nicely fallback to Websql. > > I have also used the "preferred" setting with passing "memory", again on Opera it falls back to "Memory". > > So, you have my "Go!" for the release coolio, i'll probably do it tomorrow afternoon then > Seb > > > > > On Thu, Dec 5, 2013 at 9:21 PM, Lucas Holmquist wrote: > Hot on the heels of 1.3.0, i am hoping to release 1.3.1 next week. > > Here is a list of the JIRA's associated with it > > https://issues.jboss.org/issues/?jql=project%20%3D%20AGJS%20AND%20fixVersion%20%3D%20%221.3.1%22%20ORDER%20BY%20updated%20DESC%2C%20priority%20DESC%2C%20created%20ASC > > There was some bug fixes and test/documentation updates, but there were 2 big option added in DataManager: > > 1. Auto Connect > > Since IndexedDB and WebSQL needed to both be "opened" before doing a read/save/remove/filter , i've added an option " auto" to the creation of a store. It will default to false, so it will not break any existing stuff. if set to true, then you can do the a read, for example and not have to worry about calling open. > > 2. Opt-Out of Fallback and "preferred" > > this new option, 'fallback' will default to true, so data manager will fallback to a support adapter by default, but if you want to make sure an error is thrown if an adapter is not supported then you can set fallback=false. > > there is also a new "preferred" option. By default when fallback is enabled, this is the order the adapters are tried [ "IndexedDB", "WebSQL", "SessionLocal", "Memory" ] > > now a user can specify a list of adapters they want to try, so they can do [ "Memory" ] if they only want to fallback to the memory adapter if lets say IndexedDB isn't available > > > > So give it a try > > > > _______________________________________________ > 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/20131210/1ddfd0b8/attachment.html From scm.blanc at gmail.com Tue Dec 10 16:09:23 2013 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Tue, 10 Dec 2013 22:09:23 +0100 Subject: [aerogear-dev] how about this API for sync? In-Reply-To: References: <52A20665.8080800@redhat.com> <44873EDC-1C3D-4F7D-ACC2-29B155F25D65@redhat.com> <52A5C532.9040908@redhat.com> <7C6E47FF-0BFB-4183-9A91-A6E3D18F520B@redhat.com> <52A5EA97.8080003@redhat.com> <52A72FAD.5080601@redhat.com> <52A7568B.7040607@redhat.com> Message-ID: Agreed, we could use Summer's table as start point and extract maybe more "concrete" use cases from it ? https://gist.github.com/secondsun/e6552abfbf51ed915d92#file-table-of-contents-md Use Case Push/PollRealtimeServer APIs UsedPeriodic Read Only Update PollNAny legacyPipelines, Authentication, Stores Real Time Read Only UpdatePush Y(ish)Legacy + Updates for Unified PushUnified Push, Store Simple Settings Sync PushY(ish)Legacy + Updates for Unified Push + Updates for conflict mgmtPipelines, Authentication, UnifiedPush, Store Real Time Text SyncPush YNeeds lots of custom code, vert.x realtime componentUnifiedPush, Store On Tue, Dec 10, 2013 at 8:45 PM, Bruno Oliveira wrote: > Sorry because I got lost into this thread, but do we have any use case > scenarios to understand which problem we are willing to solve? > > I think would be nice to start to enumerate at least 3 and choose 1 to > stay focused. Thoughts? > > -- > abstractj > > On December 10, 2013 at 3:59:45 PM, Summers Pittman (supittma at redhat.com) > wrote: > > > The difference is we have different opinions, use cases, and > > ideas of "correct". Our users will also have said ideas so our > > solution should make it possible for both to be supported (even > > if we only provide one). > > _______________________________________________ > 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/20131210/7108a65e/attachment.html From bruno at abstractj.org Tue Dec 10 18:48:39 2013 From: bruno at abstractj.org (Bruno Oliveira) Date: Tue, 10 Dec 2013 21:48:39 -0200 Subject: [aerogear-dev] how about this API for sync? In-Reply-To: References: <52A20665.8080800@redhat.com> <44873EDC-1C3D-4F7D-ACC2-29B155F25D65@redhat.com> <52A5C532.9040908@redhat.com> <7C6E47FF-0BFB-4183-9A91-A6E3D18F520B@redhat.com> <52A5EA97.8080003@redhat.com> <52A72FAD.5080601@redhat.com> <52A7568B.7040607@redhat.com> Message-ID: +1 to include this table at our documentation?https://github.com/aerogear/aerogear.org/blob/6de2250fca9150110ec03eee2af7f5418cbe44b8/docs/specs/aerogear-data-sync/index.md Do we have any scenario for detecting synchronization conflicts between client and server?? -- abstractj On December 10, 2013 at 7:09:53 PM, Sebastien Blanc (scm.blanc at gmail.com) wrote: > > Agreed, we could use Summer's table as start point and extract > maybe more > "concrete" use cases from it ? > > https://gist.github.com/secondsun/e6552abfbf51ed915d92#file-table-of-contents-md > > Use Case Push/PollRealtimeServer APIs UsedPeriodic Read Only > Update > PollNAny legacyPipelines, > Authentication, Stores Real Time Read Only UpdatePush Y(ish)Legacy > + > Updates for Unified PushUnified Push, Store Simple Settings > Sync > PushY(ish)Legacy + Updates for Unified Push + Updates for conflict > mgmtPipelines, > Authentication, UnifiedPush, Store Real Time Text SyncPush > YNeeds lots of > custom code, vert.x realtime componentUnifiedPush, Store > > > On Tue, Dec 10, 2013 at 8:45 PM, Bruno Oliveira > wrote: > > > Sorry because I got lost into this thread, but do we have any use > case > > scenarios to understand which problem we are willing to solve? > > > > I think would be nice to start to enumerate at least 3 and choose > 1 to > > stay focused. Thoughts? > > > > -- > > abstractj > > > > On December 10, 2013 at 3:59:45 PM, Summers Pittman (supittma at redhat.com) > > wrote: > > > > The difference is we have different opinions, use cases, > and > > > ideas of "correct". Our users will also have said ideas so our > > > solution should make it possible for both to be supported (even > > > if we only provide one). > > > > _______________________________________________ > > 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 bsutter at redhat.com Tue Dec 10 22:13:59 2013 From: bsutter at redhat.com (Burr Sutter) Date: Tue, 10 Dec 2013 22:13:59 -0500 Subject: [aerogear-dev] Hybrid Cordova Tooling Message-ID: <994985BF-D5A6-481C-B858-10E03A096766@redhat.com> Camtasia gave me fits trying to get this recorded. https://vimeo.com/81565404 In JBDS 7.1 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20131210/51d56155/attachment-0001.html From edewit at redhat.com Wed Dec 11 02:30:37 2013 From: edewit at redhat.com (Erik Jan de Wit) Date: Wed, 11 Dec 2013 08:30:37 +0100 Subject: [aerogear-dev] how about this API for sync? In-Reply-To: <52A75632.1040406@redhat.com> References: <52A20665.8080800@redhat.com> <44873EDC-1C3D-4F7D-ACC2-29B155F25D65@redhat.com> <52A5C532.9040908@redhat.com> <7C6E47FF-0BFB-4183-9A91-A6E3D18F520B@redhat.com> <52A5EA97.8080003@redhat.com> <52A72FAD.5080601@redhat.com> <52A75632.1040406@redhat.com> Message-ID: > > Just because I want to start with a simple use case doesn't mean you can > dismiss the use case. > I don?t want to dismiss anything just wanted to know what you think about my idea to combine a pipe and store to create a pipe that continues to work when the user goes offline. Obviously you don?t feel my idea makes any sense and I think that you sync isn?t a super powerful feature to have (there are to many pre conditions in my opinion), but we could have it, not dismissing it. What do others think about this discussion? What use cases should we support first? Can you think of other ways/things to sync? From daniel.bevenius at gmail.com Wed Dec 11 04:37:19 2013 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Wed, 11 Dec 2013 10:37:19 +0100 Subject: [aerogear-dev] how about this API for sync? In-Reply-To: References: <52A20665.8080800@redhat.com> <44873EDC-1C3D-4F7D-ACC2-29B155F25D65@redhat.com> <52A5C532.9040908@redhat.com> <7C6E47FF-0BFB-4183-9A91-A6E3D18F520B@redhat.com> <52A5EA97.8080003@redhat.com> <52A72FAD.5080601@redhat.com> <52A75632.1040406@redhat.com> Message-ID: First, I appreciate the discussion in this thread as this is all new to me. > What use cases should we support first? I'd be for looking into the document use case first, and hold off with the transactional/Operational Transformation one for now. This mainly because is seems to be a lot simpler. qmx suggested using something similar to CouchDB. CouchDB uses a revision field for each document to handle/detect conflicts. The following is a concrete example of how this works with CouchDB: Create a database: curl -X PUT http://127.0.0.1:5984/agsync {"ok":true} Get a uuid: curl -X GET http://127.0.0.1:5984/_uuids {"uuids":["f11075199bcea80849204660d7000d53"]} Create a car object(document) using the above uuid: curl -X PUT http://127.0.0.1:5984/agsync/f11075199bcea80849204660d7000d53-d '{"car": {"make":"Toyota", "color":"red"}}' {"ok":true,"id":"f11075199bcea80849204660d7000d53","rev":"1-dffbd1dbd1b9ecbffc1b02a34cbaea0b"} Notice that the server returned a new document revision. Now clientA updates the car object, notice that we are specifying the document revision: curl -X PUT http://127.0.0.1:5984/agsync/f11075199bcea80849204660d7000d53-d '{"_rev":"1-dffbd1dbd1b9ecbffc1b02a34cbaea0b", "car": {"make":"Toyota","color":"blue"}}' {"ok":true,"id":"f11075199bcea80849204660d7000d53","rev":"2-588a9da2e252e9a3d2fc0634610a0c25"} Also, notice how the server returned a new document revision. Now, clientB still has the old revision and tries to update the car object: curl -v -X PUT http://127.0.0.1:5984/agsync/f11075199bcea80849204660d7000d53 -d '{"_rev":"1-dffbd1dbd1b9ecbffc1b02a34cbaea0b", "car": {"make":"Toyota","color":"yellow"}}' < HTTP/1.1 409 Conflict {"error":"conflict","reason":"Document update conflict."} This conflict would the have to be handled by the client. Could we start out with something similar and as simple as this and evolve it? On 11 December 2013 08:30, Erik Jan de Wit wrote: > > > > Just because I want to start with a simple use case doesn't mean you can > > dismiss the use case. > > > > > I don?t want to dismiss anything just wanted to know what you think about > my idea to combine a pipe and store to create a pipe that continues to work > when the user goes offline. Obviously you don?t feel my idea makes any > sense and I think that you sync isn?t a super powerful feature to have > (there are to many pre conditions in my opinion), but we could have it, not > dismissing it. > > What do others think about this discussion? What use cases should we > support first? Can you think of other ways/things to sync? > _______________________________________________ > 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/20131211/2e2dad4e/attachment.html From bruno at abstractj.org Wed Dec 11 04:44:50 2013 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 11 Dec 2013 07:44:50 -0200 Subject: [aerogear-dev] how about this API for sync? In-Reply-To: References: <52A20665.8080800@redhat.com> <44873EDC-1C3D-4F7D-ACC2-29B155F25D65@redhat.com> <52A5C532.9040908@redhat.com> <7C6E47FF-0BFB-4183-9A91-A6E3D18F520B@redhat.com> <52A5EA97.8080003@redhat.com> <52A72FAD.5080601@redhat.com> <52A75632.1040406@redhat.com> Message-ID: Very very very simple with CounchDB +4242424242 -- abstractj On December 11, 2013 at 7:37:51 AM, Daniel Bevenius (daniel.bevenius at gmail.com) wrote: > > This conflict would the have to be handled by the client. Could > we start out with something similar and as simple as this and evolve > it? From edewit at redhat.com Wed Dec 11 05:21:26 2013 From: edewit at redhat.com (Erik Jan de Wit) Date: Wed, 11 Dec 2013 11:21:26 +0100 Subject: [aerogear-dev] how about this API for sync? In-Reply-To: References: <52A20665.8080800@redhat.com> <44873EDC-1C3D-4F7D-ACC2-29B155F25D65@redhat.com> <52A5C532.9040908@redhat.com> <7C6E47FF-0BFB-4183-9A91-A6E3D18F520B@redhat.com> <52A5EA97.8080003@redhat.com> <52A72FAD.5080601@redhat.com> <52A75632.1040406@redhat.com> Message-ID: That is what I suggested, but then at the same time connect that to pipes and stores, but we can start even simpler and first develop something like this. On 11 Dec,2013, at 10:37 , Daniel Bevenius wrote: > First, I appreciate the discussion in this thread as this is all new to me. > > > What use cases should we support first? > I'd be for looking into the document use case first, and hold off with the transactional/Operational Transformation one for now. This mainly because is seems to be a lot simpler. > > qmx suggested using something similar to CouchDB. CouchDB uses a revision field for each document to handle/detect conflicts. > The following is a concrete example of how this works with CouchDB: > > Create a database: > curl -X PUT http://127.0.0.1:5984/agsync > {"ok":true} > > Get a uuid: > curl -X GET http://127.0.0.1:5984/_uuids > {"uuids":["f11075199bcea80849204660d7000d53"]} > > Create a car object(document) using the above uuid: > curl -X PUT http://127.0.0.1:5984/agsync/f11075199bcea80849204660d7000d53 -d '{"car": {"make":"Toyota", "color":"red"}}' > {"ok":true,"id":"f11075199bcea80849204660d7000d53","rev":"1-dffbd1dbd1b9ecbffc1b02a34cbaea0b"} > > Notice that the server returned a new document revision. > > Now clientA updates the car object, notice that we are specifying the document revision: > curl -X PUT http://127.0.0.1:5984/agsync/f11075199bcea80849204660d7000d53 -d '{"_rev":"1-dffbd1dbd1b9ecbffc1b02a34cbaea0b", "car": {"make":"Toyota","color":"blue"}}' > {"ok":true,"id":"f11075199bcea80849204660d7000d53","rev":"2-588a9da2e252e9a3d2fc0634610a0c25"} > > Also, notice how the server returned a new document revision. > > Now, clientB still has the old revision and tries to update the car object: > curl -v -X PUT http://127.0.0.1:5984/agsync/f11075199bcea80849204660d7000d53 -d '{"_rev":"1-dffbd1dbd1b9ecbffc1b02a34cbaea0b", "car": {"make":"Toyota","color":"yellow"}}' > < HTTP/1.1 409 Conflict > {"error":"conflict","reason":"Document update conflict."} > This conflict would the have to be handled by the client. Could we start out with something similar and as simple as this and evolve it? > > > > On 11 December 2013 08:30, Erik Jan de Wit wrote: > > > > Just because I want to start with a simple use case doesn't mean you can > > dismiss the use case. > > > > > I don?t want to dismiss anything just wanted to know what you think about my idea to combine a pipe and store to create a pipe that continues to work when the user goes offline. Obviously you don?t feel my idea makes any sense and I think that you sync isn?t a super powerful feature to have (there are to many pre conditions in my opinion), but we could have it, not dismissing it. > > What do others think about this discussion? What use cases should we support first? Can you think of other ways/things to sync? > _______________________________________________ > 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/20131211/173eff6d/attachment-0001.html From bruno at abstractj.org Wed Dec 11 05:21:36 2013 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 11 Dec 2013 08:21:36 -0200 Subject: [aerogear-dev] Jiras for Data synchronization Message-ID: Good morning peeps, I?ve started with Dan a four hands data sync umbrella and you are invited to join, add, change it:?https://issues.jboss.org/browse/AEROGEAR-1374 I think this might help us to focus on what do we need. -- abstractj From corinnekrych at gmail.com Wed Dec 11 05:21:52 2013 From: corinnekrych at gmail.com (Corinne Krych) Date: Wed, 11 Dec 2013 11:21:52 +0100 Subject: [aerogear-dev] how about this API for sync? In-Reply-To: References: <52A20665.8080800@redhat.com> <44873EDC-1C3D-4F7D-ACC2-29B155F25D65@redhat.com> <52A5C532.9040908@redhat.com> <7C6E47FF-0BFB-4183-9A91-A6E3D18F520B@redhat.com> <52A5EA97.8080003@redhat.com> <52A72FAD.5080601@redhat.com> <52A75632.1040406@redhat.com> Message-ID: <801D2DC7-ABB2-4823-AE16-9DAE428A9FAB@gmail.com> Hi all, Here's my view: Different options at different levels. Some options are corellated. SyncManager: when to trigger: 1. periodically 2. automatic: online/offline detection 3. manually Server vs peer-to-peer context 1. server context with revision tag, client send his updates, conflict resolution server side 2. no prior context : http://conferences.sigcomm.org/sigcomm/2011/papers/sigcomm/p218.pdf - queing push - pull Granularity 1. Document based. revision at object/fields level. 2. OT Conflicts resolution: 1. reject 2. proposed merge 3. prompt user Like Dan, I think we could have several implementations of sync depending on the use cases and let the end user (developer) picks the right one ffor the job. But we need to start with one of them, simplest one would be: - manual trigger sync - server side context with revision number - offline caching - client send his updates - server conflicts resolution with rejection of client changes ++ Corinne On Dec 11, 2013, at 10:37 AM, Daniel Bevenius wrote: > First, I appreciate the discussion in this thread as this is all new to me. > > > What use cases should we support first? > I'd be for looking into the document use case first, and hold off with the transactional/Operational Transformation one for now. This mainly because is seems to be a lot simpler. > > qmx suggested using something similar to CouchDB. CouchDB uses a revision field for each document to handle/detect conflicts. > The following is a concrete example of how this works with CouchDB: > > Create a database: > curl -X PUT http://127.0.0.1:5984/agsync > {"ok":true} > > Get a uuid: > curl -X GET http://127.0.0.1:5984/_uuids > {"uuids":["f11075199bcea80849204660d7000d53"]} > > Create a car object(document) using the above uuid: > curl -X PUT http://127.0.0.1:5984/agsync/f11075199bcea80849204660d7000d53 -d '{"car": {"make":"Toyota", "color":"red"}}' > {"ok":true,"id":"f11075199bcea80849204660d7000d53","rev":"1-dffbd1dbd1b9ecbffc1b02a34cbaea0b"} > > Notice that the server returned a new document revision. > > Now clientA updates the car object, notice that we are specifying the document revision: > curl -X PUT http://127.0.0.1:5984/agsync/f11075199bcea80849204660d7000d53 -d '{"_rev":"1-dffbd1dbd1b9ecbffc1b02a34cbaea0b", "car": {"make":"Toyota","color":"blue"}}' > {"ok":true,"id":"f11075199bcea80849204660d7000d53","rev":"2-588a9da2e252e9a3d2fc0634610a0c25"} > > Also, notice how the server returned a new document revision. > > Now, clientB still has the old revision and tries to update the car object: > curl -v -X PUT http://127.0.0.1:5984/agsync/f11075199bcea80849204660d7000d53 -d '{"_rev":"1-dffbd1dbd1b9ecbffc1b02a34cbaea0b", "car": {"make":"Toyota","color":"yellow"}}' > < HTTP/1.1 409 Conflict > {"error":"conflict","reason":"Document update conflict."} > This conflict would the have to be handled by the client. Could we start out with something similar and as simple as this and evolve it? > > > > On 11 December 2013 08:30, Erik Jan de Wit wrote: > > > > Just because I want to start with a simple use case doesn't mean you can > > dismiss the use case. > > > > > I don?t want to dismiss anything just wanted to know what you think about my idea to combine a pipe and store to create a pipe that continues to work when the user goes offline. Obviously you don?t feel my idea makes any sense and I think that you sync isn?t a super powerful feature to have (there are to many pre conditions in my opinion), but we could have it, not dismissing it. > > What do others think about this discussion? What use cases should we support first? Can you think of other ways/things to sync? > _______________________________________________ > 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 supittma at redhat.com Wed Dec 11 09:35:38 2013 From: supittma at redhat.com (Summers Pittman) Date: Wed, 11 Dec 2013 09:35:38 -0500 Subject: [aerogear-dev] how about this API for sync? In-Reply-To: References: <52A20665.8080800@redhat.com> <44873EDC-1C3D-4F7D-ACC2-29B155F25D65@redhat.com> <52A5C532.9040908@redhat.com> <7C6E47FF-0BFB-4183-9A91-A6E3D18F520B@redhat.com> <52A5EA97.8080003@redhat.com> <52A72FAD.5080601@redhat.com> <52A7568B.7040607@redhat.com> Message-ID: <52A8783A.9090904@redhat.com> On 12/10/2013 06:48 PM, Bruno Oliveira wrote: > +1 to include this table at our documentation https://github.com/aerogear/aerogear.org/blob/6de2250fca9150110ec03eee2af7f5418cbe44b8/docs/specs/aerogear-data-sync/index.md > > Do we have any scenario for detecting synchronization conflicts between client and server? We've straw manned a few. Least complex: The user has a set features on two devices each with their own settings. These are synchronized over all of the user's devices. On the first device he disables a feature (and thus all of its settings), but on the second device he enables settings for the feature he disabled on the other device. How do these resolve and how is the resolution transmitted. More complex: Multiple users are editing a todo list. Two users delete the first item. How do we ensure that only one item is deleted? (Or how do we build our APIs and protocol so that the backend server deletes only one item) Most complex: N (where N is > 2) edit the same document and create conflicts. How do we enable resolving all of these and resyncing the original document. Even more most complex: The same about but with an Image / binary data/ etc. > > -- > abstractj > > On December 10, 2013 at 7:09:53 PM, Sebastien Blanc (scm.blanc at gmail.com) wrote: >> >> Agreed, we could use Summer's table as start point and extract >> maybe more >> "concrete" use cases from it ? >> >> https://gist.github.com/secondsun/e6552abfbf51ed915d92#file-table-of-contents-md >> >> Use Case Push/PollRealtimeServer APIs UsedPeriodic Read Only >> Update >> PollNAny legacyPipelines, >> Authentication, Stores Real Time Read Only UpdatePush Y(ish)Legacy >> + >> Updates for Unified PushUnified Push, Store Simple Settings >> Sync >> PushY(ish)Legacy + Updates for Unified Push + Updates for conflict >> mgmtPipelines, >> Authentication, UnifiedPush, Store Real Time Text SyncPush >> YNeeds lots of >> custom code, vert.x realtime componentUnifiedPush, Store >> >> >> On Tue, Dec 10, 2013 at 8:45 PM, Bruno Oliveira >> wrote: >> >>> Sorry because I got lost into this thread, but do we have any use >> case >>> scenarios to understand which problem we are willing to solve? >>> >>> I think would be nice to start to enumerate at least 3 and choose >> 1 to >>> stay focused. Thoughts? >>> >>> -- >>> abstractj >>> >>> On December 10, 2013 at 3:59:45 PM, Summers Pittman (supittma at redhat.com) >>> wrote: >>>>> The difference is we have different opinions, use cases, >> and >>>> ideas of "correct". Our users will also have said ideas so our >>>> solution should make it possible for both to be supported (even >>>> if we only provide one). >>> _______________________________________________ >>> 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 supittma at redhat.com Wed Dec 11 09:47:09 2013 From: supittma at redhat.com (Summers Pittman) Date: Wed, 11 Dec 2013 09:47:09 -0500 Subject: [aerogear-dev] how about this API for sync? In-Reply-To: References: <52A20665.8080800@redhat.com> <44873EDC-1C3D-4F7D-ACC2-29B155F25D65@redhat.com> <52A5C532.9040908@redhat.com> <7C6E47FF-0BFB-4183-9A91-A6E3D18F520B@redhat.com> <52A5EA97.8080003@redhat.com> <52A72FAD.5080601@redhat.com> <52A75632.1040406@redhat.com> Message-ID: <52A87AED.80702@redhat.com> On 12/11/2013 04:44 AM, Bruno Oliveira wrote: > Very very very simple with CounchDB +4242424242 > One of my concerns with Couch is it is another application/server/dependency to package and keep up with. Of course if we want to build an aerogear-sync-server application instead of an aerogear-sync-sererver spec that servers can implement it makes a lot more sense. Can CouchDB be embedded in a Java EE application? From daniel.bevenius at gmail.com Wed Dec 11 09:56:43 2013 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Wed, 11 Dec 2013 15:56:43 +0100 Subject: [aerogear-dev] how about this API for sync? In-Reply-To: <52A87AED.80702@redhat.com> References: <52A20665.8080800@redhat.com> <44873EDC-1C3D-4F7D-ACC2-29B155F25D65@redhat.com> <52A5C532.9040908@redhat.com> <7C6E47FF-0BFB-4183-9A91-A6E3D18F520B@redhat.com> <52A5EA97.8080003@redhat.com> <52A72FAD.5080601@redhat.com> <52A75632.1040406@redhat.com> <52A87AED.80702@redhat.com> Message-ID: >One of my concerns with Couch is it is another application/server/dependency to package and keep up with. The suggestion is that we do something similar to CouchDB and perhaps lend some ideas from their protocol and how they handle conflicts. Not that we base this on CouchDB, sorry if this was confusing. A server implementation might start off delegating to a CouchDB instance just to get up and running. This way our client libs would have something work against. On 11 December 2013 15:47, Summers Pittman wrote: > On 12/11/2013 04:44 AM, Bruno Oliveira wrote: > > Very very very simple with CounchDB +4242424242 > > > One of my concerns with Couch is it is another > application/server/dependency to package and keep up with. > > Of course if we want to build an aerogear-sync-server application > instead of an aerogear-sync-sererver spec that servers can implement it > makes a lot more sense. > > Can CouchDB be embedded in a Java EE application? > _______________________________________________ > 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/20131211/57691ad3/attachment.html From aemmanou at redhat.com Wed Dec 11 10:22:13 2013 From: aemmanou at redhat.com (Apostolos Emmanouilidis) Date: Wed, 11 Dec 2013 16:22:13 +0100 Subject: [aerogear-dev] how about this API for sync? In-Reply-To: References: <52A20665.8080800@redhat.com> <44873EDC-1C3D-4F7D-ACC2-29B155F25D65@redhat.com> <52A5C532.9040908@redhat.com> <7C6E47FF-0BFB-4183-9A91-A6E3D18F520B@redhat.com> <52A5EA97.8080003@redhat.com> <52A72FAD.5080601@redhat.com> <52A75632.1040406@redhat.com> Message-ID: <1386775333.1866.21.camel@dhcp129-205.brq.redhat.com> +1 for starting with an implementation similar to CouchDB. This looks like the Offline Lock pattern where there are version stamps and a client cannot fulfill a transaction if he has an old current version stamp. Regarding the concepts that Summers sent https://neil.fraser.name/writing/sync/ I feel that are some Open Source implementations of these concepts out there. e.g google-diff-match-patch[1] And something more, there is a security parameter in the data sync concept. The database might contain data which should be visible/accessible to all the clients. [1]: https://code.google.com/p/google-diff-match-patch/ On Wed, 2013-12-11 at 10:37 +0100, Daniel Bevenius wrote: > This conflict would the have to be handled by the client. Could we > start out with something similar and as simple as this and evolve it? From aemmanou at redhat.com Wed Dec 11 10:26:55 2013 From: aemmanou at redhat.com (Apostolos Emmanouilidis) Date: Wed, 11 Dec 2013 16:26:55 +0100 Subject: [aerogear-dev] how about this API for sync? In-Reply-To: <1386775333.1866.21.camel@dhcp129-205.brq.redhat.com> References: <52A20665.8080800@redhat.com> <44873EDC-1C3D-4F7D-ACC2-29B155F25D65@redhat.com> <52A5C532.9040908@redhat.com> <7C6E47FF-0BFB-4183-9A91-A6E3D18F520B@redhat.com> <52A5EA97.8080003@redhat.com> <52A72FAD.5080601@redhat.com> <52A75632.1040406@redhat.com> <1386775333.1866.21.camel@dhcp129-205.brq.redhat.com> Message-ID: <1386775615.1866.23.camel@dhcp129-205.brq.redhat.com> apologies, just a correction. The security concern is that the database might contain data which should be NOT visible/accessible to all the clients. On Wed, 2013-12-11 at 16:22 +0100, Apostolos Emmanouilidis wrote: > +1 for starting with an implementation similar to CouchDB. This looks > like the Offline Lock pattern where there are version stamps and a > client cannot fulfill a transaction if he has an old current version > stamp. > > Regarding the concepts that Summers sent > https://neil.fraser.name/writing/sync/ I feel that are some Open Source > implementations of these concepts out there. > e.g google-diff-match-patch[1] > > And something more, there is a security parameter in the data sync > concept. The database might contain data which should be > visible/accessible to all the clients. > > [1]: https://code.google.com/p/google-diff-match-patch/ > > > On Wed, 2013-12-11 at 10:37 +0100, Daniel Bevenius wrote: > > > > This conflict would the have to be handled by the client. Could we > > start out with something similar and as simple as this and evolve it? > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From lholmqui at redhat.com Wed Dec 11 10:33:42 2013 From: lholmqui at redhat.com (Lucas Holmquist) Date: Wed, 11 Dec 2013 10:33:42 -0500 Subject: [aerogear-dev] how about this API for sync? In-Reply-To: <1386775615.1866.23.camel@dhcp129-205.brq.redhat.com> References: <52A20665.8080800@redhat.com> <44873EDC-1C3D-4F7D-ACC2-29B155F25D65@redhat.com> <52A5C532.9040908@redhat.com> <7C6E47FF-0BFB-4183-9A91-A6E3D18F520B@redhat.com> <52A5EA97.8080003@redhat.com> <52A72FAD.5080601@redhat.com> <52A75632.1040406@redhat.com> <1386775333.1866.21.camel@dhcp129-205.brq.redhat.com> <1386775615.1866.23.camel@dhcp129-205.brq.redhat.com> Message-ID: wanted to dump some thoughts i was having Client Side Perspective let me try to dump some of the client side thoughts i have, which will probably be more javascript centric i see data sync as keeping DataManager stores in sync with the server side not sure if it makes sense without it? I can see using Notifier using sockJS connecting to a netty server(?) to do the "real-time" updates Sync should be plugable, so an existing REST application using DataManager can just add it in or turn it off easily the sync should have some events that the user can "listen" for, to deal with conflict/changes and such there is another type of sync that i'm also thinking off. Since Pipeline and Datamanager are not tied to each other, do we want to think about the possiblity of "syncing" them. that is when i do a read currently on a pipe, i have to manually store the data, should that be automatic, this used to happen in the way begining of pipeline, but we removed it since we wanted to keep it modular On Dec 11, 2013, at 10:26 AM, Apostolos Emmanouilidis wrote: > apologies, just a correction. The security concern is that the database > might contain data which should be NOT visible/accessible to all the > clients. > > On Wed, 2013-12-11 at 16:22 +0100, Apostolos Emmanouilidis wrote: >> +1 for starting with an implementation similar to CouchDB. This looks >> like the Offline Lock pattern where there are version stamps and a >> client cannot fulfill a transaction if he has an old current version >> stamp. >> >> Regarding the concepts that Summers sent >> https://neil.fraser.name/writing/sync/ I feel that are some Open Source >> implementations of these concepts out there. >> e.g google-diff-match-patch[1] >> >> And something more, there is a security parameter in the data sync >> concept. The database might contain data which should be >> visible/accessible to all the clients. >> >> [1]: https://code.google.com/p/google-diff-match-patch/ >> >> >> On Wed, 2013-12-11 at 10:37 +0100, Daniel Bevenius wrote: >> >> >>> This conflict would the have to be handled by the client. Could we >>> start out with something similar and as simple as this and evolve it? >> >> >> >> _______________________________________________ >> 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/20131211/262278bf/attachment.html From supittma at redhat.com Wed Dec 11 10:48:40 2013 From: supittma at redhat.com (Summers Pittman) Date: Wed, 11 Dec 2013 10:48:40 -0500 Subject: [aerogear-dev] how about this API for sync? In-Reply-To: References: <52A20665.8080800@redhat.com> <44873EDC-1C3D-4F7D-ACC2-29B155F25D65@redhat.com> <52A5C532.9040908@redhat.com> <7C6E47FF-0BFB-4183-9A91-A6E3D18F520B@redhat.com> <52A5EA97.8080003@redhat.com> <52A72FAD.5080601@redhat.com> <52A75632.1040406@redhat.com> <52A87AED.80702@redhat.com> Message-ID: <52A88958.90908@redhat.com> On 12/11/2013 09:56 AM, Daniel Bevenius wrote: > >One of my concerns with Couch is it is another > application/server/dependency to package and keep up with. > The suggestion is that we do something similar to CouchDB and perhaps > lend some ideas from their protocol and how they handle conflicts. Not > that we base this on CouchDB, sorry if this was confusing. > A server implementation might start off delegating to a CouchDB > instance just to get up and running. This way our client libs would > have something work against. > Ok, just wanted to make sure. > > > > > > On 11 December 2013 15:47, Summers Pittman > wrote: > > On 12/11/2013 04:44 AM, Bruno Oliveira wrote: > > Very very very simple with CounchDB +4242424242 > > > One of my concerns with Couch is it is another > application/server/dependency to package and keep up with. > > Of course if we want to build an aerogear-sync-server application > instead of an aerogear-sync-sererver spec that servers can > implement it > makes a lot more sense. > > Can CouchDB be embedded in a Java EE application? > _______________________________________________ > 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/20131211/91c3e4a4/attachment.html From scm.blanc at gmail.com Wed Dec 11 11:13:02 2013 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Wed, 11 Dec 2013 17:13:02 +0100 Subject: [aerogear-dev] how about this API for sync? In-Reply-To: References: <52A20665.8080800@redhat.com> <44873EDC-1C3D-4F7D-ACC2-29B155F25D65@redhat.com> <52A5C532.9040908@redhat.com> <7C6E47FF-0BFB-4183-9A91-A6E3D18F520B@redhat.com> <52A5EA97.8080003@redhat.com> <52A72FAD.5080601@redhat.com> <52A75632.1040406@redhat.com> <1386775333.1866.21.camel@dhcp129-205.brq.redhat.com> <1386775615.1866.23.camel@dhcp129-205.brq.redhat.com> Message-ID: On Wed, Dec 11, 2013 at 4:33 PM, Lucas Holmquist wrote: > wanted to dump some thoughts i was having > Client Side Perspective > > let me try to dump some of the client side thoughts i have, which will > probably be more javascript centric > > - > > i see data sync as keeping DataManager stores in sync with the server > side > - > > not sure if it makes sense without it? > - > > I can see using Notifier using sockJS connecting to a netty server(?) > to do the "real-time" updates > - > > Sync should be plugable, so an existing REST application using > DataManager can just add it in or turn it off easily > - > > the sync should have some events that the user can "listen" for, to > deal with conflict/changes and such > - > > there is another type of sync that i'm also thinking off. > > Since Pipeline and Datamanager are not tied to each other, do we want > to think about the possiblity of "syncing" them. that is when i do a read > currently on a pipe, i have to manually store the data, should that be > automatic, this used to happen in the way begining of pipeline, but we > removed it since we wanted to keep it modular > > Yes, I think that makes totally sense. If you it should be automatic, well, we could configure it to be or not. In the same spirit, I was thinking of some kind of storeFallback option we can pass to a pipe. If we call a read on a pipe and there is no connection, we fallback automatically on the local store to retrieve the data (with some metadata/flag saying it's local data). > > > On Dec 11, 2013, at 10:26 AM, Apostolos Emmanouilidis > wrote: > > apologies, just a correction. The security concern is that the database > might contain data which should be NOT visible/accessible to all the > clients. > > On Wed, 2013-12-11 at 16:22 +0100, Apostolos Emmanouilidis wrote: > > +1 for starting with an implementation similar to CouchDB. This looks > like the Offline Lock pattern where there are version stamps and a > client cannot fulfill a transaction if he has an old current version > stamp. > > Regarding the concepts that Summers sent > https://neil.fraser.name/writing/sync/ I feel that are some Open Source > implementations of these concepts out there. > e.g google-diff-match-patch[1] > > And something more, there is a security parameter in the data sync > concept. The database might contain data which should be > visible/accessible to all the clients. > > [1]: https://code.google.com/p/google-diff-match-patch/ > > > On Wed, 2013-12-11 at 10:37 +0100, Daniel Bevenius wrote: > > > This conflict would the have to be handled by the client. Could we > start out with something similar and as simple as this and evolve it? > > > > > _______________________________________________ > 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/20131211/85c5eafc/attachment-0001.html From supittma at redhat.com Wed Dec 11 11:14:16 2013 From: supittma at redhat.com (Summers Pittman) Date: Wed, 11 Dec 2013 11:14:16 -0500 Subject: [aerogear-dev] Updated website sync branch Message-ID: <52A88F58.7000300@redhat.com> Hey guys, I've added to the sync branch some of the stuff from the jumbo thread. Feel free to cram in your bits that I may have ignored, glossed over, forgotten, etc https://github.com/aerogear/aerogear.org/commit/db760e0f40d43c77a785b27f72856675f28b79af Also, we should probably start shaving up the jumbo thread into smaller threads. Summers From corinnekrych at gmail.com Wed Dec 11 11:24:11 2013 From: corinnekrych at gmail.com (Corinne Krych) Date: Wed, 11 Dec 2013 17:24:11 +0100 Subject: [aerogear-dev] how about this API for sync? In-Reply-To: References: <52A20665.8080800@redhat.com> <44873EDC-1C3D-4F7D-ACC2-29B155F25D65@redhat.com> <52A5C532.9040908@redhat.com> <7C6E47FF-0BFB-4183-9A91-A6E3D18F520B@redhat.com> <52A5EA97.8080003@redhat.com> <52A72FAD.5080601@redhat.com> <52A75632.1040406@redhat.com> <1386775333.1866.21.camel@dhcp129-205.brq.redhat.com> <1386775615.1866.23.camel@dhcp129-205.brq.redhat.com> Message-ID: <3DC41C42-65FD-4A0F-8448-CA6EF537A89C@gmail.com> Interesting link to understand 'a la couchDB': http://docs.couchbase.com/couchbase-lite/cbl-concepts/#introduction that comes will iOS/Android client implementation. ++ Corinne On Dec 11, 2013, at 5:13 PM, Sebastien Blanc wrote: > > > > On Wed, Dec 11, 2013 at 4:33 PM, Lucas Holmquist wrote: > wanted to dump some thoughts i was having > Client Side Perspective > > let me try to dump some of the client side thoughts i have, which will probably be more javascript centric > > ? i see data sync as keeping DataManager stores in sync with the server side > > ? not sure if it makes sense without it? > > ? I can see using Notifier using sockJS connecting to a netty server(?) to do the "real-time" updates > > ? Sync should be plugable, so an existing REST application using DataManager can just add it in or turn it off easily > > ? the sync should have some events that the user can "listen" for, to deal with conflict/changes and such > > ? there is another type of sync that i'm also thinking off. > > Since Pipeline and Datamanager are not tied to each other, do we want to think about the possiblity of "syncing" them. that is when i do a read currently on a pipe, i have to manually store the data, should that be automatic, this used to happen in the way begining of pipeline, but we removed it since we wanted to keep it modular > > Yes, I think that makes totally sense. If you it should be automatic, well, we could configure it to be or not. In the same spirit, I was thinking of some kind of storeFallback option we can pass to a pipe. If we call a read on a pipe and there is no connection, we fallback automatically on the local store to retrieve the data (with some metadata/flag saying it's local data). > > > On Dec 11, 2013, at 10:26 AM, Apostolos Emmanouilidis wrote: > >> apologies, just a correction. The security concern is that the database >> might contain data which should be NOT visible/accessible to all the >> clients. >> >> On Wed, 2013-12-11 at 16:22 +0100, Apostolos Emmanouilidis wrote: >>> +1 for starting with an implementation similar to CouchDB. This looks >>> like the Offline Lock pattern where there are version stamps and a >>> client cannot fulfill a transaction if he has an old current version >>> stamp. >>> >>> Regarding the concepts that Summers sent >>> https://neil.fraser.name/writing/sync/ I feel that are some Open Source >>> implementations of these concepts out there. >>> e.g google-diff-match-patch[1] >>> >>> And something more, there is a security parameter in the data sync >>> concept. The database might contain data which should be >>> visible/accessible to all the clients. >>> >>> [1]: https://code.google.com/p/google-diff-match-patch/ >>> >>> >>> On Wed, 2013-12-11 at 10:37 +0100, Daniel Bevenius wrote: >>> >>> >>>> This conflict would the have to be handled by the client. Could we >>>> start out with something similar and as simple as this and evolve it? >>> >>> >>> >>> _______________________________________________ >>> 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 From lholmqui at redhat.com Wed Dec 11 11:26:03 2013 From: lholmqui at redhat.com (Lucas Holmquist) Date: Wed, 11 Dec 2013 11:26:03 -0500 Subject: [aerogear-dev] how about this API for sync? In-Reply-To: <3DC41C42-65FD-4A0F-8448-CA6EF537A89C@gmail.com> References: <52A20665.8080800@redhat.com> <44873EDC-1C3D-4F7D-ACC2-29B155F25D65@redhat.com> <52A5C532.9040908@redhat.com> <7C6E47FF-0BFB-4183-9A91-A6E3D18F520B@redhat.com> <52A5EA97.8080003@redhat.com> <52A72FAD.5080601@redhat.com> <52A75632.1040406@redhat.com> <1386775333.1866.21.camel@dhcp129-205.brq.redhat.com> <1386775615.1866.23.camel@dhcp129-205.brq.redhat.com> <3DC41C42-65FD-4A0F-8448-CA6EF537A89C@gmail.com> Message-ID: <8F178B64-BEDD-470F-B363-EF18A57D5C36@redhat.com> So i know with PouchDB, they do long polling when the "continuous" option is on. they sync against couchDB On Dec 11, 2013, at 11:24 AM, Corinne Krych wrote: > Interesting link to understand 'a la couchDB': > http://docs.couchbase.com/couchbase-lite/cbl-concepts/#introduction > > that comes will iOS/Android client implementation. > > ++ > Corinne > On Dec 11, 2013, at 5:13 PM, Sebastien Blanc wrote: > >> >> >> >> On Wed, Dec 11, 2013 at 4:33 PM, Lucas Holmquist wrote: >> wanted to dump some thoughts i was having >> Client Side Perspective >> >> let me try to dump some of the client side thoughts i have, which will probably be more javascript centric >> >> ? i see data sync as keeping DataManager stores in sync with the server side >> >> ? not sure if it makes sense without it? >> >> ? I can see using Notifier using sockJS connecting to a netty server(?) to do the "real-time" updates >> >> ? Sync should be plugable, so an existing REST application using DataManager can just add it in or turn it off easily >> >> ? the sync should have some events that the user can "listen" for, to deal with conflict/changes and such >> >> ? there is another type of sync that i'm also thinking off. >> >> Since Pipeline and Datamanager are not tied to each other, do we want to think about the possiblity of "syncing" them. that is when i do a read currently on a pipe, i have to manually store the data, should that be automatic, this used to happen in the way begining of pipeline, but we removed it since we wanted to keep it modular >> >> Yes, I think that makes totally sense. If you it should be automatic, well, we could configure it to be or not. In the same spirit, I was thinking of some kind of storeFallback option we can pass to a pipe. If we call a read on a pipe and there is no connection, we fallback automatically on the local store to retrieve the data (with some metadata/flag saying it's local data). >> >> >> On Dec 11, 2013, at 10:26 AM, Apostolos Emmanouilidis wrote: >> >>> apologies, just a correction. The security concern is that the database >>> might contain data which should be NOT visible/accessible to all the >>> clients. >>> >>> On Wed, 2013-12-11 at 16:22 +0100, Apostolos Emmanouilidis wrote: >>>> +1 for starting with an implementation similar to CouchDB. This looks >>>> like the Offline Lock pattern where there are version stamps and a >>>> client cannot fulfill a transaction if he has an old current version >>>> stamp. >>>> >>>> Regarding the concepts that Summers sent >>>> https://neil.fraser.name/writing/sync/ I feel that are some Open Source >>>> implementations of these concepts out there. >>>> e.g google-diff-match-patch[1] >>>> >>>> And something more, there is a security parameter in the data sync >>>> concept. The database might contain data which should be >>>> visible/accessible to all the clients. >>>> >>>> [1]: https://code.google.com/p/google-diff-match-patch/ >>>> >>>> >>>> On Wed, 2013-12-11 at 10:37 +0100, Daniel Bevenius wrote: >>>> >>>> >>>>> This conflict would the have to be handled by the client. Could we >>>>> start out with something similar and as simple as this and evolve it? >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 From bruno at abstractj.org Thu Dec 12 00:49:10 2013 From: bruno at abstractj.org (Bruno Oliveira) Date: Thu, 12 Dec 2013 03:49:10 -0200 Subject: [aerogear-dev] Password reset 0.1.0 Message-ID: Good morning my friends, I think I finally found a happy path to the password reset workflow. To eat my own dog food, I wrote the whole interaction with AGJS (thanks a lot Luke for your patience).? Details about the project: url:?https://github.com/abstractj/password-reset/ tag: 0.1.0 Dependencies: The following PR must be locally installed https://github.com/aerogear/aerogear-crypto-java/pull/14 The package ?api? is what I would suggest to move to another project like ag-security for example and the other packages are mostly up to the implementer.? Configuration files: - The project has 2 configuration files web.xml:? ? ? ? ? ? ? url ? ? ? ? ? ? http://localhost:8080/password-reset/ ? ? ? ? ? ? ? ? ? ? ? ? ? ? redirect-page ? ? ? ? ? ? /reset/update.html ? ? ? ? The ?url? parameter is used by the project to provide the urls like:?http://localhost:8080/password-reset/reset?id=CMZXGXLg%2Fw7nCBrlmEB%2BO6iDMHzxNSf8cD5idyDxS8U%3D and ?redirect-page? is the page to be redirected when the correct token id is provided. config.properties: secret_key = "d9eb5171c59a4c817f68b0de27b8c1e340c2341b52cdbc60d3083d4e8958532" \ ? ? ? ? ? ? ? ??18dcc5f589cafde048faec956b61f864b9b5513ff9ce29bf9e5d58b0f234f8e3b" ?secret_key? will be the passphrase used by PBKDF2 to HMAC a new token and can?t be shared. How to test it? - git clone https://github.com/abstractj/password-reset/ && cd password-reset && mvn clean package? Scenarios for testing: - Workflow I 1. Open?http://localhost:8080/password-reset/ at your browser 2. Input whatever e-mail and click on reset 3. At your console an URL will be printed at your logs. For example: http://localhost:8080/password-reset/reset?id=CMZXGXLg%2Fw7nCBrlmEB%2BO6iDMHzxNSf8cD5idyDxS8U%3D 4. Copy & paste it into your browser 5. If everything went well, you will probably see the update page. Input the e-mail, new password and the confirmation 6. Now try to send a request to the same URL and you will get a 404 (This is intentional, because the token was used & destroyed) - Workflow II 1. Try to request the update.html page 2. You should get a 404 because you?re not allowed to do it without a valid token - Workflow III 1. Try to request?http://localhost:8080/password-reset/reset/?id=?Some random or repeated id here? 2. You should get a 404 because you?re not allowed to do it without a valid token - Workflow IV 1. Change the value of?https://github.com/abstractj/password-reset/blob/master/src/main/java/org/abstractj/model/Token.java#L22 to -10 for example. 2. Input whatever e-mail and click on reset 3. At your console an URL will be printed at your logs. For example: http://localhost:8080/password-reset/reset?id=CMZXGXLg%2Fw7nCBrlmEB%2BO6iDMHzxNSf8cD5idyDxS8U%3D 4. Copy & paste it into your browser 5. You should get a 404 because this token has already expired. Open questions - The usability is easy, tricky..the configuration files are too much? - Where the package ?api? should be added? ag-security? nowhere? - Is the workflow ok for you? Thoughts, suggestions? -- abstractj From aemmanou at redhat.com Thu Dec 12 04:59:06 2013 From: aemmanou at redhat.com (Apostolos Emmanouilidis) Date: Thu, 12 Dec 2013 10:59:06 +0100 Subject: [aerogear-dev] Password reset 0.1.0 In-Reply-To: References: Message-ID: <1386842346.2432.8.camel@dhcp129-205.brq.redhat.com> Good morning Bruno, The required configuration seems reasonable and the workflow is as discussed in a previous thread. Does it make sense to validate that the passed value is e-mail address (maybe by using Apache Commons EmailValidator) before passing it to the service? btw I had to catch an InvalidKeySpecException inside TokenServiceImpl class in order to compile the password-reset. On Thu, 2013-12-12 at 03:49 -0200, Bruno Oliveira wrote: > Open questions > > - The usability is easy, tricky..the configuration files are too much? > - Where the package ?api? should be added? ag-security? nowhere? > - Is the workflow ok for you? > > Thoughts, suggestions? From scm.blanc at gmail.com Thu Dec 12 05:01:44 2013 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Thu, 12 Dec 2013 11:01:44 +0100 Subject: [aerogear-dev] Password reset 0.1.0 In-Reply-To: <1386842346.2432.8.camel@dhcp129-205.brq.redhat.com> References: <1386842346.2432.8.camel@dhcp129-205.brq.redhat.com> Message-ID: On Thu, Dec 12, 2013 at 10:59 AM, Apostolos Emmanouilidis < aemmanou at redhat.com> wrote: > Good morning Bruno, > > The required configuration seems reasonable and the workflow is as > discussed in a previous thread. > > Does it make sense to validate that the passed value is e-mail address > (maybe by using Apache Commons EmailValidator) before passing it to the > service? > > btw I had to catch an InvalidKeySpecException inside TokenServiceImpl > class in order to compile the password-reset. > I had this issue also with Master but building tag 0.1.0 did not give me this exception. > > On Thu, 2013-12-12 at 03:49 -0200, Bruno Oliveira wrote: > > Open questions > > > > - The usability is easy, tricky..the configuration files are too much? > > - Where the package ?api? should be added? ag-security? nowhere? > > - Is the workflow ok for you? > > > > Thoughts, suggestions? > > _______________________________________________ > 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/20131212/23074936/attachment.html From scm.blanc at gmail.com Thu Dec 12 05:35:18 2013 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Thu, 12 Dec 2013 11:35:18 +0100 Subject: [aerogear-dev] Password reset 0.1.0 In-Reply-To: References: Message-ID: On Thu, Dec 12, 2013 at 6:49 AM, Bruno Oliveira wrote: > Good morning my friends, I think I finally found a happy path to the > password reset workflow. To eat my own dog food, I wrote the whole > interaction with AGJS (thanks a lot Luke for your patience). > > Details about the project: > > url: https://github.com/abstractj/password-reset/ > tag: 0.1.0 > Dependencies: The following PR must be locally installed > https://github.com/aerogear/aerogear-crypto-java/pull/14 > > The package ?api? is what I would suggest to move to another project like > ag-security for example and the other packages are mostly up to the > implementer. > > Configuration files: > > - The project has 2 configuration files > > web.xml: > > > url > http://localhost:8080/password-reset/ > > > > redirect-page > /reset/update.html > > > The ?url? parameter is used by the project to provide the urls like: > http://localhost:8080/password-reset/reset?id=CMZXGXLg%2Fw7nCBrlmEB%2BO6iDMHzxNSf8cD5idyDxS8U%3Dand ?redirect-page? is the page to be redirected when the correct token id > is provided. > > config.properties: > > secret_key = > "d9eb5171c59a4c817f68b0de27b8c1e340c2341b52cdbc60d3083d4e8958532" \ > > ?18dcc5f589cafde048faec956b61f864b9b5513ff9ce29bf9e5d58b0f234f8e3b" > > ?secret_key? will be the passphrase used by PBKDF2 to HMAC a new token and > can?t be shared. > > How to test it? > > - git clone https://github.com/abstractj/password-reset/ && cd > password-reset && mvn clean package > > Scenarios for testing: > > - Workflow I > > 1. Open http://localhost:8080/password-reset/ at your browser > 2. Input whatever e-mail and click on reset > 3. At your console an URL will be printed at your logs. For example: > http://localhost:8080/password-reset/reset?id=CMZXGXLg%2Fw7nCBrlmEB%2BO6iDMHzxNSf8cD5idyDxS8U%3D > 4. Copy & paste it into your browser > 5. If everything went well, you will probably see the update page. Input > the e-mail, new password and the confirmation > 6. Now try to send a request to the same URL and you will get a 404 (This > is intentional, because the token was used & destroyed) > > - Workflow II > > 1. Try to request the update.html page > 2. You should get a 404 because you?re not allowed to do it without a > valid token > > - Workflow III > 1. Try to request http://localhost:8080/password-reset/reset/?id=?Some > random or repeated id here? > 2. You should get a 404 because you?re not allowed to do it without a > valid token > > - Workflow IV > 1. Change the value of > https://github.com/abstractj/password-reset/blob/master/src/main/java/org/abstractj/model/Token.java#L22to -10 for example. > 2. Input whatever e-mail and click on reset > 3. At your console an URL will be printed at your logs. For example: > http://localhost:8080/password-reset/reset?id=CMZXGXLg%2Fw7nCBrlmEB%2BO6iDMHzxNSf8cD5idyDxS8U%3D > 4. Copy & paste it into your browser > 5. You should get a 404 because this token has already expired. > > Open questions > > - The usability is easy, tricky..the configuration files are too much? > Seems reasonable > - Where the package ?api? should be added? ag-security? nowhere? > Make sense to add this to ag-security IMO > - Is the workflow ok for you? > The reset flow is clear and I was able to play with your project. Now, I have to think how to adapt this for UPS concerning the creation of the user, some question : - I would like the new created user to be "blocked/inactive" until he hasn't clicked the generated link, seems this approach okay ? And what is the correct way of doing this : assign a default password and set the credential as expired ? - Can I store the tokens just as in your sample (JPA/Model flow) or opens that a big security hole ? - Is there a way to have a relation between the token and the email (or whatever other unique identifier for the user) so that when the user clicks the link the backend already knows which users it concerns and just handle the password reset ? Or is that something that we don't want and the user will always have to enter his email when resetting ? > Thoughts, suggestions? > Good job ! > > > > > -- > 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/20131212/412865ca/attachment-0001.html From bruno at abstractj.org Thu Dec 12 06:24:58 2013 From: bruno at abstractj.org (Bruno Oliveira) Date: Thu, 12 Dec 2013 09:24:58 -0200 Subject: [aerogear-dev] Password reset 0.1.0 In-Reply-To: References: Message-ID: Hi my friend, build the project targeting the tag 0.1.0 like Sebastien mentioned. Regarding the e-mail validation, I can be wrong, but I think this is up to the implementer. For example if you look at?https://github.com/abstractj/password-reset/blob/master/src/main/java/org/abstractj/fixture/FakeService.java#L5 that would be some service created by the developer, as well the service for check if that e-mail provided is was provided https://github.com/abstractj/password-reset/blob/master/src/main/java/org/abstractj/service/TokenServiceImpl.java#L62. The goal of the TokenService interface is to enable developers to implement it with whatever storage they want. But of course, I?m open for suggestions.? -- abstractj On December 12, 2013 at 8:35:26 AM, Sebastien Blanc (scm.blanc at gmail.com) wrote: > > Good morning Bruno, > > The required configuration seems reasonable and the workflow > is as > discussed in a previous thread. > > Does it make sense to validate that the passed value is e-mail > address > (maybe by using Apache Commons EmailValidator) before passing > it to the > service? > > btw I had to catch an InvalidKeySpecException inside TokenServiceImpl > class in order to compile the password-reset. From bruno at abstractj.org Thu Dec 12 06:56:40 2013 From: bruno at abstractj.org (Bruno Oliveira) Date: Thu, 12 Dec 2013 09:56:40 -0200 Subject: [aerogear-dev] Password reset 0.1.0 In-Reply-To: References: Message-ID: There we go answers inline. -- abstractj On December 12, 2013 at 8:35:26 AM, Sebastien Blanc (scm.blanc at gmail.com) wrote: > > The reset flow is clear and I was able to play with your project. > Now, I have to think how to adapt this for UPS concerning the creation > of the user, some question : To adapt on UPS will be necessary to: - Implement the TokenService interface - Implement the endpoints like I did into that demo - Replace the FakeService by something real - Insert the configuration files I can help with it > > - I would like the new created user to be "blocked/inactive" until > he hasn't clicked the generated link, seems this approach okay > ?? tbh I don?t think you should have inactive users into your database because is too risky, you should have something similar to the table ?Token? to be send to the user. And what is the correct way of doing this : assign a default password > and set the credential as expired ? Have inactive users with default passwords is a bad idea, imo the correct workflow would be: - Generate something pretty similar to the reset url during the first registration - Send this url to our user (with the token having an expiration time) - User access that url and has permissions to update the password? Here is the problem when you generate an user into your database without any confirmation if they truly exists: - Is possible to generate fake users If only the admin is allowed to create/register users, I would suggest to generate the user with empty password and NEVER allow that user to login with empty passwords (not sure if it was clear but let me know) > > - Can I store the tokens just as in your sample (JPA/Model flow) > or opens that a big security hole ? You can store just like that, once the expiration time is validated and the token is destroyed I?m not sure about what do you mean about open a security hole. For example an attacker could hack the database and steal the reset tokens, but only if the time didn?t expired otherwise won?t happen, because the want?s to find out the ?secret? to generate those tokens and try to break something generated with salt + iterations with PBKDF2. Into other words is not impossible, but really hard. Another security hole would exist if the implementer incorrectly validate that token into the database. > > - Is there a way to have a relation between the token and the email > (or whatever other unique identifier for the user) so that when > the user clicks the link the backend already knows which users > it concerns and just handle the password reset ? Or is that something > that we don't want and the user will always have to enter his email > when resetting ? Into the way like it was written is possible but not recommended and lemme explain why (call me paranoid).? Scenario 1:? If an attacker hack the database and face with a table with a bunch of tokens but no relationship with other tables, will be hard to figure out which token belongs to an specific user and basically will be necessary to guess which token belongs to an specific e-mail. Scenario 2:? If we add a relationship between a table like ?Token? and for example ?User?, the attacker don?t need to guess anymore, is just a matter of check which token belongs to ?john at doe.com? for example. As I mentioned, is up to the implementer but for paranoids, risky. Let me know if something doesn?t make sense. From bruno at abstractj.org Thu Dec 12 08:18:17 2013 From: bruno at abstractj.org (Bruno Oliveira) Date: Thu, 12 Dec 2013 11:18:17 -0200 Subject: [aerogear-dev] Hybrid Cordova Tooling In-Reply-To: <994985BF-D5A6-481C-B858-10E03A096766@redhat.com> References: <994985BF-D5A6-481C-B858-10E03A096766@redhat.com> Message-ID: Nice! Thanks for sharing. -- abstractj On December 11, 2013 at 1:14:04 AM, Burr Sutter (bsutter at redhat.com) wrote: > > Camtasia gave me fits trying to get this recorded. > > https://vimeo.com/81565404 > > In JBDS 7.1 > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From scm.blanc at gmail.com Thu Dec 12 08:20:54 2013 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Thu, 12 Dec 2013 14:20:54 +0100 Subject: [aerogear-dev] Hybrid Cordova Tooling In-Reply-To: References: <994985BF-D5A6-481C-B858-10E03A096766@redhat.com> Message-ID: Really cool ! Can't wait for the version using the AG Pipes ;) btw, is the resulting app code somewhere on github ? On Thu, Dec 12, 2013 at 2:18 PM, Bruno Oliveira wrote: > Nice! Thanks for sharing. > > -- > abstractj > > On December 11, 2013 at 1:14:04 AM, Burr Sutter (bsutter at redhat.com) > wrote: > > > > Camtasia gave me fits trying to get this recorded. > > > > https://vimeo.com/81565404 > > > > In JBDS 7.1 > > > > > > _______________________________________________ > > 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/20131212/f264464a/attachment.html From bsutter at redhat.com Thu Dec 12 08:45:04 2013 From: bsutter at redhat.com (Burr Sutter) Date: Thu, 12 Dec 2013 08:45:04 -0500 Subject: [aerogear-dev] Hybrid Cordova Tooling In-Reply-To: References: <994985BF-D5A6-481C-B858-10E03A096766@redhat.com> Message-ID: <10F3C411-69C3-4F26-B10D-0E8155B92AF7@redhat.com> The machine that demo was recorded on died :-( so I recreated the project, basically following my own video on another machine. And now pushed it up to github https://github.com/burrsutter/contacts If you have any feedback on my JS, please send it. Future recordings needed: 1) Show off iOS Simulator & export to XCode & deploy to iPhone on a Mac 2) Revisit my Forge video, https://vimeo.com/70822309 and see how to "peel" the UI off and put it in a Cordova project 3) Add in Aerogear.js Pipes for CRUD ops 4) Attempt to get Aerogear Push working in the context of Hybrid/Cordova Tooling In no particular order, just when I can get to them I still need to craft an overall Aerogear evangelism slide deck for use at global JBugs, where these videos can also help the presenter (he/she can just run the video). On Dec 12, 2013, at 8:20 AM, Sebastien Blanc wrote: > Really cool ! Can't wait for the version using the AG Pipes ;) > btw, is the resulting app code somewhere on github ? > > > > On Thu, Dec 12, 2013 at 2:18 PM, Bruno Oliveira wrote: > Nice! Thanks for sharing. > > -- > abstractj > > On December 11, 2013 at 1:14:04 AM, Burr Sutter (bsutter at redhat.com) wrote: > > > > Camtasia gave me fits trying to get this recorded. > > > > https://vimeo.com/81565404 > > > > In JBDS 7.1 > > > > > > _______________________________________________ > > 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/20131212/d05458a9/attachment.html From lholmqui at redhat.com Thu Dec 12 09:22:15 2013 From: lholmqui at redhat.com (Lucas Holmquist) Date: Thu, 12 Dec 2013 09:22:15 -0500 Subject: [aerogear-dev] Hybrid Cordova Tooling In-Reply-To: <10F3C411-69C3-4F26-B10D-0E8155B92AF7@redhat.com> References: <994985BF-D5A6-481C-B858-10E03A096766@redhat.com> <10F3C411-69C3-4F26-B10D-0E8155B92AF7@redhat.com> Message-ID: <5536CDF1-F9B5-421A-A7F3-F159EA7311F4@redhat.com> On Dec 12, 2013, at 8:45 AM, Burr Sutter wrote: > The machine that demo was recorded on died :-( so I recreated the project, basically following my own video on another machine. And now pushed it up to github > https://github.com/burrsutter/contacts > > If you have any feedback on my JS, please send it. on this line https://github.com/burrsutter/contacts/blob/master/www/js/index.js#L18 it would probably be better to set $("deviceContacts") to a variable, then do operations on it, so you are only searching the DOM for it once same with https://github.com/burrsutter/contacts/blob/master/www/js/index.js#L38 > > Future recordings needed: > 1) Show off iOS Simulator & export to XCode & deploy to iPhone on a Mac > 2) Revisit my Forge video, https://vimeo.com/70822309 and see how to "peel" the UI off and put it in a Cordova project > 3) Add in Aerogear.js Pipes for CRUD ops > 4) Attempt to get Aerogear Push working in the context of Hybrid/Cordova Tooling > > In no particular order, just when I can get to them > > I still need to craft an overall Aerogear evangelism slide deck for use at global JBugs, where these videos can also help the presenter (he/she can just run the video). > > > On Dec 12, 2013, at 8:20 AM, Sebastien Blanc wrote: > >> Really cool ! Can't wait for the version using the AG Pipes ;) >> btw, is the resulting app code somewhere on github ? >> >> >> >> On Thu, Dec 12, 2013 at 2:18 PM, Bruno Oliveira wrote: >> Nice! Thanks for sharing. >> >> -- >> abstractj >> >> On December 11, 2013 at 1:14:04 AM, Burr Sutter (bsutter at redhat.com) wrote: >> > >> > Camtasia gave me fits trying to get this recorded. >> > >> > https://vimeo.com/81565404 >> > >> > In JBDS 7.1 >> > >> > >> > _______________________________________________ >> > 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/20131212/8a4e44ea/attachment-0001.html From bsutter at redhat.com Thu Dec 12 10:06:20 2013 From: bsutter at redhat.com (Burr Sutter) Date: Thu, 12 Dec 2013 10:06:20 -0500 Subject: [aerogear-dev] Hybrid Cordova Tooling In-Reply-To: <5536CDF1-F9B5-421A-A7F3-F159EA7311F4@redhat.com> References: <994985BF-D5A6-481C-B858-10E03A096766@redhat.com> <10F3C411-69C3-4F26-B10D-0E8155B92AF7@redhat.com> <5536CDF1-F9B5-421A-A7F3-F159EA7311F4@redhat.com> Message-ID: That is a great tip and it would not have occurred to me, thank you. On Dec 12, 2013, at 9:22 AM, Lucas Holmquist wrote: > > On Dec 12, 2013, at 8:45 AM, Burr Sutter wrote: > >> The machine that demo was recorded on died :-( so I recreated the project, basically following my own video on another machine. And now pushed it up to github >> https://github.com/burrsutter/contacts >> >> If you have any feedback on my JS, please send it. > on this line https://github.com/burrsutter/contacts/blob/master/www/js/index.js#L18 > > it would probably be better to set $("deviceContacts") to a variable, then do operations on it, so you are only searching the DOM for it once > > same with https://github.com/burrsutter/contacts/blob/master/www/js/index.js#L38 > >> >> Future recordings needed: >> 1) Show off iOS Simulator & export to XCode & deploy to iPhone on a Mac >> 2) Revisit my Forge video, https://vimeo.com/70822309 and see how to "peel" the UI off and put it in a Cordova project >> 3) Add in Aerogear.js Pipes for CRUD ops >> 4) Attempt to get Aerogear Push working in the context of Hybrid/Cordova Tooling >> >> In no particular order, just when I can get to them >> >> I still need to craft an overall Aerogear evangelism slide deck for use at global JBugs, where these videos can also help the presenter (he/she can just run the video). >> >> >> On Dec 12, 2013, at 8:20 AM, Sebastien Blanc wrote: >> >>> Really cool ! Can't wait for the version using the AG Pipes ;) >>> btw, is the resulting app code somewhere on github ? >>> >>> >>> >>> On Thu, Dec 12, 2013 at 2:18 PM, Bruno Oliveira wrote: >>> Nice! Thanks for sharing. >>> >>> -- >>> abstractj >>> >>> On December 11, 2013 at 1:14:04 AM, Burr Sutter (bsutter at redhat.com) wrote: >>> > >>> > Camtasia gave me fits trying to get this recorded. >>> > >>> > https://vimeo.com/81565404 >>> > >>> > In JBDS 7.1 >>> > >>> > >>> > _______________________________________________ >>> > 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/20131212/937db172/attachment.html From daniel at passos.me Fri Dec 13 09:33:52 2013 From: daniel at passos.me (Daniel Passos) Date: Fri, 13 Dec 2013 12:33:52 -0200 Subject: [aerogear-dev] AeroGear Android Root Document In-Reply-To: <19FA4209-6688-43C5-9153-757EE34E9F4A@gmail.com> References: <19FA4209-6688-43C5-9153-757EE34E9F4A@gmail.com> Message-ID: On Tue, Dec 10, 2013 at 6:00 AM, Corinne Krych wrote: Hello Daniel > > I really buy into your idea. > We definitively need more consistent documentation on AeroGear features > with concrete and simple exemple (like we started in cookbook). > The idea is clean up our documentation, write a UNIQUE document explaining how to build our lib and apps. Looks like ActionBarSherlock - Prereq - Build - Usage In all README we will link for this document (on ag.org) and add specific things for the app Let's refactor our documentation together and meake suure we go in the same > direction. > See Hylke thread on it [1]. As suggested by Hylke, let's group our > documentation per category/features: core, push, security, offline/sync. We > could have a general description of what the features is, some link to > specs etc.. > +1 for reorganize this Then the sample part. Each sample/recipe(from cookbook) should be well > documented and follow a similar template like you gist shown it. I've done > similar with iOS-cookbook. One central readme [1] which list all recipes. > Each recipes [2] has is own documentation following the same template. We > ca work on unifying the template. I like prerequisites section, > install/build section common to both, you miss a short description of the > app and some ui flow with pictures would be nice and then a last sec ion we > we explain the main fatures we want ot demo. > The root document is not to explain how to use our features. It?s for explain how to build our libs and apps. We don?t have one central README and other specific for cookbook looks like iOS, because for Android we have only one cookbook app. This application has all our features. For each feature we have one activity (screen). This makes the explanation very simple and focus on this feature. Each activity (screens) explain one feature and each feature has a usage guide on the ag.org ( http://aerogear.org/docs/guides/aerogear-android/)) A couple of questions on implementation though: > - Instead of just having links to cookbook, how can we embed in asciidoc > or markdown? the sample documentation should belong to the cookbook repo. > - How are we going to publish read me info from cookbook into aerogear.orgrepo? a build or some sort of automation will be good. > I think those questions have been answered above. > ++ > Corinne > [1] > http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Website-restructure-td5246.html > [1] > https://github.com/corinnekrych/aerogear-ios-cookbook/blob/master/README.md > [2] > https://github.com/corinnekrych/aerogear-ios-cookbook/blob/master/Xmas/Xmas.md > > On Dec 9, 2013, at 11:20 PM, Daniel Passos wrote: > > > Summers and I tossed around the idea last week to create a 'root > document' how to build AeroGear android lib and apps. > > > > The idea is write a simple document that looks like ActionBar Sherlock > doc instead of having a huge doc with lots of repeated setup, have a setup > docs which branch from there > > > > Publish it on aerogear.org and link all others (like README) with it > > > > My draft for it is here: > https://gist.github.com/danielpassos/4b4e694c1c71473b4f59 > > > > wdyt? > > > > -- Daniel Passos > > > > _______________________________________________ > > 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/20131213/bafed83f/attachment.html From daniel at passos.me Fri Dec 13 10:05:09 2013 From: daniel at passos.me (Daniel Passos) Date: Fri, 13 Dec 2013 13:05:09 -0200 Subject: [aerogear-dev] AeroGear Android Root Document In-Reply-To: References: <19FA4209-6688-43C5-9153-757EE34E9F4A@gmail.com> Message-ID: Well, That is what we have today and what we want to follow <#>Android Documentations <#> Root document A documentation explain how to build lib and app <#>README A link for root document and add specific things for conf/run app <#>Usage Guide For each feature we have a document explaining how to use it on the site. We don?t add any explanation of how to use a feature in the README <#>Cookbook We have only one app to show for community see how to our feature works. We have one activity per usage guide <#> Feature table I love corinne idea for put table feature on README but I like to move it for ag lib instead cookbook On Fri, Dec 13, 2013 at 12:33 PM, Daniel Passos wrote: > On Tue, Dec 10, 2013 at 6:00 AM, Corinne Krych > wrote: > > Hello Daniel >> >> I really buy into your idea. >> We definitively need more consistent documentation on AeroGear features >> with concrete and simple exemple (like we started in cookbook). >> > The idea is clean up our documentation, write a UNIQUE document explaining > how to build our lib and apps. Looks like ActionBarSherlock > > - Prereq > - Build > - Usage > > In all README we will link for this document (on ag.org) and add specific > things for the app > > Let's refactor our documentation together and meake suure we go in the >> same direction. >> See Hylke thread on it [1]. As suggested by Hylke, let's group our >> documentation per category/features: core, push, security, offline/sync. We >> could have a general description of what the features is, some link to >> specs etc.. >> > +1 for reorganize this > > Then the sample part. Each sample/recipe(from cookbook) should be well >> documented and follow a similar template like you gist shown it. I've done >> similar with iOS-cookbook. One central readme [1] which list all recipes. >> Each recipes [2] has is own documentation following the same template. We >> ca work on unifying the template. I like prerequisites section, >> install/build section common to both, you miss a short description of the >> app and some ui flow with pictures would be nice and then a last sec ion we >> we explain the main fatures we want ot demo. >> > The root document is not to explain how to use our features. It?s for > explain how to build our libs and apps. > > We don?t have one central README and other specific for cookbook looks > like iOS, because for Android we have only one cookbook app. This > application has all our features. For each feature we have one activity > (screen). This makes the explanation very simple and focus on this feature. > Each activity (screens) explain one feature and each feature has a usage > guide on the ag.org ( > http://aerogear.org/docs/guides/aerogear-android/)) > > A couple of questions on implementation though: >> - Instead of just having links to cookbook, how can we embed in asciidoc >> or markdown? the sample documentation should belong to the cookbook repo. >> - How are we going to publish read me info from cookbook into >> aerogear.org repo? a build or some sort of automation will be good. >> > I think those questions have been answered above. > >> ++ >> Corinne >> [1] >> http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Website-restructure-td5246.html >> [1] >> https://github.com/corinnekrych/aerogear-ios-cookbook/blob/master/README.md >> [2] >> https://github.com/corinnekrych/aerogear-ios-cookbook/blob/master/Xmas/Xmas.md >> >> On Dec 9, 2013, at 11:20 PM, Daniel Passos wrote: >> >> > Summers and I tossed around the idea last week to create a 'root >> document' how to build AeroGear android lib and apps. >> > >> > The idea is write a simple document that looks like ActionBar Sherlock >> doc instead of having a huge doc with lots of repeated setup, have a setup >> docs which branch from there >> > >> > Publish it on aerogear.org and link all others (like README) with it >> > >> > My draft for it is here: >> https://gist.github.com/danielpassos/4b4e694c1c71473b4f59 >> > >> > wdyt? >> > >> > -- Daniel Passos >> > >> > _______________________________________________ >> > 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/20131213/4a93e0e9/attachment-0001.html From corinnekrych at gmail.com Fri Dec 13 10:40:37 2013 From: corinnekrych at gmail.com (Corinne Krych) Date: Fri, 13 Dec 2013 16:40:37 +0100 Subject: [aerogear-dev] AeroGear Android Root Document In-Reply-To: References: <19FA4209-6688-43C5-9153-757EE34E9F4A@gmail.com> Message-ID: <6B6E85E9-60D5-49C2-BC64-E5E41CB2A8E1@gmail.com> On Dec 13, 2013, at 4:05 PM, Daniel Passos wrote: > Well, That is what we have today and what we want to follow > > Android Documentations > > Root document > > A documentation explain how to build lib and app > > README > > A link for root document and add specific things for conf/run app > > Usage Guide > > For each feature we have a document explaining how to use it on the site. We don?t add any explanation of how to use a feature in the README > > Cookbook > > We have only one app to show for community see how to our feature works. We have one activity per usage guide Because of the nature of iOS app, we use storyboard (no UI code) so we can concentrate on AG app code. We add a bit of fun by defining 'fun' app. I think we don't have to stick exactly to the same for the recipes. Both ways are fine, one single objective: demo AG code, straight to the point. > > Feature table > > I love corinne idea for put table feature on README but I like to move it for ag lib instead cookbook Agreed We could move this table in web site documetation and add a link on cookbook readme to it. https://issues.jboss.org/browse/AGIOS-141 Once you've completed your Android documentation, we can start iOS one and stick close to yours for the template. > > > > On Fri, Dec 13, 2013 at 12:33 PM, Daniel Passos wrote: > On Tue, Dec 10, 2013 at 6:00 AM, Corinne Krych wrote: > > > > Hello Daniel > > I really buy into your idea. > We definitively need more consistent documentation on AeroGear features with concrete and simple exemple (like we started in cookbook). > > > The idea is clean up our documentation, write a UNIQUE document explaining how to build our lib and apps. Looks like ActionBarSherlock > > ? Prereq > ? Build > ? Usage > In all README we will link for this document (on ag.org) and add specific things for the app > > > > Let's refactor our documentation together and meake suure we go in the same direction. > See Hylke thread on it [1]. As suggested by Hylke, let's group our documentation per category/features: core, push, security, offline/sync. We could have a general description of what the features is, some link to specs etc.. > > > +1 for reorganize this > > > > Then the sample part. Each sample/recipe(from cookbook) should be well documented and follow a similar template like you gist shown it. I've done similar with iOS-cookbook. One central readme [1] which list all recipes. Each recipes [2] has is own documentation following the same template. We ca work on unifying the template. I like prerequisites section, install/build section common to both, you miss a short description of the app and some ui flow with pictures would be nice and then a last sec ion we we explain the main fatures we want ot demo. > > > The root document is not to explain how to use our features. It?s for explain how to build our libs and apps. > > We don?t have one central README and other specific for cookbook looks like iOS, because for Android we have only one cookbook app. This application has all our features. For each feature we have one activity (screen). This makes the explanation very simple and focus on this feature. Each activity (screens) explain one feature and each feature has a usage guide on the ag.org (http://aerogear.org/docs/guides/aerogear-android/)) > > > > A couple of questions on implementation though: > - Instead of just having links to cookbook, how can we embed in asciidoc or markdown? the sample documentation should belong to the cookbook repo. > - How are we going to publish read me info from cookbook into aerogear.org repo? a build or some sort of automation will be good. > > > I think those questions have been answered above. > > ++ > Corinne > [1] http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Website-restructure-td5246.html > [1] https://github.com/corinnekrych/aerogear-ios-cookbook/blob/master/README.md > [2] https://github.com/corinnekrych/aerogear-ios-cookbook/blob/master/Xmas/Xmas.md > > On Dec 9, 2013, at 11:20 PM, Daniel Passos wrote: > > > Summers and I tossed around the idea last week to create a 'root document' how to build AeroGear android lib and apps. > > > > The idea is write a simple document that looks like ActionBar Sherlock doc instead of having a huge doc with lots of repeated setup, have a setup docs which branch from there > > > > Publish it on aerogear.org and link all others (like README) with it > > > > My draft for it is here: https://gist.github.com/danielpassos/4b4e694c1c71473b4f59 > > > > wdyt? > > > > -- Daniel Passos > > > > _______________________________________________ > > 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 bsutter at redhat.com Sat Dec 14 12:06:53 2013 From: bsutter at redhat.com (Burr Sutter) Date: Sat, 14 Dec 2013 12:06:53 -0500 Subject: [aerogear-dev] Aerogear.js for CRUD Message-ID: I am having a problem with pipe.save(), likely user error :-) For some reason, the POST is occurring, the save seems to work but the error callback is invoked, not the success method. And I am doing all of this in the context of our tooling which has some limitations (auto-closing console/firebug lite) http://screencast.com/t/gosd7Qnhz REST endpoint: http://agmobile-html5.rhcloud.com/rest/forge/members Use of Forge, with the Member.java entity to offer full CRUD capabilities Sources: https://github.com/burrsutter/AGContacts/blob/master/www/js/index.js -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20131214/d23f1e3e/attachment.html From daniel.bevenius at gmail.com Mon Dec 16 03:01:37 2013 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Mon, 16 Dec 2013 09:01:37 +0100 Subject: [aerogear-dev] Team Meeting Message-ID: Agenda: http://oksoclap.com/p/aerogear-team-mgt-20131216 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20131216/d14fba62/attachment.html From aemmanou at redhat.com Mon Dec 16 03:56:31 2013 From: aemmanou at redhat.com (Apostolos Emmanouilidis) Date: Mon, 16 Dec 2013 09:56:31 +0100 Subject: [aerogear-dev] Aerogear.js for CRUD In-Reply-To: References: Message-ID: <1387184191.10538.3.camel@dhcp129-205.brq.redhat.com> My sense is that you're trying to perform a CORS request and probably your REST service is not configured to support CORS. Here is an example to configure it [1] [1]: https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/installations/InstallationRegistrationEndpoint.java#L65 On Sat, 2013-12-14 at 12:06 -0500, Burr Sutter wrote: > I am having a problem with pipe.save(), likely user error :-) > > > For some reason, the POST is occurring, the save seems to work but the > error callback is invoked, not the success method. > > > And I am doing all of this in the context of our tooling which has > some limitations (auto-closing console/firebug lite) > > > http://screencast.com/t/gosd7Qnhz > > > REST endpoint: > http://agmobile-html5.rhcloud.com/rest/forge/members > Use of Forge, with the Member.java entity to offer full CRUD > capabilities > > > Sources: > https://github.com/burrsutter/AGContacts/blob/master/www/js/index.js > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From scm.blanc at gmail.com Mon Dec 16 04:11:12 2013 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Mon, 16 Dec 2013 10:11:12 +0100 Subject: [aerogear-dev] Aerogear.js for CRUD In-Reply-To: <1387184191.10538.3.camel@dhcp129-205.brq.redhat.com> References: <1387184191.10538.3.camel@dhcp129-205.brq.redhat.com> Message-ID: On Mon, Dec 16, 2013 at 9:56 AM, Apostolos Emmanouilidis < aemmanou at redhat.com> wrote: > My sense is that you're trying to perform a CORS request and probably > your REST service is not configured to support CORS. > CORS should not be an issue for a hybrid/cordova app and even then, the POST should not even occurs if there was a CORS issue. > > Here is an example to configure it [1] > > [1]: > > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/installations/InstallationRegistrationEndpoint.java#L65 > > > > On Sat, 2013-12-14 at 12:06 -0500, Burr Sutter wrote: > > I am having a problem with pipe.save(), likely user error :-) > > > > > > For some reason, the POST is occurring, the save seems to work but the > > error callback is invoked, not the success method. > > > > > > And I am doing all of this in the context of our tooling which has > > some limitations (auto-closing console/firebug lite) > > > > > > http://screencast.com/t/gosd7Qnhz > > > > > > REST endpoint: > > http://agmobile-html5.rhcloud.com/rest/forge/members > > Use of Forge, with the Member.java entity to offer full CRUD > > capabilities > > > > > > Sources: > > https://github.com/burrsutter/AGContacts/blob/master/www/js/index.js > > > > > > _______________________________________________ > > 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/20131216/8e0c5631/attachment.html From scm.blanc at gmail.com Mon Dec 16 07:01:18 2013 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Mon, 16 Dec 2013 13:01:18 +0100 Subject: [aerogear-dev] Aerogear.js for CRUD In-Reply-To: References: Message-ID: Burr, I've added some logs statements on the client and basically it seems it can not parse the response from the server : I/Web Console( 1386): textStatus: parsererror at file:///android_asset/www/js/index.js:103 I/Web Console( 1386): error: SyntaxError: Unexpected end of input at file:///android_asset/www/js/index.js:104 If I do a CURL like this : curl -v -b cookies.txt -c cookies.txt -H "Accept: application/json" -H "Content-type: application/json" -X POST -d '{"phoneNumber":"1234567890","email":"newTest at test.com","name":"newTest"}' http://agmobile-html5.rhcloud.com/rest/forge/members I got an correct answer but the content type is 'text/plain' , please check your rest endpoint to be sure it's producing json as output, that should solve your issue. Could you also paste the commands you used in Forge to scaffold the REST endpoints so that we can check there hasn't been an incompatibility introduced ? On Sat, Dec 14, 2013 at 6:06 PM, Burr Sutter wrote: > I am having a problem with pipe.save(), likely user error :-) > > For some reason, the POST is occurring, the save seems to work but the > error callback is invoked, not the success method. > > And I am doing all of this in the context of our tooling which has some > limitations (auto-closing console/firebug lite) > > http://screencast.com/t/gosd7Qnhz > > REST endpoint: > http://agmobile-html5.rhcloud.com/rest/forge/members > Use of Forge, with the Member.java entity to offer full CRUD capabilities > > Sources: > https://github.com/burrsutter/AGContacts/blob/master/www/js/index.js > > > _______________________________________________ > 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/20131216/46446742/attachment-0001.html From lholmqui at redhat.com Mon Dec 16 08:23:34 2013 From: lholmqui at redhat.com (Lucas Holmquist) Date: Mon, 16 Dec 2013 08:23:34 -0500 Subject: [aerogear-dev] Aerogear.js for CRUD In-Reply-To: References: Message-ID: <94F4DB17-F6DE-48D0-A810-7EB2E9BA05E9@redhat.com> without even looking, that is what i was thinking the culprit is. On Dec 16, 2013, at 7:01 AM, Sebastien Blanc wrote: > Burr, > I've added some logs statements on the client and basically it seems it can not parse the response from the server : > > I/Web Console( 1386): textStatus: parsererror at file:///android_asset/www/js/index.js:103 > I/Web Console( 1386): error: SyntaxError: Unexpected end of input at file:///android_asset/www/js/index.js:104 > > If I do a CURL like this : > curl -v -b cookies.txt -c cookies.txt -H "Accept: application/json" -H "Content-type: application/json" -X POST -d '{"phoneNumber":"1234567890","email":"newTest at test.com","name":"newTest"}' http://agmobile-html5.rhcloud.com/rest/forge/members > > I got an correct answer but the content type is 'text/plain' , please check your rest endpoint to be sure it's producing json as output, that should solve your issue. > > Could you also paste the commands you used in Forge to scaffold the REST endpoints so that we can check there hasn't been an incompatibility introduced ? > > > > > On Sat, Dec 14, 2013 at 6:06 PM, Burr Sutter wrote: > I am having a problem with pipe.save(), likely user error :-) > > For some reason, the POST is occurring, the save seems to work but the error callback is invoked, not the success method. > > And I am doing all of this in the context of our tooling which has some limitations (auto-closing console/firebug lite) > > http://screencast.com/t/gosd7Qnhz > > REST endpoint: > http://agmobile-html5.rhcloud.com/rest/forge/members > Use of Forge, with the Member.java entity to offer full CRUD capabilities > > Sources: > https://github.com/burrsutter/AGContacts/blob/master/www/js/index.js > > > _______________________________________________ > 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/20131216/ac324a60/attachment.html From supittma at redhat.com Mon Dec 16 08:56:33 2013 From: supittma at redhat.com (Summers Pittman) Date: Mon, 16 Dec 2013 08:56:33 -0500 Subject: [aerogear-dev] Sync ideas with actual code Message-ID: <52AF0691.5080309@redhat.com> Merry Christmas everyone! So last week I mentioned working on a DevNexus app to build out some sync ideas. https://plus.google.com/103442292643366117394/posts/HGVHwtPArPW And the AeroGear code : https://github.com/secondsun/aerogear-android/tree/sync And the docs so far : https://github.com/aerogear/aerogear.org/commit/d4f1f18b951f634c48cc5adf03163609bf51a4ce If you remember the table I posted a while ago, this is showing off the Simple Settings Sync which I have called TwoWaySQLSynchronization (terrible name). Thoughts, comments, questions, etc are all welcome. From scm.blanc at gmail.com Mon Dec 16 09:38:07 2013 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Mon, 16 Dec 2013 15:38:07 +0100 Subject: [aerogear-dev] Fwd: Password reset 0.1.0 In-Reply-To: References: Message-ID: Sorry, just realized I replied only to AbstractJ and not the list. ---------- Forwarded message ---------- From: Sebastien Blanc Date: Fri, Dec 13, 2013 at 6:38 PM Subject: Re: [aerogear-dev] Password reset 0.1.0 To: Bruno Oliveira Hi, A quick update before the weekend starts ;) I started to integrate this into UPS and I also moved some stuff to ag-sec as discussed on this thread. You can play with it here : https://push-sblanc.rhcloud.com/ Steps : 1. Log in with admin/aerogear 2. On the top bar on the right you should see a menu icon (the hamburger-menu icon) , select "Manage Users" 3. Click on "Create" 4. Create a new user by just providing a loginName. A popup will appear, wait until the registration link appears (can be a bit long depending on Open Shift's mood). 5. Copy paste this link in a new tab or browser. 6. You are redirected to a "confirmation" page, fill the info and send. 7. Go back to the first page you opened at step 1, logout, and now tries to login with the new user. It should work. PRs will be send out next week as I need some polish, validation and Role Management but if you want to build it and deploy your self here is the puzzle ;) : - UPS : https://github.com/aerogear/aerogear-unifiedpush-server/tree/register_link - Admin UI : https://github.com/sebastienblanc/aerogear-unified-push-server-admin-ui/tree/user_mngt - Crypto : https://github.com/aerogear/aerogear-crypto-java/pull/14 - AG-SEC : https://github.com/sebastienblanc/aerogear-security/tree/token Thanks again Bruno, On Thu, Dec 12, 2013 at 1:24 PM, Sebastien Blanc wrote: > > > > On Thu, Dec 12, 2013 at 12:56 PM, Bruno Oliveira wrote: > >> There we go answers inline. >> >> -- >> abstractj >> >> On December 12, 2013 at 8:35:26 AM, Sebastien Blanc (scm.blanc at gmail.com) >> wrote: >> > > The reset flow is clear and I was able to play with your project. >> > Now, I have to think how to adapt this for UPS concerning the creation >> > of the user, some question : >> >> To adapt on UPS will be necessary to: >> >> - Implement the TokenService interface >> - Implement the endpoints like I did into that demo >> - Replace the FakeService by something real >> - Insert the configuration files >> >> I can help with it >> > Cool, I should be able to handle most of these, as soon if pushed stuff I > will point it to you so you can help/give feedback > >> >> > >> > - I would like the new created user to be "blocked/inactive" until >> > he hasn't clicked the generated link, seems this approach okay >> > ? >> >> tbh I don?t think you should have inactive users into your database >> because is too risky, you should have something similar to the table >> ?Token? to be send to the user. >> >> And what is the correct way of doing this : assign a default password >> > and set the credential as expired ? >> >> Have inactive users with default passwords is a bad idea, imo the correct >> workflow would be: >> >> - Generate something pretty similar to the reset url during the first >> registration >> - Send this url to our user (with the token having an expiration time) >> - User access that url and has permissions to update the password >> >> Here is the problem when you generate an user into your database without >> any confirmation if they truly exists: >> >> - Is possible to generate fake users >> >> If only the admin is allowed to create/register users, I would suggest to >> generate the user with empty password and NEVER allow that user to login >> with empty passwords (not sure if it was clear but let me know) >> > > Yeah, only admin can create users, this limits the risk of having fake > users, so for the first iteration I will use this approach (empty password > and able to login). > >> >> > >> > - Can I store the tokens just as in your sample (JPA/Model flow) >> > or opens that a big security hole ? >> >> You can store just like that, once the expiration time is validated and >> the token is destroyed I?m not sure about what do you mean about open a >> security hole. For example an attacker could hack the database and steal >> the reset tokens, but only if the time didn?t expired otherwise won?t >> happen, because the want?s to find out the ?secret? to generate those >> tokens and try to break something generated with salt + iterations with >> PBKDF2. >> >> Into other words is not impossible, but really hard. Another security >> hole would exist if the implementer incorrectly validate that token into >> the database. >> >> > >> > - Is there a way to have a relation between the token and the email >> > (or whatever other unique identifier for the user) so that when >> > the user clicks the link the backend already knows which users >> > it concerns and just handle the password reset ? Or is that something >> > that we don't want and the user will always have to enter his email >> > when resetting ? >> >> Into the way like it was written is possible but not recommended and >> lemme explain why (call me paranoid). >> >> Scenario 1: >> >> If an attacker hack the database and face with a table with a bunch of >> tokens but no relationship with other tables, will be hard to figure out >> which token belongs to an specific user and basically will be necessary to >> guess which token belongs to an specific e-mail. >> >> Scenario 2: >> >> If we add a relationship between a table like ?Token? and for example >> ?User?, the attacker don?t need to guess anymore, is just a matter of check >> which token belongs to ?john at doe.com? for example. >> >> As I mentioned, is up to the implementer but for paranoids, risky. >> > > Ok, we will keep it simple and safe, just one "token" table with no > relations. > >> >> Let me know if something doesn?t make sense. >> > > Thanks for your answers ! > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20131216/bba832d8/attachment.html From bruno at abstractj.org Mon Dec 16 10:16:11 2013 From: bruno at abstractj.org (Bruno Oliveira) Date: Mon, 16 Dec 2013 13:16:11 -0200 Subject: [aerogear-dev] Team Meeting In-Reply-To: References: Message-ID: Le minutes... [13:15] jbott: Meeting ended Mon Dec 16 15:06:23 2013 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) [13:15] jbott: Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2013/aerogear.2013-12-16-14.53.html [13:15] jbott: Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2013/aerogear.2013-12-16-14.53.txt [13:15] jbott: Log: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2013/aerogear.2013-12-16-14.53.log.html On Mon, Dec 16, 2013 at 6:01 AM, Daniel Bevenius wrote: > Agenda: > http://oksoclap.com/p/aerogear-team-mgt-20131216 > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- -- "The measure of a man is what he does with power" - Plato - @abstractj - Volenti Nihil Difficile -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20131216/3b443103/attachment-0001.html From bsutter at redhat.com Mon Dec 16 13:52:55 2013 From: bsutter at redhat.com (Burr Sutter) Date: Mon, 16 Dec 2013 13:52:55 -0500 Subject: [aerogear-dev] Aerogear.js for CRUD In-Reply-To: References: Message-ID: <504FFE44-06CE-4C05-A8A6-D049D2D41E00@redhat.com> Adding Vineet as he has spent time on the Forge REST scaffolding. On Dec 16, 2013, at 7:01 AM, Sebastien Blanc wrote: > Burr, > I've added some logs statements on the client and basically it seems it can not parse the response from the server : > > I/Web Console( 1386): textStatus: parsererror at file:///android_asset/www/js/index.js:103 > I/Web Console( 1386): error: SyntaxError: Unexpected end of input at file:///android_asset/www/js/index.js:104 > > If I do a CURL like this : > curl -v -b cookies.txt -c cookies.txt -H "Accept: application/json" -H "Content-type: application/json" -X POST -d '{"phoneNumber":"1234567890","email":"newTest at test.com","name":"newTest"}' http://agmobile-html5.rhcloud.com/rest/forge/members > I should have pointed to the sources to the REST endpoint: https://github.com/burrsutter/agmobile/blob/master/src/main/java/com/burrsutter/agmobile/rest/MemberEndpoint.java This was generated by Forge as I am too lazy to type up a full CRUD REST endpoint myself :-) > I got an correct answer but the content type is 'text/plain' , please check your rest endpoint to be sure it's producing json as output, that should solve your issue. It says @POST @Consumes("application/json") > > Could you also paste the commands you used in Forge to scaffold the REST endpoints so that we can check there hasn't been an incompatibility introduced ? I just used the Forge Wizard that is built into JBDS/Tools http://screencast.com/t/QrKkCoFZMUn error.status is 201 error.responseText is blank > > > > > On Sat, Dec 14, 2013 at 6:06 PM, Burr Sutter wrote: > I am having a problem with pipe.save(), likely user error :-) > > For some reason, the POST is occurring, the save seems to work but the error callback is invoked, not the success method. > > And I am doing all of this in the context of our tooling which has some limitations (auto-closing console/firebug lite) > > http://screencast.com/t/gosd7Qnhz > > REST endpoint: > http://agmobile-html5.rhcloud.com/rest/forge/members > Use of Forge, with the Member.java entity to offer full CRUD capabilities > > Sources: > https://github.com/burrsutter/AGContacts/blob/master/www/js/index.js > > > _______________________________________________ > 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/20131216/242d9607/attachment.html From lholmqui at redhat.com Mon Dec 16 14:23:25 2013 From: lholmqui at redhat.com (Lucas Holmquist) Date: Mon, 16 Dec 2013 14:23:25 -0500 Subject: [aerogear-dev] Aerogear.js for CRUD In-Reply-To: <504FFE44-06CE-4C05-A8A6-D049D2D41E00@redhat.com> References: <504FFE44-06CE-4C05-A8A6-D049D2D41E00@redhat.com> Message-ID: On Dec 16, 2013, at 1:52 PM, Burr Sutter wrote: > Adding Vineet as he has spent time on the Forge REST scaffolding. > > On Dec 16, 2013, at 7:01 AM, Sebastien Blanc wrote: > >> Burr, >> I've added some logs statements on the client and basically it seems it can not parse the response from the server : >> >> I/Web Console( 1386): textStatus: parsererror at file:///android_asset/www/js/index.js:103 >> I/Web Console( 1386): error: SyntaxError: Unexpected end of input at file:///android_asset/www/js/index.js:104 >> >> If I do a CURL like this : >> curl -v -b cookies.txt -c cookies.txt -H "Accept: application/json" -H "Content-type: application/json" -X POST -d '{"phoneNumber":"1234567890","email":"newTest at test.com","name":"newTest"}' http://agmobile-html5.rhcloud.com/rest/forge/members >> > I should have pointed to the sources to the REST endpoint: > https://github.com/burrsutter/agmobile/blob/master/src/main/java/com/burrsutter/agmobile/rest/MemberEndpoint.java > This was generated by Forge as I am too lazy to type up a full CRUD REST endpoint myself :-) > >> I got an correct answer but the content type is 'text/plain' , please check your rest endpoint to be sure it's producing json as output, that should solve your issue. > It says > @POST > @Consumes("application/json") > needs a @Produces("application/json") > >> >> Could you also paste the commands you used in Forge to scaffold the REST endpoints so that we can check there hasn't been an incompatibility introduced ? > I just used the Forge Wizard that is built into JBDS/Tools > http://screencast.com/t/QrKkCoFZMUn > > error.status is 201 > error.responseText is blank > >> >> >> >> >> On Sat, Dec 14, 2013 at 6:06 PM, Burr Sutter wrote: >> I am having a problem with pipe.save(), likely user error :-) >> >> For some reason, the POST is occurring, the save seems to work but the error callback is invoked, not the success method. >> >> And I am doing all of this in the context of our tooling which has some limitations (auto-closing console/firebug lite) >> >> http://screencast.com/t/gosd7Qnhz >> >> REST endpoint: >> http://agmobile-html5.rhcloud.com/rest/forge/members >> Use of Forge, with the Member.java entity to offer full CRUD capabilities >> >> Sources: >> https://github.com/burrsutter/AGContacts/blob/master/www/js/index.js >> >> >> _______________________________________________ >> 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/20131216/a5fa83e3/attachment.html From vpereira at redhat.com Mon Dec 16 15:06:58 2013 From: vpereira at redhat.com (Vineet Reynolds Pereira) Date: Mon, 16 Dec 2013 15:06:58 -0500 (EST) Subject: [aerogear-dev] Aerogear.js for CRUD In-Reply-To: References: <504FFE44-06CE-4C05-A8A6-D049D2D41E00@redhat.com> Message-ID: <1445599908.40527893.1387224418368.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Lucas Holmquist" > To: "AeroGear Developer Mailing List" > Cc: "Vineet Reynolds Pereira" > Sent: Tuesday, December 17, 2013 12:53:25 AM > Subject: Re: [aerogear-dev] Aerogear.js for CRUD > > > On Dec 16, 2013, at 1:52 PM, Burr Sutter wrote: > > > Adding Vineet as he has spent time on the Forge REST scaffolding. > > > > On Dec 16, 2013, at 7:01 AM, Sebastien Blanc wrote: > > > >> Burr, > >> I've added some logs statements on the client and basically it seems it > >> can not parse the response from the server : > >> > >> I/Web Console( 1386): textStatus: parsererror at > >> file:///android_asset/www/js/index.js:103 > >> I/Web Console( 1386): error: SyntaxError: Unexpected end of input at > >> file:///android_asset/www/js/index.js:104 > >> > >> If I do a CURL like this : > >> curl -v -b cookies.txt -c cookies.txt -H "Accept: application/json" -H > >> "Content-type: application/json" -X POST -d > >> '{"phoneNumber":"1234567890","email":"newTest at test.com","name":"newTest"}' > >> http://agmobile-html5.rhcloud.com/rest/forge/members > >> > > I should have pointed to the sources to the REST endpoint: > > https://github.com/burrsutter/agmobile/blob/master/src/main/java/com/burrsutter/agmobile/rest/MemberEndpoint.java > > This was generated by Forge as I am too lazy to type up a full CRUD REST > > endpoint myself :-) > > > >> I got an correct answer but the content type is 'text/plain' , please > >> check your rest endpoint to be sure it's producing json as output, that > >> should solve your issue. > > It says > > @POST > > @Consumes("application/json") > > > needs a @Produces("application/json") I'm not sure that will help. The response is a HTTP 201 with a Location header. Is the client expecting an entity of type application/json in the response ? If yes, then the method should look like: @POST @Consumes("application/json") public Response create(MemberDTO dto) { Member entity = dto.fromDTO(null, em); em.persist(entity); return Response.created(UriBuilder.fromResource(MemberEndpoint.class).path(String.valueOf(entity.getId())).build()).entity(entity).build(); } I've added : .entity(entity) in the above method to populate the response with the entity. > > > > >> > >> Could you also paste the commands you used in Forge to scaffold the REST > >> endpoints so that we can check there hasn't been an incompatibility > >> introduced ? > > I just used the Forge Wizard that is built into JBDS/Tools > > http://screencast.com/t/QrKkCoFZMUn > > > > error.status is 201 > > error.responseText is blank > > > >> > >> > >> > >> > >> On Sat, Dec 14, 2013 at 6:06 PM, Burr Sutter wrote: > >> I am having a problem with pipe.save(), likely user error :-) > >> > >> For some reason, the POST is occurring, the save seems to work but the > >> error callback is invoked, not the success method. > >> > >> And I am doing all of this in the context of our tooling which has some > >> limitations (auto-closing console/firebug lite) > >> > >> http://screencast.com/t/gosd7Qnhz > >> > >> REST endpoint: > >> http://agmobile-html5.rhcloud.com/rest/forge/members > >> Use of Forge, with the Member.java entity to offer full CRUD capabilities > >> > >> Sources: > >> https://github.com/burrsutter/AGContacts/blob/master/www/js/index.js > >> > >> > >> _______________________________________________ > >> 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 bsutter at redhat.com Mon Dec 16 15:29:41 2013 From: bsutter at redhat.com (Burr Sutter) Date: Mon, 16 Dec 2013 15:29:41 -0500 Subject: [aerogear-dev] Aerogear.js for CRUD In-Reply-To: <1445599908.40527893.1387224418368.JavaMail.root@redhat.com> References: <504FFE44-06CE-4C05-A8A6-D049D2D41E00@redhat.com> <1445599908.40527893.1387224418368.JavaMail.root@redhat.com> Message-ID: That seems to do the trick - now, where do we apply the fix? :-) On Dec 16, 2013, at 3:06 PM, Vineet Reynolds Pereira wrote: > > > ----- Original Message ----- >> From: "Lucas Holmquist" >> To: "AeroGear Developer Mailing List" >> Cc: "Vineet Reynolds Pereira" >> Sent: Tuesday, December 17, 2013 12:53:25 AM >> Subject: Re: [aerogear-dev] Aerogear.js for CRUD >> >> >> On Dec 16, 2013, at 1:52 PM, Burr Sutter wrote: >> >>> Adding Vineet as he has spent time on the Forge REST scaffolding. >>> >>> On Dec 16, 2013, at 7:01 AM, Sebastien Blanc wrote: >>> >>>> Burr, >>>> I've added some logs statements on the client and basically it seems it >>>> can not parse the response from the server : >>>> >>>> I/Web Console( 1386): textStatus: parsererror at >>>> file:///android_asset/www/js/index.js:103 >>>> I/Web Console( 1386): error: SyntaxError: Unexpected end of input at >>>> file:///android_asset/www/js/index.js:104 >>>> >>>> If I do a CURL like this : >>>> curl -v -b cookies.txt -c cookies.txt -H "Accept: application/json" -H >>>> "Content-type: application/json" -X POST -d >>>> '{"phoneNumber":"1234567890","email":"newTest at test.com","name":"newTest"}' >>>> http://agmobile-html5.rhcloud.com/rest/forge/members >>>> >>> I should have pointed to the sources to the REST endpoint: >>> https://github.com/burrsutter/agmobile/blob/master/src/main/java/com/burrsutter/agmobile/rest/MemberEndpoint.java >>> This was generated by Forge as I am too lazy to type up a full CRUD REST >>> endpoint myself :-) >>> >>>> I got an correct answer but the content type is 'text/plain' , please >>>> check your rest endpoint to be sure it's producing json as output, that >>>> should solve your issue. >>> It says >>> @POST >>> @Consumes("application/json") >>> >> needs a @Produces("application/json") > > I'm not sure that will help. The response is a HTTP 201 with a Location header. > Is the client expecting an entity of type application/json in the response ? > > If yes, then the method should look like: > > @POST > @Consumes("application/json") > public Response create(MemberDTO dto) > { > Member entity = dto.fromDTO(null, em); > em.persist(entity); > return Response.created(UriBuilder.fromResource(MemberEndpoint.class).path(String.valueOf(entity.getId())).build()).entity(entity).build(); > } > > I've added : .entity(entity) in the above method to populate the response with the entity. > >> >>> >>>> >>>> Could you also paste the commands you used in Forge to scaffold the REST >>>> endpoints so that we can check there hasn't been an incompatibility >>>> introduced ? >>> I just used the Forge Wizard that is built into JBDS/Tools >>> http://screencast.com/t/QrKkCoFZMUn >>> >>> error.status is 201 >>> error.responseText is blank >>> >>>> >>>> >>>> >>>> >>>> On Sat, Dec 14, 2013 at 6:06 PM, Burr Sutter wrote: >>>> I am having a problem with pipe.save(), likely user error :-) >>>> >>>> For some reason, the POST is occurring, the save seems to work but the >>>> error callback is invoked, not the success method. >>>> >>>> And I am doing all of this in the context of our tooling which has some >>>> limitations (auto-closing console/firebug lite) >>>> >>>> http://screencast.com/t/gosd7Qnhz >>>> >>>> REST endpoint: >>>> http://agmobile-html5.rhcloud.com/rest/forge/members >>>> Use of Forge, with the Member.java entity to offer full CRUD capabilities >>>> >>>> Sources: >>>> https://github.com/burrsutter/AGContacts/blob/master/www/js/index.js >>>> >>>> >>>> _______________________________________________ >>>> 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/20131216/1c6c3374/attachment-0001.html From vpereira at redhat.com Mon Dec 16 16:25:53 2013 From: vpereira at redhat.com (Vineet Reynolds Pereira) Date: Mon, 16 Dec 2013 16:25:53 -0500 (EST) Subject: [aerogear-dev] Aerogear.js for CRUD In-Reply-To: References: <504FFE44-06CE-4C05-A8A6-D049D2D41E00@redhat.com> <1445599908.40527893.1387224418368.JavaMail.root@redhat.com> Message-ID: <1928607956.40560513.1387229153309.JavaMail.root@redhat.com> Adding forge-dev. ----- Original Message ----- > From: "Burr Sutter" > To: "AeroGear Developer Mailing List" > Sent: Tuesday, December 17, 2013 1:59:41 AM > Subject: Re: [aerogear-dev] Aerogear.js for CRUD > > That seems to do the trick - now, where do we apply the fix? :-) Well, ideally this would be a feature request in Forge to support a new type of a REST resource. But a couple of modified lines might not warrant it. It would be better to treat this as a flag to be enabled during REST resource scaffolding. It would allow users to choose how the resource behaves - * send a 201 response with Location header, * send a 201 response with Location header and also a response entity. It would most likely be addressed in Forge 2. > > On Dec 16, 2013, at 3:06 PM, Vineet Reynolds Pereira < vpereira at redhat.com > > wrote: > > > > > > > ----- Original Message ----- > > > From: "Lucas Holmquist" < lholmqui at redhat.com > > To: "AeroGear Developer Mailing List" < aerogear-dev at lists.jboss.org > > Cc: "Vineet Reynolds Pereira" < vpereira at redhat.com > > Sent: Tuesday, December 17, 2013 12:53:25 AM > Subject: Re: [aerogear-dev] Aerogear.js for CRUD > > > On Dec 16, 2013, at 1:52 PM, Burr Sutter < bsutter at redhat.com > wrote: > > > > Adding Vineet as he has spent time on the Forge REST scaffolding. > > On Dec 16, 2013, at 7:01 AM, Sebastien Blanc < scm.blanc at gmail.com > wrote: > > > > Burr, > I've added some logs statements on the client and basically it seems it > can not parse the response from the server : > > I/Web Console( 1386): textStatus: parsererror at > file:///android_asset/www/js/index.js:103 > I/Web Console( 1386): error: SyntaxError: Unexpected end of input at > file:///android_asset/www/js/index.js:104 > > If I do a CURL like this : > curl -v -b cookies.txt -c cookies.txt -H "Accept: application/json" -H > "Content-type: application/json" -X POST -d > '{"phoneNumber":"1234567890","email":"newTest at test.com","name":"newTest"}' > http://agmobile-html5.rhcloud.com/rest/forge/members > > I should have pointed to the sources to the REST endpoint: > https://github.com/burrsutter/agmobile/blob/master/src/main/java/com/burrsutter/agmobile/rest/MemberEndpoint.java > This was generated by Forge as I am too lazy to type up a full CRUD REST > endpoint myself :-) > > > > I got an correct answer but the content type is 'text/plain' , please > check your rest endpoint to be sure it's producing json as output, that > should solve your issue. > It says > @POST > @Consumes("application/json") > > needs a @Produces("application/json") > > I'm not sure that will help. The response is a HTTP 201 with a Location > header. > Is the client expecting an entity of type application/json in the response ? > > If yes, then the method should look like: > > @POST > @Consumes("application/json") > public Response create(MemberDTO dto) > { > Member entity = dto.fromDTO(null, em); > em.persist(entity); > return > Response.created(UriBuilder.fromResource(MemberEndpoint.class).path(String.valueOf(entity.getId())).build()).entity(entity).build(); > } > > I've added : .entity(entity) in the above method to populate the response > with the entity. > > > > > > > > > > > Could you also paste the commands you used in Forge to scaffold the REST > endpoints so that we can check there hasn't been an incompatibility > introduced ? > I just used the Forge Wizard that is built into JBDS/Tools > http://screencast.com/t/QrKkCoFZMUn > > error.status is 201 > error.responseText is blank > > > > > > > > On Sat, Dec 14, 2013 at 6:06 PM, Burr Sutter wrote: > I am having a problem with pipe.save(), likely user error :-) > > For some reason, the POST is occurring, the save seems to work but the > error callback is invoked, not the success method. > > And I am doing all of this in the context of our tooling which has some > limitations (auto-closing console/firebug lite) > > http://screencast.com/t/gosd7Qnhz > > REST endpoint: > http://agmobile-html5.rhcloud.com/rest/forge/members > Use of Forge, with the Member.java entity to offer full CRUD capabilities > > Sources: > https://github.com/burrsutter/AGContacts/blob/master/www/js/index.js > > > _______________________________________________ > 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 From vpereira at redhat.com Mon Dec 16 16:27:10 2013 From: vpereira at redhat.com (Vineet Reynolds Pereira) Date: Mon, 16 Dec 2013 16:27:10 -0500 (EST) Subject: [aerogear-dev] Aerogear.js for CRUD In-Reply-To: <1928607956.40560513.1387229153309.JavaMail.root@redhat.com> References: <504FFE44-06CE-4C05-A8A6-D049D2D41E00@redhat.com> <1445599908.40527893.1387224418368.JavaMail.root@redhat.com> <1928607956.40560513.1387229153309.JavaMail.root@redhat.com> Message-ID: <1835599751.40562229.1387229230777.JavaMail.root@redhat.com> I missed something: raised https://issues.jboss.org/browse/FORGE-1361 to track this. If there is anything more specific to Aerogear clients that can be done, I'd like to know about them as well. ----- Original Message ----- > From: "Vineet Reynolds Pereira" > To: "AeroGear Developer Mailing List" > Cc: "forge-dev List" > Sent: Tuesday, December 17, 2013 2:55:53 AM > Subject: Re: [aerogear-dev] Aerogear.js for CRUD > > Adding forge-dev. > > ----- Original Message ----- > > From: "Burr Sutter" > > To: "AeroGear Developer Mailing List" > > Sent: Tuesday, December 17, 2013 1:59:41 AM > > Subject: Re: [aerogear-dev] Aerogear.js for CRUD > > > > That seems to do the trick - now, where do we apply the fix? :-) > > Well, ideally this would be a feature request in Forge to support a new type > of a REST resource. But a couple of modified lines might not warrant it. > > It would be better to treat this as a flag to be enabled during REST resource > scaffolding. It would allow users to choose how the resource behaves - > * send a 201 response with Location header, > * send a 201 response with Location header and also a response entity. > > It would most likely be addressed in Forge 2. > > > > > On Dec 16, 2013, at 3:06 PM, Vineet Reynolds Pereira < vpereira at redhat.com > > > > > wrote: > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Lucas Holmquist" < lholmqui at redhat.com > > > To: "AeroGear Developer Mailing List" < aerogear-dev at lists.jboss.org > > > Cc: "Vineet Reynolds Pereira" < vpereira at redhat.com > > > Sent: Tuesday, December 17, 2013 12:53:25 AM > > Subject: Re: [aerogear-dev] Aerogear.js for CRUD > > > > > > On Dec 16, 2013, at 1:52 PM, Burr Sutter < bsutter at redhat.com > wrote: > > > > > > > > Adding Vineet as he has spent time on the Forge REST scaffolding. > > > > On Dec 16, 2013, at 7:01 AM, Sebastien Blanc < scm.blanc at gmail.com > wrote: > > > > > > > > Burr, > > I've added some logs statements on the client and basically it seems it > > can not parse the response from the server : > > > > I/Web Console( 1386): textStatus: parsererror at > > file:///android_asset/www/js/index.js:103 > > I/Web Console( 1386): error: SyntaxError: Unexpected end of input at > > file:///android_asset/www/js/index.js:104 > > > > If I do a CURL like this : > > curl -v -b cookies.txt -c cookies.txt -H "Accept: application/json" -H > > "Content-type: application/json" -X POST -d > > '{"phoneNumber":"1234567890","email":"newTest at test.com","name":"newTest"}' > > http://agmobile-html5.rhcloud.com/rest/forge/members > > > > I should have pointed to the sources to the REST endpoint: > > https://github.com/burrsutter/agmobile/blob/master/src/main/java/com/burrsutter/agmobile/rest/MemberEndpoint.java > > This was generated by Forge as I am too lazy to type up a full CRUD REST > > endpoint myself :-) > > > > > > > > I got an correct answer but the content type is 'text/plain' , please > > check your rest endpoint to be sure it's producing json as output, that > > should solve your issue. > > It says > > @POST > > @Consumes("application/json") > > > > needs a @Produces("application/json") > > > > I'm not sure that will help. The response is a HTTP 201 with a Location > > header. > > Is the client expecting an entity of type application/json in the response > > ? > > > > If yes, then the method should look like: > > > > @POST > > @Consumes("application/json") > > public Response create(MemberDTO dto) > > { > > Member entity = dto.fromDTO(null, em); > > em.persist(entity); > > return > > Response.created(UriBuilder.fromResource(MemberEndpoint.class).path(String.valueOf(entity.getId())).build()).entity(entity).build(); > > } > > > > I've added : .entity(entity) in the above method to populate the response > > with the entity. > > > > > > > > > > > > > > > > > > > > > > Could you also paste the commands you used in Forge to scaffold the REST > > endpoints so that we can check there hasn't been an incompatibility > > introduced ? > > I just used the Forge Wizard that is built into JBDS/Tools > > http://screencast.com/t/QrKkCoFZMUn > > > > error.status is 201 > > error.responseText is blank > > > > > > > > > > > > > > > > On Sat, Dec 14, 2013 at 6:06 PM, Burr Sutter wrote: > > I am having a problem with pipe.save(), likely user error :-) > > > > For some reason, the POST is occurring, the save seems to work but the > > error callback is invoked, not the success method. > > > > And I am doing all of this in the context of our tooling which has some > > limitations (auto-closing console/firebug lite) > > > > http://screencast.com/t/gosd7Qnhz > > > > REST endpoint: > > http://agmobile-html5.rhcloud.com/rest/forge/members > > Use of Forge, with the Member.java entity to offer full CRUD capabilities > > > > Sources: > > https://github.com/burrsutter/AGContacts/blob/master/www/js/index.js > > > > > > _______________________________________________ > > 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 > From bsutter at redhat.com Mon Dec 16 17:41:54 2013 From: bsutter at redhat.com (Burr Sutter) Date: Mon, 16 Dec 2013 17:41:54 -0500 Subject: [aerogear-dev] [forge-dev] Aerogear.js for CRUD In-Reply-To: <1928607956.40560513.1387229153309.JavaMail.root@redhat.com> References: <504FFE44-06CE-4C05-A8A6-D049D2D41E00@redhat.com> <1445599908.40527893.1387224418368.JavaMail.root@redhat.com> <1928607956.40560513.1387229153309.JavaMail.root@redhat.com> Message-ID: I need to find my REST bible - what is typical to respond to the POST with the JSON-serialized entity that was originally POST'd or to simply respond with a basic acknowledgement (http 201)? On Dec 16, 2013, at 4:25 PM, Vineet Reynolds Pereira wrote: > Adding forge-dev. > > ----- Original Message ----- >> From: "Burr Sutter" >> To: "AeroGear Developer Mailing List" >> Sent: Tuesday, December 17, 2013 1:59:41 AM >> Subject: Re: [aerogear-dev] Aerogear.js for CRUD >> >> That seems to do the trick - now, where do we apply the fix? :-) > > Well, ideally this would be a feature request in Forge to support a new type > of a REST resource. But a couple of modified lines might not warrant it. > > It would be better to treat this as a flag to be enabled during REST resource > scaffolding. It would allow users to choose how the resource behaves - > * send a 201 response with Location header, > * send a 201 response with Location header and also a response entity. > > It would most likely be addressed in Forge 2. > >> >> On Dec 16, 2013, at 3:06 PM, Vineet Reynolds Pereira < vpereira at redhat.com > >> wrote: >> >> >> >> >> >> >> ----- Original Message ----- >> >> >> From: "Lucas Holmquist" < lholmqui at redhat.com > >> To: "AeroGear Developer Mailing List" < aerogear-dev at lists.jboss.org > >> Cc: "Vineet Reynolds Pereira" < vpereira at redhat.com > >> Sent: Tuesday, December 17, 2013 12:53:25 AM >> Subject: Re: [aerogear-dev] Aerogear.js for CRUD >> >> >> On Dec 16, 2013, at 1:52 PM, Burr Sutter < bsutter at redhat.com > wrote: >> >> >> >> Adding Vineet as he has spent time on the Forge REST scaffolding. >> >> On Dec 16, 2013, at 7:01 AM, Sebastien Blanc < scm.blanc at gmail.com > wrote: >> >> >> >> Burr, >> I've added some logs statements on the client and basically it seems it >> can not parse the response from the server : >> >> I/Web Console( 1386): textStatus: parsererror at >> file:///android_asset/www/js/index.js:103 >> I/Web Console( 1386): error: SyntaxError: Unexpected end of input at >> file:///android_asset/www/js/index.js:104 >> >> If I do a CURL like this : >> curl -v -b cookies.txt -c cookies.txt -H "Accept: application/json" -H >> "Content-type: application/json" -X POST -d >> '{"phoneNumber":"1234567890","email":"newTest at test.com","name":"newTest"}' >> http://agmobile-html5.rhcloud.com/rest/forge/members >> >> I should have pointed to the sources to the REST endpoint: >> https://github.com/burrsutter/agmobile/blob/master/src/main/java/com/burrsutter/agmobile/rest/MemberEndpoint.java >> This was generated by Forge as I am too lazy to type up a full CRUD REST >> endpoint myself :-) >> >> >> >> I got an correct answer but the content type is 'text/plain' , please >> check your rest endpoint to be sure it's producing json as output, that >> should solve your issue. >> It says >> @POST >> @Consumes("application/json") >> >> needs a @Produces("application/json") >> >> I'm not sure that will help. The response is a HTTP 201 with a Location >> header. >> Is the client expecting an entity of type application/json in the response ? >> >> If yes, then the method should look like: >> >> @POST >> @Consumes("application/json") >> public Response create(MemberDTO dto) >> { >> Member entity = dto.fromDTO(null, em); >> em.persist(entity); >> return >> Response.created(UriBuilder.fromResource(MemberEndpoint.class).path(String.valueOf(entity.getId())).build()).entity(entity).build(); >> } >> >> I've added : .entity(entity) in the above method to populate the response >> with the entity. >> >> >> >> >> >> >> >> >> >> >> Could you also paste the commands you used in Forge to scaffold the REST >> endpoints so that we can check there hasn't been an incompatibility >> introduced ? >> I just used the Forge Wizard that is built into JBDS/Tools >> http://screencast.com/t/QrKkCoFZMUn >> >> error.status is 201 >> error.responseText is blank >> >> >> >> >> >> >> >> On Sat, Dec 14, 2013 at 6:06 PM, Burr Sutter wrote: >> I am having a problem with pipe.save(), likely user error :-) >> >> For some reason, the POST is occurring, the save seems to work but the >> error callback is invoked, not the success method. >> >> And I am doing all of this in the context of our tooling which has some >> limitations (auto-closing console/firebug lite) >> >> http://screencast.com/t/gosd7Qnhz >> >> REST endpoint: >> http://agmobile-html5.rhcloud.com/rest/forge/members >> Use of Forge, with the Member.java entity to offer full CRUD capabilities >> >> Sources: >> https://github.com/burrsutter/AGContacts/blob/master/www/js/index.js >> >> >> _______________________________________________ >> 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 > _______________________________________________ > forge-dev mailing list > forge-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20131216/2c37d994/attachment-0001.html From bruno at abstractj.org Mon Dec 16 21:01:58 2013 From: bruno at abstractj.org (Bruno Oliveira) Date: Tue, 17 Dec 2013 00:01:58 -0200 Subject: [aerogear-dev] AeroGear Security and AeroGear Crypto on Staging Message-ID: Good morning slackland, the sun is not shining yet, but I know you are more anxious than a kid waiting in long lines to take a pic with Santa to see the next release of AG Security. So there we go: AeroGear Security / AeroGear Security Picketlink 1.3.0 - Password reset feature (https://issues.jboss.org/browse/AGSEC-161). Thanks Sebastien for helping me with the integration of the feature into the UPS. - Upgrade to PicketLink 2.5.2.Final AeroGear Crypto Java 0.1.1 - Message authentication support (https://issues.jboss.org/browse/AGSEC-119) - AG Crypto Java will raise ClassNotFoundException for non Android projects (https://issues.jboss.org/browse/AGSEC-160) The repository was staged under?https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-2290/. I?m planning to release it on Wednesday so, feel free to test and provide some feedback. -- abstractj From vpereira at redhat.com Tue Dec 17 04:36:14 2013 From: vpereira at redhat.com (Vineet Reynolds Pereira) Date: Tue, 17 Dec 2013 04:36:14 -0500 (EST) Subject: [aerogear-dev] [forge-dev] Aerogear.js for CRUD In-Reply-To: <52B0187A.9020903@redhat.com> References: <1445599908.40527893.1387224418368.JavaMail.root@redhat.com> <1928607956.40560513.1387229153309.JavaMail.root@redhat.com> <52B0187A.9020903@redhat.com> Message-ID: <521510137.40738790.1387272974513.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Sebastien Blanc" > To: forge-dev at lists.jboss.org, aerogear-dev at lists.jboss.org > Sent: Tuesday, December 17, 2013 2:55:14 PM > Subject: Re: [forge-dev] [aerogear-dev] Aerogear.js for CRUD > > Adding again aerogear list. > I think that we must discuss with the team (aerogear) on how we can/must > handle a proper 201 response. I'd concur. Both of these are 'correct'. But it would be better to indicate if the client or consumers of the client should do anything more for 201 responses. Several clients (Backbone.js [1], AngularJS[2] etc.) expect that responses to POST contain the entity in the response. Consumers are expected to fetch the updated resource for a 201 with an empty body. 1: https://github.com/jashkenas/backbone/issues/1660 2: https://github.com/angular/angular.js/issues/2572 > > On 12/17/2013 09:58 AM, Ivan St. Ivanov wrote: > > > > Hi! > > I think that the 'right' approach is to respond with 201 (created) and return > a URI to the newly created resource. > > Cheers, > Ivan > > > On Tue, Dec 17, 2013 at 12:58 AM, Lincoln Baxter, III < > lincolnbaxter at gmail.com > wrote: > > > > Either is typical, but I think that most "pure" restifarians would favor the > 201. > > > On Mon, Dec 16, 2013 at 5:41 PM, Burr Sutter < bsutter at redhat.com > wrote: > > > > I need to find my REST bible - what is typical to respond to the POST with > the JSON-serialized entity that was originally POST'd or to simply respond > with a basic acknowledgement (http 201)? > > > On Dec 16, 2013, at 4:25 PM, Vineet Reynolds Pereira < vpereira at redhat.com > > wrote: > > > > > Adding forge-dev. > > ----- Original Message ----- > > > From: "Burr Sutter" < bsutter at redhat.com > > To: "AeroGear Developer Mailing List" < aerogear-dev at lists.jboss.org > > Sent: Tuesday, December 17, 2013 1:59:41 AM > Subject: Re: [aerogear-dev] Aerogear.js for CRUD > > That seems to do the trick - now, where do we apply the fix? :-) > > Well, ideally this would be a feature request in Forge to support a new type > of a REST resource. But a couple of modified lines might not warrant it. > > It would be better to treat this as a flag to be enabled during REST resource > scaffolding. It would allow users to choose how the resource behaves - > * send a 201 response with Location header, > * send a 201 response with Location header and also a response entity. > > It would most likely be addressed in Forge 2. > > > > > On Dec 16, 2013, at 3:06 PM, Vineet Reynolds Pereira < vpereira at redhat.com > > wrote: > > > > > > > ----- Original Message ----- > > > From: "Lucas Holmquist" < lholmqui at redhat.com > > To: "AeroGear Developer Mailing List" < aerogear-dev at lists.jboss.org > > Cc: "Vineet Reynolds Pereira" < vpereira at redhat.com > > Sent: Tuesday, December 17, 2013 12:53:25 AM > Subject: Re: [aerogear-dev] Aerogear.js for CRUD > > > On Dec 16, 2013, at 1:52 PM, Burr Sutter < bsutter at redhat.com > wrote: > > > > Adding Vineet as he has spent time on the Forge REST scaffolding. > > On Dec 16, 2013, at 7:01 AM, Sebastien Blanc < scm.blanc at gmail.com > wrote: > > > > Burr, > I've added some logs statements on the client and basically it seems it > can not parse the response from the server : > > I/Web Console( 1386): textStatus: parsererror at > file:///android_asset/www/js/index.js:103 > I/Web Console( 1386): error: SyntaxError: Unexpected end of input at > file:///android_asset/www/js/index.js:104 > > If I do a CURL like this : > curl -v -b cookies.txt -c cookies.txt -H "Accept: application/json" -H > "Content-type: application/json" -X POST -d > '{"phoneNumber":"1234567890","email":" newTest at test.com ","name":"newTest"}' > http://agmobile-html5.rhcloud.com/rest/forge/members > > I should have pointed to the sources to the REST endpoint: > https://github.com/burrsutter/agmobile/blob/master/src/main/java/com/burrsutter/agmobile/rest/MemberEndpoint.java > This was generated by Forge as I am too lazy to type up a full CRUD REST > endpoint myself :-) > > > > I got an correct answer but the content type is 'text/plain' , please > check your rest endpoint to be sure it's producing json as output, that > should solve your issue. > It says > @POST > @Consumes("application/json") > > needs a @Produces("application/json") > > I'm not sure that will help. The response is a HTTP 201 with a Location > header. > Is the client expecting an entity of type application/json in the response ? > > If yes, then the method should look like: > > @POST > @Consumes("application/json") > public Response create(MemberDTO dto) > { > Member entity = dto.fromDTO(null, em); > em.persist(entity); > return > Response.created(UriBuilder.fromResource(MemberEndpoint.class).path(String.valueOf(entity.getId())).build()).entity(entity).build(); > } > > I've added : .entity(entity) in the above method to populate the response > with the entity. > > > > > > > > > > > Could you also paste the commands you used in Forge to scaffold the REST > endpoints so that we can check there hasn't been an incompatibility > introduced ? > I just used the Forge Wizard that is built into JBDS/Tools > http://screencast.com/t/QrKkCoFZMUn > > error.status is 201 > error.responseText is blank > > > > > > > > On Sat, Dec 14, 2013 at 6:06 PM, Burr Sutter < bsutter at redhat.com > wrote: > I am having a problem with pipe.save(), likely user error :-) > > For some reason, the POST is occurring, the save seems to work but the > error callback is invoked, not the success method. > > And I am doing all of this in the context of our tooling which has some > limitations (auto-closing console/firebug lite) > > http://screencast.com/t/gosd7Qnhz > > REST endpoint: > http://agmobile-html5.rhcloud.com/rest/forge/members > Use of Forge, with the Member.java entity to offer full CRUD capabilities > > Sources: > https://github.com/burrsutter/AGContacts/blob/master/www/js/index.js > > > _______________________________________________ > 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 > _______________________________________________ > forge-dev mailing list > forge-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev > > > _______________________________________________ > forge-dev mailing list > forge-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > -- > Lincoln Baxter, III > http://ocpsoft.org > "Simpler is better." > > _______________________________________________ > forge-dev mailing list > forge-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > _______________________________________________ > forge-dev mailing list forge-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev > > > _______________________________________________ > forge-dev mailing list > forge-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev From lholmqui at redhat.com Tue Dec 17 08:29:10 2013 From: lholmqui at redhat.com (Lucas Holmquist) Date: Tue, 17 Dec 2013 08:29:10 -0500 Subject: [aerogear-dev] [forge-dev] Aerogear.js for CRUD In-Reply-To: <52B0187A.9020903@redhat.com> References: <504FFE44-06CE-4C05-A8A6-D049D2D41E00@redhat.com> <1445599908.40527893.1387224418368.JavaMail.root@redhat.com> <1928607956.40560513.1387229153309.JavaMail.root@redhat.com> <52B0187A.9020903@redhat.com> Message-ID: <98682D8D-478E-4D4E-87FE-C4F08B4F67AF@redhat.com> On Dec 17, 2013, at 4:25 AM, Sebastien Blanc wrote: > Adding again aerogear list. > I think that we must discuss with the team (aerogear) on how we can/must handle a proper 201 response. i don't see this as a client issue at all. jQuery ajax is used under the hood here and it is handling the 201 fine, but it is choking on parsing the response since it is not in the correct format, thus calling back in the error callback. this should really be handled on the server > > On 12/17/2013 09:58 AM, Ivan St. Ivanov wrote: >> Hi! >> >> I think that the 'right' approach is to respond with 201 (created) and return a URI to the newly created resource. >> >> Cheers, >> Ivan >> >> >> On Tue, Dec 17, 2013 at 12:58 AM, Lincoln Baxter, III wrote: >> Either is typical, but I think that most "pure" restifarians would favor the 201. >> >> >> On Mon, Dec 16, 2013 at 5:41 PM, Burr Sutter wrote: >> I need to find my REST bible - what is typical to respond to the POST with the JSON-serialized entity that was originally POST'd or to simply respond with a basic acknowledgement (http 201)? >> >> >> On Dec 16, 2013, at 4:25 PM, Vineet Reynolds Pereira wrote: >> >>> Adding forge-dev. >>> >>> ----- Original Message ----- >>>> From: "Burr Sutter" >>>> To: "AeroGear Developer Mailing List" >>>> Sent: Tuesday, December 17, 2013 1:59:41 AM >>>> Subject: Re: [aerogear-dev] Aerogear.js for CRUD >>>> >>>> That seems to do the trick - now, where do we apply the fix? :-) >>> >>> Well, ideally this would be a feature request in Forge to support a new type >>> of a REST resource. But a couple of modified lines might not warrant it. >>> >>> It would be better to treat this as a flag to be enabled during REST resource >>> scaffolding. It would allow users to choose how the resource behaves - >>> * send a 201 response with Location header, >>> * send a 201 response with Location header and also a response entity. >>> >>> It would most likely be addressed in Forge 2. >>> >>>> >>>> On Dec 16, 2013, at 3:06 PM, Vineet Reynolds Pereira < vpereira at redhat.com > >>>> wrote: >>>> >>>> >>>> >>>> >>>> >>>> >>>> ----- Original Message ----- >>>> >>>> >>>> From: "Lucas Holmquist" < lholmqui at redhat.com > >>>> To: "AeroGear Developer Mailing List" < aerogear-dev at lists.jboss.org > >>>> Cc: "Vineet Reynolds Pereira" < vpereira at redhat.com > >>>> Sent: Tuesday, December 17, 2013 12:53:25 AM >>>> Subject: Re: [aerogear-dev] Aerogear.js for CRUD >>>> >>>> >>>> On Dec 16, 2013, at 1:52 PM, Burr Sutter < bsutter at redhat.com > wrote: >>>> >>>> >>>> >>>> Adding Vineet as he has spent time on the Forge REST scaffolding. >>>> >>>> On Dec 16, 2013, at 7:01 AM, Sebastien Blanc < scm.blanc at gmail.com > wrote: >>>> >>>> >>>> >>>> Burr, >>>> I've added some logs statements on the client and basically it seems it >>>> can not parse the response from the server : >>>> >>>> I/Web Console( 1386): textStatus: parsererror at >>>> file:///android_asset/www/js/index.js:103 >>>> I/Web Console( 1386): error: SyntaxError: Unexpected end of input at >>>> file:///android_asset/www/js/index.js:104 >>>> >>>> If I do a CURL like this : >>>> curl -v -b cookies.txt -c cookies.txt -H "Accept: application/json" -H >>>> "Content-type: application/json" -X POST -d >>>> '{"phoneNumber":"1234567890","email":"newTest at test.com","name":"newTest"}' >>>> http://agmobile-html5.rhcloud.com/rest/forge/members >>>> >>>> I should have pointed to the sources to the REST endpoint: >>>> https://github.com/burrsutter/agmobile/blob/master/src/main/java/com/burrsutter/agmobile/rest/MemberEndpoint.java >>>> This was generated by Forge as I am too lazy to type up a full CRUD REST >>>> endpoint myself :-) >>>> >>>> >>>> >>>> I got an correct answer but the content type is 'text/plain' , please >>>> check your rest endpoint to be sure it's producing json as output, that >>>> should solve your issue. >>>> It says >>>> @POST >>>> @Consumes("application/json") >>>> >>>> needs a @Produces("application/json") >>>> >>>> I'm not sure that will help. The response is a HTTP 201 with a Location >>>> header. >>>> Is the client expecting an entity of type application/json in the response ? >>>> >>>> If yes, then the method should look like: >>>> >>>> @POST >>>> @Consumes("application/json") >>>> public Response create(MemberDTO dto) >>>> { >>>> Member entity = dto.fromDTO(null, em); >>>> em.persist(entity); >>>> return >>>> Response.created(UriBuilder.fromResource(MemberEndpoint.class).path(String.valueOf(entity.getId())).build()).entity(entity).build(); >>>> } >>>> >>>> I've added : .entity(entity) in the above method to populate the response >>>> with the entity. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Could you also paste the commands you used in Forge to scaffold the REST >>>> endpoints so that we can check there hasn't been an incompatibility >>>> introduced ? >>>> I just used the Forge Wizard that is built into JBDS/Tools >>>> http://screencast.com/t/QrKkCoFZMUn >>>> >>>> error.status is 201 >>>> error.responseText is blank >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Sat, Dec 14, 2013 at 6:06 PM, Burr Sutter wrote: >>>> I am having a problem with pipe.save(), likely user error :-) >>>> >>>> For some reason, the POST is occurring, the save seems to work but the >>>> error callback is invoked, not the success method. >>>> >>>> And I am doing all of this in the context of our tooling which has some >>>> limitations (auto-closing console/firebug lite) >>>> >>>> http://screencast.com/t/gosd7Qnhz >>>> >>>> REST endpoint: >>>> http://agmobile-html5.rhcloud.com/rest/forge/members >>>> Use of Forge, with the Member.java entity to offer full CRUD capabilities >>>> >>>> Sources: >>>> https://github.com/burrsutter/AGContacts/blob/master/www/js/index.js >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> _______________________________________________ >>> forge-dev mailing list >>> forge-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/forge-dev >> >> >> _______________________________________________ >> forge-dev mailing list >> forge-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/forge-dev >> >> >> >> -- >> Lincoln Baxter, III >> http://ocpsoft.org >> "Simpler is better." >> >> _______________________________________________ >> forge-dev mailing list >> forge-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/forge-dev >> >> >> >> _______________________________________________ >> forge-dev mailing list >> forge-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/forge-dev > > _______________________________________________ > forge-dev mailing list > forge-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20131217/b9e04973/attachment-0001.html From bsutter at redhat.com Tue Dec 17 08:55:02 2013 From: bsutter at redhat.com (Burr Sutter) Date: Tue, 17 Dec 2013 08:55:02 -0500 Subject: [aerogear-dev] [forge-dev] Aerogear.js for CRUD In-Reply-To: <521510137.40738790.1387272974513.JavaMail.root@redhat.com> References: <1445599908.40527893.1387224418368.JavaMail.root@redhat.com> <1928607956.40560513.1387229153309.JavaMail.root@redhat.com> <52B0187A.9020903@redhat.com> <521510137.40738790.1387272974513.JavaMail.root@redhat.com> Message-ID: <1479565A-A100-48B2-A05F-9351EC223443@redhat.com> On Dec 17, 2013, at 4:36 AM, Vineet Reynolds Pereira wrote: > > > ----- Original Message ----- >> From: "Sebastien Blanc" >> To: forge-dev at lists.jboss.org, aerogear-dev at lists.jboss.org >> Sent: Tuesday, December 17, 2013 2:55:14 PM >> Subject: Re: [forge-dev] [aerogear-dev] Aerogear.js for CRUD >> >> Adding again aerogear list. >> I think that we must discuss with the team (aerogear) on how we can/must >> handle a proper 201 response. > > I'd concur. Both of these are 'correct'. But it would be better to indicate > if the client or consumers of the client should do anything more for 201 responses. > > Several clients (Backbone.js [1], AngularJS[2] etc.) expect that responses to POST contain > the entity in the response. Consumers are expected to fetch the updated resource for a 201 > with an empty body. These statements seem almost contradict each other. If Backbone/Angular assume that the response to a POST is a 201 with the entire entity from the server then that suggests that Aerogear's default is also correct behavior, in which case, the Forge scaffolding should be corrected. If "Consumers are expected to fetch the updated resource for a 201with an empty body", then no JSON serialized entity is needed in the response. My definitions (which may be different than yours) - 201 is the http response header/status - entity is the entire object (e.g. Person, Customer, Part, Order) that was originally POST'd/INSERTed + any default values returned by the ORM+RDBMS (e.g. auto-inc id, pre-populated fields from triggers, etc) - response body is where the JSON-serialized entity payload would be > > 1: https://github.com/jashkenas/backbone/issues/1660 > 2: https://github.com/angular/angular.js/issues/2572 > > >> >> On 12/17/2013 09:58 AM, Ivan St. Ivanov wrote: >> >> >> >> Hi! >> >> I think that the 'right' approach is to respond with 201 (created) and return >> a URI to the newly created resource. >> >> Cheers, >> Ivan >> >> >> On Tue, Dec 17, 2013 at 12:58 AM, Lincoln Baxter, III < >> lincolnbaxter at gmail.com > wrote: >> >> >> >> Either is typical, but I think that most "pure" restifarians would favor the >> 201. >> >> >> On Mon, Dec 16, 2013 at 5:41 PM, Burr Sutter < bsutter at redhat.com > wrote: >> >> >> >> I need to find my REST bible - what is typical to respond to the POST with >> the JSON-serialized entity that was originally POST'd or to simply respond >> with a basic acknowledgement (http 201)? >> >> >> On Dec 16, 2013, at 4:25 PM, Vineet Reynolds Pereira < vpereira at redhat.com > >> wrote: >> >> >> >> >> Adding forge-dev. >> >> ----- Original Message ----- >> >> >> From: "Burr Sutter" < bsutter at redhat.com > >> To: "AeroGear Developer Mailing List" < aerogear-dev at lists.jboss.org > >> Sent: Tuesday, December 17, 2013 1:59:41 AM >> Subject: Re: [aerogear-dev] Aerogear.js for CRUD >> >> That seems to do the trick - now, where do we apply the fix? :-) >> >> Well, ideally this would be a feature request in Forge to support a new type >> of a REST resource. But a couple of modified lines might not warrant it. >> >> It would be better to treat this as a flag to be enabled during REST resource >> scaffolding. It would allow users to choose how the resource behaves - >> * send a 201 response with Location header, >> * send a 201 response with Location header and also a response entity. >> >> It would most likely be addressed in Forge 2. >> >> >> >> >> On Dec 16, 2013, at 3:06 PM, Vineet Reynolds Pereira < vpereira at redhat.com > >> wrote: >> >> >> >> >> >> >> ----- Original Message ----- >> >> >> From: "Lucas Holmquist" < lholmqui at redhat.com > >> To: "AeroGear Developer Mailing List" < aerogear-dev at lists.jboss.org > >> Cc: "Vineet Reynolds Pereira" < vpereira at redhat.com > >> Sent: Tuesday, December 17, 2013 12:53:25 AM >> Subject: Re: [aerogear-dev] Aerogear.js for CRUD >> >> >> On Dec 16, 2013, at 1:52 PM, Burr Sutter < bsutter at redhat.com > wrote: >> >> >> >> Adding Vineet as he has spent time on the Forge REST scaffolding. >> >> On Dec 16, 2013, at 7:01 AM, Sebastien Blanc < scm.blanc at gmail.com > wrote: >> >> >> >> Burr, >> I've added some logs statements on the client and basically it seems it >> can not parse the response from the server : >> >> I/Web Console( 1386): textStatus: parsererror at >> file:///android_asset/www/js/index.js:103 >> I/Web Console( 1386): error: SyntaxError: Unexpected end of input at >> file:///android_asset/www/js/index.js:104 >> >> If I do a CURL like this : >> curl -v -b cookies.txt -c cookies.txt -H "Accept: application/json" -H >> "Content-type: application/json" -X POST -d >> '{"phoneNumber":"1234567890","email":" newTest at test.com ","name":"newTest"}' >> http://agmobile-html5.rhcloud.com/rest/forge/members >> >> I should have pointed to the sources to the REST endpoint: >> https://github.com/burrsutter/agmobile/blob/master/src/main/java/com/burrsutter/agmobile/rest/MemberEndpoint.java >> This was generated by Forge as I am too lazy to type up a full CRUD REST >> endpoint myself :-) >> >> >> >> I got an correct answer but the content type is 'text/plain' , please >> check your rest endpoint to be sure it's producing json as output, that >> should solve your issue. >> It says >> @POST >> @Consumes("application/json") >> >> needs a @Produces("application/json") >> >> I'm not sure that will help. The response is a HTTP 201 with a Location >> header. >> Is the client expecting an entity of type application/json in the response ? >> >> If yes, then the method should look like: >> >> @POST >> @Consumes("application/json") >> public Response create(MemberDTO dto) >> { >> Member entity = dto.fromDTO(null, em); >> em.persist(entity); >> return >> Response.created(UriBuilder.fromResource(MemberEndpoint.class).path(String.valueOf(entity.getId())).build()).entity(entity).build(); >> } >> >> I've added : .entity(entity) in the above method to populate the response >> with the entity. >> >> >> >> >> >> >> >> >> >> >> Could you also paste the commands you used in Forge to scaffold the REST >> endpoints so that we can check there hasn't been an incompatibility >> introduced ? >> I just used the Forge Wizard that is built into JBDS/Tools >> http://screencast.com/t/QrKkCoFZMUn >> >> error.status is 201 >> error.responseText is blank >> >> >> >> >> >> >> >> On Sat, Dec 14, 2013 at 6:06 PM, Burr Sutter < bsutter at redhat.com > wrote: >> I am having a problem with pipe.save(), likely user error :-) >> >> For some reason, the POST is occurring, the save seems to work but the >> error callback is invoked, not the success method. >> >> And I am doing all of this in the context of our tooling which has some >> limitations (auto-closing console/firebug lite) >> >> http://screencast.com/t/gosd7Qnhz >> >> REST endpoint: >> http://agmobile-html5.rhcloud.com/rest/forge/members >> Use of Forge, with the Member.java entity to offer full CRUD capabilities >> >> Sources: >> https://github.com/burrsutter/AGContacts/blob/master/www/js/index.js >> >> >> _______________________________________________ >> 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 >> _______________________________________________ >> forge-dev mailing list >> forge-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/forge-dev >> >> >> _______________________________________________ >> forge-dev mailing list >> forge-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/forge-dev >> >> >> >> -- >> Lincoln Baxter, III >> http://ocpsoft.org >> "Simpler is better." >> >> _______________________________________________ >> forge-dev mailing list >> forge-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/forge-dev >> >> >> >> _______________________________________________ >> forge-dev mailing list forge-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/forge-dev >> >> >> _______________________________________________ >> forge-dev mailing list >> forge-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/forge-dev > _______________________________________________ > forge-dev mailing list > forge-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20131217/8fce662e/attachment.html From vpereira at redhat.com Tue Dec 17 09:43:50 2013 From: vpereira at redhat.com (Vineet Reynolds Pereira) Date: Tue, 17 Dec 2013 09:43:50 -0500 (EST) Subject: [aerogear-dev] [forge-dev] Aerogear.js for CRUD In-Reply-To: <98682D8D-478E-4D4E-87FE-C4F08B4F67AF@redhat.com> References: <1928607956.40560513.1387229153309.JavaMail.root@redhat.com> <52B0187A.9020903@redhat.com> <98682D8D-478E-4D4E-87FE-C4F08B4F67AF@redhat.com> Message-ID: <2032951163.40864303.1387291430377.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Lucas Holmquist" > To: "forge-dev List" > Cc: aerogear-dev at lists.jboss.org > Sent: Tuesday, December 17, 2013 6:59:10 PM > Subject: Re: [forge-dev] [aerogear-dev] Aerogear.js for CRUD > > > On Dec 17, 2013, at 4:25 AM, Sebastien Blanc < sblanc at redhat.com > wrote: > > > > > Adding again aerogear list. > I think that we must discuss with the team (aerogear) on how we can/must > handle a proper 201 response. > > i don't see this as a client issue at all. jQuery ajax is used under the hood > here and it is handling the 201 fine, but it is choking on parsing the > response since it is not in the correct format, thus calling back in the > error callback. Ah, you mean this problem: http://jquery.com/upgrade-guide/1.9/#jquery-ajax-returning-a-json-result-of-an-empty-string This would definitely require the server to not send empty responses when the client expects JSON. > > this should really be handled on the server > > > > > > On 12/17/2013 09:58 AM, Ivan St. Ivanov wrote: > > > > Hi! > > I think that the 'right' approach is to respond with 201 (created) and return > a URI to the newly created resource. > > Cheers, > Ivan > > > On Tue, Dec 17, 2013 at 12:58 AM, Lincoln Baxter, III < > lincolnbaxter at gmail.com > wrote: > > > > Either is typical, but I think that most "pure" restifarians would favor the > 201. > > > On Mon, Dec 16, 2013 at 5:41 PM, Burr Sutter < bsutter at redhat.com > wrote: > > > > I need to find my REST bible - what is typical to respond to the POST with > the JSON-serialized entity that was originally POST'd or to simply respond > with a basic acknowledgement (http 201)? > > > On Dec 16, 2013, at 4:25 PM, Vineet Reynolds Pereira < vpereira at redhat.com > > wrote: > > > > > Adding forge-dev. > > ----- Original Message ----- > > > From: "Burr Sutter" < bsutter at redhat.com > > To: "AeroGear Developer Mailing List" < aerogear-dev at lists.jboss.org > > Sent: Tuesday, December 17, 2013 1:59:41 AM > Subject: Re: [aerogear-dev] Aerogear.js for CRUD > > That seems to do the trick - now, where do we apply the fix? :-) > > Well, ideally this would be a feature request in Forge to support a new type > of a REST resource. But a couple of modified lines might not warrant it. > > It would be better to treat this as a flag to be enabled during REST resource > scaffolding. It would allow users to choose how the resource behaves - > * send a 201 response with Location header, > * send a 201 response with Location header and also a response entity. > > It would most likely be addressed in Forge 2. > > > > > On Dec 16, 2013, at 3:06 PM, Vineet Reynolds Pereira < vpereira at redhat.com > > wrote: > > > > > > > ----- Original Message ----- > > > From: "Lucas Holmquist" < lholmqui at redhat.com > > To: "AeroGear Developer Mailing List" < aerogear-dev at lists.jboss.org > > Cc: "Vineet Reynolds Pereira" < vpereira at redhat.com > > Sent: Tuesday, December 17, 2013 12:53:25 AM > Subject: Re: [aerogear-dev] Aerogear.js for CRUD > > > On Dec 16, 2013, at 1:52 PM, Burr Sutter < bsutter at redhat.com > wrote: > > > > Adding Vineet as he has spent time on the Forge REST scaffolding. > > On Dec 16, 2013, at 7:01 AM, Sebastien Blanc < scm.blanc at gmail.com > wrote: > > > > Burr, > I've added some logs statements on the client and basically it seems it > can not parse the response from the server : > > I/Web Console( 1386): textStatus: parsererror at > file:///android_asset/www/js/index.js:103 > I/Web Console( 1386): error: SyntaxError: Unexpected end of input at > file:///android_asset/www/js/index.js:104 > > If I do a CURL like this : > curl -v -b cookies.txt -c cookies.txt -H "Accept: application/json" -H > "Content-type: application/json" -X POST -d > '{"phoneNumber":"1234567890","email":" newTest at test.com ","name":"newTest"}' > http://agmobile-html5.rhcloud.com/rest/forge/members > > I should have pointed to the sources to the REST endpoint: > https://github.com/burrsutter/agmobile/blob/master/src/main/java/com/burrsutter/agmobile/rest/MemberEndpoint.java > This was generated by Forge as I am too lazy to type up a full CRUD REST > endpoint myself :-) > > > > I got an correct answer but the content type is 'text/plain' , please > check your rest endpoint to be sure it's producing json as output, that > should solve your issue. > It says > @POST > @Consumes("application/json") > > needs a @Produces("application/json") > > I'm not sure that will help. The response is a HTTP 201 with a Location > header. > Is the client expecting an entity of type application/json in the response ? > > If yes, then the method should look like: > > @POST > @Consumes("application/json") > public Response create(MemberDTO dto) > { > Member entity = dto.fromDTO(null, em); > em.persist(entity); > return > Response.created(UriBuilder.fromResource(MemberEndpoint.class).path(String.valueOf(entity.getId())).build()).entity(entity).build(); > } > > I've added : .entity(entity) in the above method to populate the response > with the entity. > > > > > > > > > > > Could you also paste the commands you used in Forge to scaffold the REST > endpoints so that we can check there hasn't been an incompatibility > introduced ? > I just used the Forge Wizard that is built into JBDS/Tools > http://screencast.com/t/QrKkCoFZMUn > > error.status is 201 > error.responseText is blank > > > > > > > > On Sat, Dec 14, 2013 at 6:06 PM, Burr Sutter < bsutter at redhat.com > wrote: > I am having a problem with pipe.save(), likely user error :-) > > For some reason, the POST is occurring, the save seems to work but the > error callback is invoked, not the success method. > > And I am doing all of this in the context of our tooling which has some > limitations (auto-closing console/firebug lite) > > http://screencast.com/t/gosd7Qnhz > > REST endpoint: > http://agmobile-html5.rhcloud.com/rest/forge/members > Use of Forge, with the Member.java entity to offer full CRUD capabilities > > Sources: > https://github.com/burrsutter/AGContacts/blob/master/www/js/index.js > > > _______________________________________________ > 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 > _______________________________________________ > forge-dev mailing list > forge-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev > > > _______________________________________________ > forge-dev mailing list > forge-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > -- > Lincoln Baxter, III > http://ocpsoft.org > "Simpler is better." > > _______________________________________________ > forge-dev mailing list > forge-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > _______________________________________________ > forge-dev mailing list forge-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev > > _______________________________________________ > forge-dev mailing list > forge-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev > > > _______________________________________________ > forge-dev mailing list > forge-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev From jbalunas at redhat.com Tue Dec 17 10:05:22 2013 From: jbalunas at redhat.com (Jay Balunas) Date: Tue, 17 Dec 2013 10:05:22 -0500 Subject: [aerogear-dev] [forge-dev] Aerogear.js for CRUD In-Reply-To: <2032951163.40864303.1387291430377.JavaMail.root@redhat.com> References: <1928607956.40560513.1387229153309.JavaMail.root@redhat.com> <52B0187A.9020903@redhat.com> <98682D8D-478E-4D4E-87FE-C4F08B4F67AF@redhat.com> <2032951163.40864303.1387291430377.JavaMail.root@redhat.com> Message-ID: On Dec 17, 2013, at 9:43 AM, Vineet Reynolds Pereira wrote: > > > ----- Original Message ----- >> From: "Lucas Holmquist" >> To: "forge-dev List" >> Cc: aerogear-dev at lists.jboss.org >> Sent: Tuesday, December 17, 2013 6:59:10 PM >> Subject: Re: [forge-dev] [aerogear-dev] Aerogear.js for CRUD >> >> >> On Dec 17, 2013, at 4:25 AM, Sebastien Blanc < sblanc at redhat.com > wrote: >> >> >> >> >> Adding again aerogear list. >> I think that we must discuss with the team (aerogear) on how we can/must >> handle a proper 201 response. >> >> i don't see this as a client issue at all. jQuery ajax is used under the hood >> here and it is handling the 201 fine, but it is choking on parsing the >> response since it is not in the correct format, thus calling back in the >> error callback. > > Ah, you mean this problem: > > http://jquery.com/upgrade-guide/1.9/#jquery-ajax-returning-a-json-result-of-an-empty-string > > This would definitely require the server to not send empty responses when the client expects JSON. So in this case, with jQuery 1.9+ what is the best way for the us to handle this. Is this a chance in AeroGear.js to help handle this situation, or do we need to make sure the server impls reply with content, even with a 201? > >> >> this should really be handled on the server >> >> >> >> >> >> On 12/17/2013 09:58 AM, Ivan St. Ivanov wrote: >> >> >> >> Hi! >> >> I think that the 'right' approach is to respond with 201 (created) and return >> a URI to the newly created resource. >> >> Cheers, >> Ivan >> >> >> On Tue, Dec 17, 2013 at 12:58 AM, Lincoln Baxter, III < >> lincolnbaxter at gmail.com > wrote: >> >> >> >> Either is typical, but I think that most "pure" restifarians would favor the >> 201. >> >> >> On Mon, Dec 16, 2013 at 5:41 PM, Burr Sutter < bsutter at redhat.com > wrote: >> >> >> >> I need to find my REST bible - what is typical to respond to the POST with >> the JSON-serialized entity that was originally POST'd or to simply respond >> with a basic acknowledgement (http 201)? >> >> >> On Dec 16, 2013, at 4:25 PM, Vineet Reynolds Pereira < vpereira at redhat.com > >> wrote: >> >> >> >> >> Adding forge-dev. >> >> ----- Original Message ----- >> >> >> From: "Burr Sutter" < bsutter at redhat.com > >> To: "AeroGear Developer Mailing List" < aerogear-dev at lists.jboss.org > >> Sent: Tuesday, December 17, 2013 1:59:41 AM >> Subject: Re: [aerogear-dev] Aerogear.js for CRUD >> >> That seems to do the trick - now, where do we apply the fix? :-) >> >> Well, ideally this would be a feature request in Forge to support a new type >> of a REST resource. But a couple of modified lines might not warrant it. >> >> It would be better to treat this as a flag to be enabled during REST resource >> scaffolding. It would allow users to choose how the resource behaves - >> * send a 201 response with Location header, >> * send a 201 response with Location header and also a response entity. >> >> It would most likely be addressed in Forge 2. >> >> >> >> >> On Dec 16, 2013, at 3:06 PM, Vineet Reynolds Pereira < vpereira at redhat.com > >> wrote: >> >> >> >> >> >> >> ----- Original Message ----- >> >> >> From: "Lucas Holmquist" < lholmqui at redhat.com > >> To: "AeroGear Developer Mailing List" < aerogear-dev at lists.jboss.org > >> Cc: "Vineet Reynolds Pereira" < vpereira at redhat.com > >> Sent: Tuesday, December 17, 2013 12:53:25 AM >> Subject: Re: [aerogear-dev] Aerogear.js for CRUD >> >> >> On Dec 16, 2013, at 1:52 PM, Burr Sutter < bsutter at redhat.com > wrote: >> >> >> >> Adding Vineet as he has spent time on the Forge REST scaffolding. >> >> On Dec 16, 2013, at 7:01 AM, Sebastien Blanc < scm.blanc at gmail.com > wrote: >> >> >> >> Burr, >> I've added some logs statements on the client and basically it seems it >> can not parse the response from the server : >> >> I/Web Console( 1386): textStatus: parsererror at >> file:///android_asset/www/js/index.js:103 >> I/Web Console( 1386): error: SyntaxError: Unexpected end of input at >> file:///android_asset/www/js/index.js:104 >> >> If I do a CURL like this : >> curl -v -b cookies.txt -c cookies.txt -H "Accept: application/json" -H >> "Content-type: application/json" -X POST -d >> '{"phoneNumber":"1234567890","email":" newTest at test.com ","name":"newTest"}' >> http://agmobile-html5.rhcloud.com/rest/forge/members >> >> I should have pointed to the sources to the REST endpoint: >> https://github.com/burrsutter/agmobile/blob/master/src/main/java/com/burrsutter/agmobile/rest/MemberEndpoint.java >> This was generated by Forge as I am too lazy to type up a full CRUD REST >> endpoint myself :-) >> >> >> >> I got an correct answer but the content type is 'text/plain' , please >> check your rest endpoint to be sure it's producing json as output, that >> should solve your issue. >> It says >> @POST >> @Consumes("application/json") >> >> needs a @Produces("application/json") >> >> I'm not sure that will help. The response is a HTTP 201 with a Location >> header. >> Is the client expecting an entity of type application/json in the response ? >> >> If yes, then the method should look like: >> >> @POST >> @Consumes("application/json") >> public Response create(MemberDTO dto) >> { >> Member entity = dto.fromDTO(null, em); >> em.persist(entity); >> return >> Response.created(UriBuilder.fromResource(MemberEndpoint.class).path(String.valueOf(entity.getId())).build()).entity(entity).build(); >> } >> >> I've added : .entity(entity) in the above method to populate the response >> with the entity. >> >> >> >> >> >> >> >> >> >> >> Could you also paste the commands you used in Forge to scaffold the REST >> endpoints so that we can check there hasn't been an incompatibility >> introduced ? >> I just used the Forge Wizard that is built into JBDS/Tools >> http://screencast.com/t/QrKkCoFZMUn >> >> error.status is 201 >> error.responseText is blank >> >> >> >> >> >> >> >> On Sat, Dec 14, 2013 at 6:06 PM, Burr Sutter < bsutter at redhat.com > wrote: >> I am having a problem with pipe.save(), likely user error :-) >> >> For some reason, the POST is occurring, the save seems to work but the >> error callback is invoked, not the success method. >> >> And I am doing all of this in the context of our tooling which has some >> limitations (auto-closing console/firebug lite) >> >> http://screencast.com/t/gosd7Qnhz >> >> REST endpoint: >> http://agmobile-html5.rhcloud.com/rest/forge/members >> Use of Forge, with the Member.java entity to offer full CRUD capabilities >> >> Sources: >> https://github.com/burrsutter/AGContacts/blob/master/www/js/index.js >> >> >> _______________________________________________ >> 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 >> _______________________________________________ >> forge-dev mailing list >> forge-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/forge-dev >> >> >> _______________________________________________ >> forge-dev mailing list >> forge-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/forge-dev >> >> >> >> -- >> Lincoln Baxter, III >> http://ocpsoft.org >> "Simpler is better." >> >> _______________________________________________ >> forge-dev mailing list >> forge-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/forge-dev >> >> >> >> _______________________________________________ >> forge-dev mailing list forge-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/forge-dev >> >> _______________________________________________ >> forge-dev mailing list >> forge-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/forge-dev >> >> >> _______________________________________________ >> forge-dev mailing list >> forge-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/forge-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/20131217/2b73d90b/attachment.html From vpereira at redhat.com Tue Dec 17 10:57:31 2013 From: vpereira at redhat.com (Vineet Reynolds Pereira) Date: Tue, 17 Dec 2013 10:57:31 -0500 (EST) Subject: [aerogear-dev] [forge-dev] Aerogear.js for CRUD In-Reply-To: References: <52B0187A.9020903@redhat.com> <98682D8D-478E-4D4E-87FE-C4F08B4F67AF@redhat.com> <2032951163.40864303.1387291430377.JavaMail.root@redhat.com> Message-ID: <262480495.40914157.1387295851386.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Jay Balunas" > To: "AeroGear Developer Mailing List" > Cc: "forge-dev List" > Sent: Tuesday, December 17, 2013 8:35:22 PM > Subject: Re: [aerogear-dev] [forge-dev] Aerogear.js for CRUD > > > On Dec 17, 2013, at 9:43 AM, Vineet Reynolds Pereira < vpereira at redhat.com > > wrote: > > > > > > > ----- Original Message ----- > > > From: "Lucas Holmquist" < lholmqui at redhat.com > > To: "forge-dev List" < forge-dev at lists.jboss.org > > Cc: aerogear-dev at lists.jboss.org > Sent: Tuesday, December 17, 2013 6:59:10 PM > Subject: Re: [forge-dev] [aerogear-dev] Aerogear.js for CRUD > > > On Dec 17, 2013, at 4:25 AM, Sebastien Blanc < sblanc at redhat.com > wrote: > > > > > Adding again aerogear list. > I think that we must discuss with the team (aerogear) on how we can/must > handle a proper 201 response. > > i don't see this as a client issue at all. jQuery ajax is used under the hood > here and it is handling the 201 fine, but it is choking on parsing the > response since it is not in the correct format, thus calling back in the > error callback. > > Ah, you mean this problem: > > http://jquery.com/upgrade-guide/1.9/#jquery-ajax-returning-a-json-result-of-an-empty-string > > This would definitely require the server to not send empty responses when the > client expects JSON. > > So in this case, with jQuery 1.9+ what is the best way for the us to handle > this. Is this a chance in AeroGear.js to help handle this situation, or do > we need to make sure the server impls reply with content, even with a 201? I'm not aware of what Aerogear does but the question that would lead to the answer is - Does Aerogear expect that the response contain JSON? The rationale behind jQuery's decision to treat empty responses as errors is - the expected datatype was JSON, and thus an empty response body for a response with content/type application/json is an error. If the AG client expects a JSON response, then I'd agree that the server must not respond with an empty response body. For instance, Backbone.js does this: https://github.com/jashkenas/backbone/blob/master/backbone.js#L1140 and thus the REST API is expected to send JSON in the response body on Model.save(). On the other hand, if the client does not expect a JSON response, then it must not set the datatype when invoking $.ajax(). This may not be practical - Backbone.js doesn't do this and instead allows users to swap in custom Backbone.sync or Backbone.ajax implementations to get around this. I'll try and address this in FORGE-1361 taking this behavior into account. It looks like we need a different type of a REST resource for AG clients. > > > > > > > > > this should really be handled on the server > > > > > > On 12/17/2013 09:58 AM, Ivan St. Ivanov wrote: > > > > Hi! > > I think that the 'right' approach is to respond with 201 (created) and return > a URI to the newly created resource. > > Cheers, > Ivan > > > On Tue, Dec 17, 2013 at 12:58 AM, Lincoln Baxter, III < > lincolnbaxter at gmail.com > wrote: > > > > Either is typical, but I think that most "pure" restifarians would favor the > 201. > > > On Mon, Dec 16, 2013 at 5:41 PM, Burr Sutter < bsutter at redhat.com > wrote: > > > > I need to find my REST bible - what is typical to respond to the POST with > the JSON-serialized entity that was originally POST'd or to simply respond > with a basic acknowledgement (http 201)? > > > On Dec 16, 2013, at 4:25 PM, Vineet Reynolds Pereira < vpereira at redhat.com > > wrote: > > > > > Adding forge-dev. > > ----- Original Message ----- > > > From: "Burr Sutter" < bsutter at redhat.com > > To: "AeroGear Developer Mailing List" < aerogear-dev at lists.jboss.org > > Sent: Tuesday, December 17, 2013 1:59:41 AM > Subject: Re: [aerogear-dev] Aerogear.js for CRUD > > That seems to do the trick - now, where do we apply the fix? :-) > > Well, ideally this would be a feature request in Forge to support a new type > of a REST resource. But a couple of modified lines might not warrant it. > > It would be better to treat this as a flag to be enabled during REST resource > scaffolding. It would allow users to choose how the resource behaves - > * send a 201 response with Location header, > * send a 201 response with Location header and also a response entity. > > It would most likely be addressed in Forge 2. > > > > > On Dec 16, 2013, at 3:06 PM, Vineet Reynolds Pereira < vpereira at redhat.com > > wrote: > > > > > > > ----- Original Message ----- > > > From: "Lucas Holmquist" < lholmqui at redhat.com > > To: "AeroGear Developer Mailing List" < aerogear-dev at lists.jboss.org > > Cc: "Vineet Reynolds Pereira" < vpereira at redhat.com > > Sent: Tuesday, December 17, 2013 12:53:25 AM > Subject: Re: [aerogear-dev] Aerogear.js for CRUD > > > On Dec 16, 2013, at 1:52 PM, Burr Sutter < bsutter at redhat.com > wrote: > > > > Adding Vineet as he has spent time on the Forge REST scaffolding. > > On Dec 16, 2013, at 7:01 AM, Sebastien Blanc < scm.blanc at gmail.com > wrote: > > > > Burr, > I've added some logs statements on the client and basically it seems it > can not parse the response from the server : > > I/Web Console( 1386): textStatus: parsererror at > file:///android_asset/www/js/index.js:103 > I/Web Console( 1386): error: SyntaxError: Unexpected end of input at > file:///android_asset/www/js/index.js:104 > > If I do a CURL like this : > curl -v -b cookies.txt -c cookies.txt -H "Accept: application/json" -H > "Content-type: application/json" -X POST -d > '{"phoneNumber":"1234567890","email":" newTest at test.com ","name":"newTest"}' > http://agmobile-html5.rhcloud.com/rest/forge/members > > I should have pointed to the sources to the REST endpoint: > https://github.com/burrsutter/agmobile/blob/master/src/main/java/com/burrsutter/agmobile/rest/MemberEndpoint.java > This was generated by Forge as I am too lazy to type up a full CRUD REST > endpoint myself :-) > > > > I got an correct answer but the content type is 'text/plain' , please > check your rest endpoint to be sure it's producing json as output, that > should solve your issue. > It says > @POST > @Consumes("application/json") > > needs a @Produces("application/json") > > I'm not sure that will help. The response is a HTTP 201 with a Location > header. > Is the client expecting an entity of type application/json in the response ? > > If yes, then the method should look like: > > @POST > @Consumes("application/json") > public Response create(MemberDTO dto) > { > Member entity = dto.fromDTO(null, em); > em.persist(entity); > return > Response.created(UriBuilder.fromResource(MemberEndpoint.class).path(String.valueOf(entity.getId())).build()).entity(entity).build(); > } > > I've added : .entity(entity) in the above method to populate the response > with the entity. > > > > > > > > > > > Could you also paste the commands you used in Forge to scaffold the REST > endpoints so that we can check there hasn't been an incompatibility > introduced ? > I just used the Forge Wizard that is built into JBDS/Tools > http://screencast.com/t/QrKkCoFZMUn > > error.status is 201 > error.responseText is blank > > > > > > > > On Sat, Dec 14, 2013 at 6:06 PM, Burr Sutter < bsutter at redhat.com > wrote: > I am having a problem with pipe.save(), likely user error :-) > > For some reason, the POST is occurring, the save seems to work but the > error callback is invoked, not the success method. > > And I am doing all of this in the context of our tooling which has some > limitations (auto-closing console/firebug lite) > > http://screencast.com/t/gosd7Qnhz > > REST endpoint: > http://agmobile-html5.rhcloud.com/rest/forge/members > Use of Forge, with the Member.java entity to offer full CRUD capabilities > > Sources: > https://github.com/burrsutter/AGContacts/blob/master/www/js/index.js > > > _______________________________________________ > 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 > _______________________________________________ > forge-dev mailing list > forge-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev > > > _______________________________________________ > forge-dev mailing list > forge-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > -- > Lincoln Baxter, III > http://ocpsoft.org > "Simpler is better." > > _______________________________________________ > forge-dev mailing list > forge-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > _______________________________________________ > forge-dev mailing list forge-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev > > _______________________________________________ > forge-dev mailing list > forge-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev > > > _______________________________________________ > forge-dev mailing list > forge-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-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 daniel at passos.me Wed Dec 18 04:26:50 2013 From: daniel at passos.me (Daniel Passos) Date: Wed, 18 Dec 2013 07:26:50 -0200 Subject: [aerogear-dev] AeroGear Android Root Document In-Reply-To: <6B6E85E9-60D5-49C2-BC64-E5E41CB2A8E1@gmail.com> References: <19FA4209-6688-43C5-9153-757EE34E9F4A@gmail.com> <6B6E85E9-60D5-49C2-BC64-E5E41CB2A8E1@gmail.com> Message-ID: After a lot of drafts: The Root Document ideia:?https://gist.github.com/danielpassos/4b4e694c1c71473b4f59 The README example:?https://gist.github.com/danielpassos/2fe51449fc5547b3e65f wdyt? --? Daniel Passos On December 13, 2013 at 1:41:00 PM, Corinne Krych (corinnekrych at gmail.com) wrote: On Dec 13, 2013, at 4:05 PM, Daniel Passos wrote: > Well, That is what we have today and what we want to follow > > Android Documentations > > Root document > > A documentation explain how to build lib and app > > README > > A link for root document and add specific things for conf/run app > > Usage Guide > > For each feature we have a document explaining how to use it on the site. We don?t add any explanation of how to use a feature in the README > > Cookbook > > We have only one app to show for community see how to our feature works. We have one activity per usage guide Because of the nature of iOS app, we use storyboard (no UI code) so we can concentrate on AG app code. We add a bit of fun by defining 'fun' app. I think we don't have to stick exactly to the same for the recipes. Both ways are fine, one single objective: demo AG code, straight to the point. > > Feature table > > I love corinne idea for put table feature on README but I like to move it for ag lib instead cookbook Agreed We could move this table in web site documetation and add a link on cookbook readme to it. https://issues.jboss.org/browse/AGIOS-141 Once you've completed your Android documentation, we can start iOS one and stick close to yours for the template. > > > > On Fri, Dec 13, 2013 at 12:33 PM, Daniel Passos wrote: > On Tue, Dec 10, 2013 at 6:00 AM, Corinne Krych wrote: > > > > Hello Daniel > > I really buy into your idea. > We definitively need more consistent documentation on AeroGear features with concrete and simple exemple (like we started in cookbook). > > > The idea is clean up our documentation, write a UNIQUE document explaining how to build our lib and apps. Looks like ActionBarSherlock > > ? Prereq > ? Build > ? Usage > In all README we will link for this document (on ag.org) and add specific things for the app > > > > Let's refactor our documentation together and meake suure we go in the same direction. > See Hylke thread on it [1]. As suggested by Hylke, let's group our documentation per category/features: core, push, security, offline/sync. We could have a general description of what the features is, some link to specs etc.. > > > +1 for reorganize this > > > > Then the sample part. Each sample/recipe(from cookbook) should be well documented and follow a similar template like you gist shown it. I've done similar with iOS-cookbook. One central readme [1] which list all recipes. Each recipes [2] has is own documentation following the same template. We ca work on unifying the template. I like prerequisites section, install/build section common to both, you miss a short description of the app and some ui flow with pictures would be nice and then a last sec ion we we explain the main fatures we want ot demo. > > > The root document is not to explain how to use our features. It?s for explain how to build our libs and apps. > > We don?t have one central README and other specific for cookbook looks like iOS, because for Android we have only one cookbook app. This application has all our features. For each feature we have one activity (screen). This makes the explanation very simple and focus on this feature. Each activity (screens) explain one feature and each feature has a usage guide on the ag.org (http://aerogear.org/docs/guides/aerogear-android/)) > > > > A couple of questions on implementation though: > - Instead of just having links to cookbook, how can we embed in asciidoc or markdown? the sample documentation should belong to the cookbook repo. > - How are we going to publish read me info from cookbook into aerogear.org repo? a build or some sort of automation will be good. > > > I think those questions have been answered above. > > ++ > Corinne > [1] http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Website-restructure-td5246.html > [1] https://github.com/corinnekrych/aerogear-ios-cookbook/blob/master/README.md > [2] https://github.com/corinnekrych/aerogear-ios-cookbook/blob/master/Xmas/Xmas.md > > On Dec 9, 2013, at 11:20 PM, Daniel Passos wrote: > > > Summers and I tossed around the idea last week to create a 'root document' how to build AeroGear android lib and apps. > > > > The idea is write a simple document that looks like ActionBar Sherlock doc instead of having a huge doc with lots of repeated setup, have a setup docs which branch from there > > > > Publish it on aerogear.org and link all others (like README) with it > > > > My draft for it is here: https://gist.github.com/danielpassos/4b4e694c1c71473b4f59 > > > > wdyt? > > > > -- Daniel Passos > > > > _______________________________________________ > > 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/20131218/46088ffe/attachment.html From corinnekrych at gmail.com Wed Dec 18 04:34:32 2013 From: corinnekrych at gmail.com (Corinne Krych) Date: Wed, 18 Dec 2013 10:34:32 +0100 Subject: [aerogear-dev] AeroGear Android Root Document In-Reply-To: References: <19FA4209-6688-43C5-9153-757EE34E9F4A@gmail.com> <6B6E85E9-60D5-49C2-BC64-E5E41CB2A8E1@gmail.com> Message-ID: <60342CD1-4350-40B0-A4E1-784CC8C3ED14@gmail.com> In your build instruction since you're mentioning Gradle in the Usage section and not any more in the Build section, I think it will be nice to add a note saying about Gradle usage and how it is supported (or not) in AG. Format looks good to me. Table of demo apps +1 ++ Corinne On Dec 18, 2013, at 10:26 AM, Daniel Passos wrote: > After a lot of drafts: > > The Root Document ideia: https://gist.github.com/danielpassos/4b4e694c1c71473b4f59 > The README example: https://gist.github.com/danielpassos/2fe51449fc5547b3e65f > > wdyt? > > -- > Daniel Passos > > > On December 13, 2013 at 1:41:00 PM, Corinne Krych (corinnekrych at gmail.com) wrote: > >> >> On Dec 13, 2013, at 4:05 PM, Daniel Passos wrote: >> >> > Well, That is what we have today and what we want to follow >> > >> > Android Documentations >> > >> > Root document >> > >> > A documentation explain how to build lib and app >> > >> > README >> > >> > A link for root document and add specific things for conf/run app >> > >> > Usage Guide >> > >> > For each feature we have a document explaining how to use it on the site. We don?t add any explanation of how to use a feature in the README >> > >> > Cookbook >> > >> > We have only one app to show for community see how to our feature works. We have one activity per usage guide >> >> Because of the nature of iOS app, we use storyboard (no UI code) so we can concentrate on AG app code. >> We add a bit of fun by defining 'fun' app. >> I think we don't have to stick exactly to the same for the recipes. Both ways are fine, one single objective: demo AG code, straight to the point. >> >> > >> > Feature table >> > >> > I love corinne idea for put table feature on README but I like to move it for ag lib instead cookbook >> >> Agreed >> We could move this table in web site documetation and add a link on cookbook readme to it. >> https://issues.jboss.org/browse/AGIOS-141 >> Once you've completed your Android documentation, we can start iOS one and stick close to yours for the template. >> >> > >> > >> > >> > On Fri, Dec 13, 2013 at 12:33 PM, Daniel Passos wrote: >> > On Tue, Dec 10, 2013 at 6:00 AM, Corinne Krych wrote: >> > >> > >> > >> > Hello Daniel >> > >> > I really buy into your idea. >> > We definitively need more consistent documentation on AeroGear features with concrete and simple exemple (like we started in cookbook). >> > >> > >> > The idea is clean up our documentation, write a UNIQUE document explaining how to build our lib and apps. Looks like ActionBarSherlock >> > >> > ? Prereq >> > ? Build >> > ? Usage >> > In all README we will link for this document (on ag.org) and add specific things for the app >> > >> > >> > >> > Let's refactor our documentation together and meake suure we go in the same direction. >> > See Hylke thread on it [1]. As suggested by Hylke, let's group our documentation per category/features: core, push, security, offline/sync. We could have a general description of what the features is, some link to specs etc.. >> > >> > >> > +1 for reorganize this >> > >> > >> > >> > Then the sample part. Each sample/recipe(from cookbook) should be well documented and follow a similar template like you gist shown it. I've done similar with iOS-cookbook. One central readme [1] which list all recipes. Each recipes [2] has is own documentation following the same template. We ca work on unifying the template. I like prerequisites section, install/build section common to both, you miss a short description of the app and some ui flow with pictures would be nice and then a last sec ion we we explain the main fatures we want ot demo. >> > >> > >> > The root document is not to explain how to use our features. It?s for explain how to build our libs and apps. >> > >> > We don?t have one central README and other specific for cookbook looks like iOS, because for Android we have only one cookbook app. This application has all our features. For each feature we have one activity (screen). This makes the explanation very simple and focus on this feature. Each activity (screens) explain one feature and each feature has a usage guide on the ag.org (http://aerogear.org/docs/guides/aerogear-android/)) >> > >> > >> > >> > A couple of questions on implementation though: >> > - Instead of just having links to cookbook, how can we embed in asciidoc or markdown? the sample documentation should belong to the cookbook repo. >> > - How are we going to publish read me info from cookbook into aerogear.org repo? a build or some sort of automation will be good. >> > >> > >> > I think those questions have been answered above. >> > >> > ++ >> > Corinne >> > [1] http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Website-restructure-td5246.html >> > [1] https://github.com/corinnekrych/aerogear-ios-cookbook/blob/master/README.md >> > [2] https://github.com/corinnekrych/aerogear-ios-cookbook/blob/master/Xmas/Xmas.md >> > >> > On Dec 9, 2013, at 11:20 PM, Daniel Passos wrote: >> > >> > > Summers and I tossed around the idea last week to create a 'root document' how to build AeroGear android lib and apps. >> > > >> > > The idea is write a simple document that looks like ActionBar Sherlock doc instead of having a huge doc with lots of repeated setup, have a setup docs which branch from there >> > > >> > > Publish it on aerogear.org and link all others (like README) with it >> > > >> > > My draft for it is here: https://gist.github.com/danielpassos/4b4e694c1c71473b4f59 >> > > >> > > wdyt? >> > > >> > > -- Daniel Passos >> > > >> > > _______________________________________________ >> > > 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 From daniel at passos.me Wed Dec 18 04:57:13 2013 From: daniel at passos.me (Daniel Passos) Date: Wed, 18 Dec 2013 07:57:13 -0200 Subject: [aerogear-dev] AeroGear Android Root Document In-Reply-To: <60342CD1-4350-40B0-A4E1-784CC8C3ED14@gmail.com> References: <19FA4209-6688-43C5-9153-757EE34E9F4A@gmail.com> <6B6E85E9-60D5-49C2-BC64-E5E41CB2A8E1@gmail.com> <60342CD1-4350-40B0-A4E1-784CC8C3ED14@gmail.com> Message-ID: Well, the AG Lib is a maven project so for build it you have only one option: Maven. We?ll start ship AG lib in 2 diferents formats - apklibto using in your maven project - aar (as experimental) to using in your gradle project -- Daniel Passos On December 18, 2013 at 7:34:52 AM, Corinne Krych (corinnekrych at gmail.com) wrote: In your build instruction since you're mentioning Gradle in the Usage section and not any more in the Build section, I think it will be nice to add a note saying about Gradle usage and how it is supported (or not) in AG. Format looks good to me. Table of demo apps +1 ++ Corinne On Dec 18, 2013, at 10:26 AM, Daniel Passos wrote: > After a lot of drafts: > > The Root Document ideia: https://gist.github.com/danielpassos/4b4e694c1c71473b4f59 > The README example: https://gist.github.com/danielpassos/2fe51449fc5547b3e65f > > wdyt? > > -- > Daniel Passos > > > On December 13, 2013 at 1:41:00 PM, Corinne Krych (corinnekrych at gmail.com) wrote: > >> >> On Dec 13, 2013, at 4:05 PM, Daniel Passos wrote: >> >> > Well, That is what we have today and what we want to follow >> > >> > Android Documentations >> > >> > Root document >> > >> > A documentation explain how to build lib and app >> > >> > README >> > >> > A link for root document and add specific things for conf/run app >> > >> > Usage Guide >> > >> > For each feature we have a document explaining how to use it on the site. We don?t add any explanation of how to use a feature in the README >> > >> > Cookbook >> > >> > We have only one app to show for community see how to our feature works. We have one activity per usage guide >> >> Because of the nature of iOS app, we use storyboard (no UI code) so we can concentrate on AG app code. >> We add a bit of fun by defining 'fun' app. >> I think we don't have to stick exactly to the same for the recipes. Both ways are fine, one single objective: demo AG code, straight to the point. >> >> > >> > Feature table >> > >> > I love corinne idea for put table feature on README but I like to move it for ag lib instead cookbook >> >> Agreed >> We could move this table in web site documetation and add a link on cookbook readme to it. >> https://issues.jboss.org/browse/AGIOS-141 >> Once you've completed your Android documentation, we can start iOS one and stick close to yours for the template. >> >> > >> > >> > >> > On Fri, Dec 13, 2013 at 12:33 PM, Daniel Passos wrote: >> > On Tue, Dec 10, 2013 at 6:00 AM, Corinne Krych wrote: >> > >> > >> > >> > Hello Daniel >> > >> > I really buy into your idea. >> > We definitively need more consistent documentation on AeroGear features with concrete and simple exemple (like we started in cookbook). >> > >> > >> > The idea is clean up our documentation, write a UNIQUE document explaining how to build our lib and apps. Looks like ActionBarSherlock >> > >> > ? Prereq >> > ? Build >> > ? Usage >> > In all README we will link for this document (on ag.org) and add specific things for the app >> > >> > >> > >> > Let's refactor our documentation together and meake suure we go in the same direction. >> > See Hylke thread on it [1]. As suggested by Hylke, let's group our documentation per category/features: core, push, security, offline/sync. We could have a general description of what the features is, some link to specs etc.. >> > >> > >> > +1 for reorganize this >> > >> > >> > >> > Then the sample part. Each sample/recipe(from cookbook) should be well documented and follow a similar template like you gist shown it. I've done similar with iOS-cookbook. One central readme [1] which list all recipes. Each recipes [2] has is own documentation following the same template. We ca work on unifying the template. I like prerequisites section, install/build section common to both, you miss a short description of the app and some ui flow with pictures would be nice and then a last sec ion we we explain the main fatures we want ot demo. >> > >> > >> > The root document is not to explain how to use our features. It?s for explain how to build our libs and apps. >> > >> > We don?t have one central README and other specific for cookbook looks like iOS, because for Android we have only one cookbook app. This application has all our features. For each feature we have one activity (screen). This makes the explanation very simple and focus on this feature. Each activity (screens) explain one feature and each feature has a usage guide on the ag.org (http://aerogear.org/docs/guides/aerogear-android/)) >> > >> > >> > >> > A couple of questions on implementation though: >> > - Instead of just having links to cookbook, how can we embed in asciidoc or markdown? the sample documentation should belong to the cookbook repo. >> > - How are we going to publish read me info from cookbook into aerogear.org repo? a build or some sort of automation will be good. >> > >> > >> > I think those questions have been answered above. >> > >> > ++ >> > Corinne >> > [1] http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Website-restructure-td5246.html >> > [1] https://github.com/corinnekrych/aerogear-ios-cookbook/blob/master/README.md >> > [2] https://github.com/corinnekrych/aerogear-ios-cookbook/blob/master/Xmas/Xmas.md >> > >> > On Dec 9, 2013, at 11:20 PM, Daniel Passos wrote: >> > >> > > Summers and I tossed around the idea last week to create a 'root document' how to build AeroGear android lib and apps. >> > > >> > > The idea is write a simple document that looks like ActionBar Sherlock doc instead of having a huge doc with lots of repeated setup, have a setup docs which branch from there >> > > >> > > Publish it on aerogear.org and link all others (like README) with it >> > > >> > > My draft for it is here: https://gist.github.com/danielpassos/4b4e694c1c71473b4f59 >> > > >> > > wdyt? >> > > >> > > -- Daniel Passos >> > > >> > > _______________________________________________ >> > > 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/20131218/2abca639/attachment-0001.html From bruno at abstractj.org Wed Dec 18 05:46:33 2013 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 18 Dec 2013 08:46:33 -0200 Subject: [aerogear-dev] AeroGear Security and AeroGear Crypto on Staging In-Reply-To: References: Message-ID: Released on Nexus. On Tue, Dec 17, 2013 at 12:01 AM, Bruno Oliveira wrote: > Good morning slackland, the sun is not shining yet, but I know you are > more anxious than a kid waiting in long lines to take a pic with Santa to > see the next release of AG Security. So there we go: > > AeroGear Security / AeroGear Security Picketlink 1.3.0 > > - Password reset feature (https://issues.jboss.org/browse/AGSEC-161). > Thanks Sebastien for helping me with the integration of the feature into > the UPS. > - Upgrade to PicketLink 2.5.2.Final > > AeroGear Crypto Java 0.1.1 > - Message authentication support ( > https://issues.jboss.org/browse/AGSEC-119) > - AG Crypto Java will raise ClassNotFoundException for non Android > projects (https://issues.jboss.org/browse/AGSEC-160) > > The repository was staged under > https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-2290/. > I?m planning to release it on Wednesday so, feel free to test and provide > some feedback. > > -- > abstractj > -- -- "The measure of a man is what he does with power" - Plato - @abstractj - Volenti Nihil Difficile -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20131218/91a76f6a/attachment.html From scm.blanc at gmail.com Wed Dec 18 05:52:30 2013 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Wed, 18 Dec 2013 11:52:30 +0100 Subject: [aerogear-dev] AeroGear Security and AeroGear Crypto on Staging In-Reply-To: References: Message-ID: Nice ! On Wed, Dec 18, 2013 at 11:46 AM, Bruno Oliveira wrote: > Released on Nexus. > > > On Tue, Dec 17, 2013 at 12:01 AM, Bruno Oliveira wrote: > >> Good morning slackland, the sun is not shining yet, but I know you are >> more anxious than a kid waiting in long lines to take a pic with Santa to >> see the next release of AG Security. So there we go: >> >> AeroGear Security / AeroGear Security Picketlink 1.3.0 >> >> - Password reset feature (https://issues.jboss.org/browse/AGSEC-161). >> Thanks Sebastien for helping me with the integration of the feature into >> the UPS. >> - Upgrade to PicketLink 2.5.2.Final >> >> AeroGear Crypto Java 0.1.1 >> - Message authentication support ( >> https://issues.jboss.org/browse/AGSEC-119) >> - AG Crypto Java will raise ClassNotFoundException for non Android >> projects (https://issues.jboss.org/browse/AGSEC-160) >> >> The repository was staged under >> https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-2290/. >> I?m planning to release it on Wednesday so, feel free to test and provide >> some feedback. >> >> -- >> abstractj >> > > > > -- > > -- > "The measure of a man is what he does with power" - Plato > - > @abstractj > - > Volenti Nihil Difficile > > _______________________________________________ > 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/20131218/94b975c5/attachment.html From kpiwko at redhat.com Wed Dec 18 10:40:38 2013 From: kpiwko at redhat.com (Karel Piwko) Date: Wed, 18 Dec 2013 16:40:38 +0100 Subject: [aerogear-dev] AeroGear Security and AeroGear Crypto on Staging In-Reply-To: References: Message-ID: <20131218164038.3575d07a@kapy-ntb-x220> FYI Tadeas did a verification of crypto part yesterday, no issues were found. Karel On Tue, 17 Dec 2013 00:01:58 -0200 Bruno Oliveira wrote: > Good morning slackland, the sun is not shining yet, but I know you are more > anxious than a kid waiting in long lines to take a pic with Santa to see the > next release of AG Security. So there we go: > > AeroGear Security / AeroGear Security Picketlink 1.3.0 > > - Password reset feature (https://issues.jboss.org/browse/AGSEC-161). Thanks > Sebastien for helping me with the integration of the feature into the UPS. > - Upgrade to PicketLink 2.5.2.Final > > AeroGear Crypto Java 0.1.1 > - Message authentication support (https://issues.jboss.org/browse/AGSEC-119) > - AG Crypto Java will raise ClassNotFoundException for non Android projects > (https://issues.jboss.org/browse/AGSEC-160) > > The repository was staged > under?https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-2290/. > I?m planning to release it on Wednesday so, feel free to test and provide > some feedback. > > -- > abstractj > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From kpiwko at redhat.com Wed Dec 18 10:47:33 2013 From: kpiwko at redhat.com (Karel Piwko) Date: Wed, 18 Dec 2013 16:47:33 +0100 Subject: [aerogear-dev] Aerogear.js for CRUD In-Reply-To: <1928607956.40560513.1387229153309.JavaMail.root@redhat.com> References: <504FFE44-06CE-4C05-A8A6-D049D2D41E00@redhat.com> <1445599908.40527893.1387224418368.JavaMail.root@redhat.com> <1928607956.40560513.1387229153309.JavaMail.root@redhat.com> Message-ID: <20131218164733.43acae54@kapy-ntb-x220> To my understanding, HTTP 201 should always return created entity and its content should be based on Content-Type header field. See http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html On Mon, 16 Dec 2013 16:25:53 -0500 (EST) Vineet Reynolds Pereira wrote: > It would be better to treat this as a flag to be enabled during REST resource > scaffolding. It would allow users to choose how the resource behaves - > * send a 201 response with Location header, > * send a 201 response with Location header and also a response entity. > From bruno at abstractj.org Wed Dec 18 10:48:30 2013 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 18 Dec 2013 13:48:30 -0200 Subject: [aerogear-dev] AeroGear Security and AeroGear Crypto on Staging In-Reply-To: <20131218164038.3575d07a@kapy-ntb-x220> References: <20131218164038.3575d07a@kapy-ntb-x220> Message-ID: Thanks Karel, next time is possible let me know that you guys want to test. I think what you guys are doing is important and I don?t want my release finger in trouble. -- abstractj On December 18, 2013 at 1:40:46 PM, Karel Piwko (kpiwko at redhat.com) wrote: > > FYI Tadeas did a verification of crypto part yesterday, no issues > were found. > > Karel From tkriz at redhat.com Wed Dec 18 10:51:22 2013 From: tkriz at redhat.com (Tadeas Kriz) Date: Wed, 18 Dec 2013 16:51:22 +0100 Subject: [aerogear-dev] AeroGear Security and AeroGear Crypto on Staging In-Reply-To: References: <20131218164038.3575d07a@kapy-ntb-x220> Message-ID: <953A9AFD-A503-4099-8202-1132C6DA7429@redhat.com> It?s my bad on this. I?ve tested it yesterday and missed the fact that you want to release today, so I?ve postponed sending an email about the testing success for today. I?ll do my best to not let this happen again. ? Tadeas Kriz tkriz at redhat.com On 18 Dec 2013, at 16:48, Bruno Oliveira wrote: > Thanks Karel, next time is possible let me know that you guys want to test. I think what you guys are doing is important and I don?t want my release finger in trouble. > > -- > abstractj > > On December 18, 2013 at 1:40:46 PM, Karel Piwko (kpiwko at redhat.com) wrote: >>> FYI Tadeas did a verification of crypto part yesterday, no issues >> were found. >> >> Karel > From bruno at abstractj.org Wed Dec 18 10:53:28 2013 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 18 Dec 2013 13:53:28 -0200 Subject: [aerogear-dev] AeroGear Security and AeroGear Crypto on Staging In-Reply-To: <20131218164038.3575d07a@kapy-ntb-x220> References: <20131218164038.3575d07a@kapy-ntb-x220> <20131218164038.3575d07a@kapy-ntb-x220> Message-ID: No worries, just let us know and we coordinate.? Thank you Tadeas. -- abstractj On December 18, 2013 at 1:40:46 PM, Karel Piwko (kpiwko at redhat.com) wrote: > > It?s my bad on this. I?ve tested it yesterday and missed the fact > that you want to release today, so I?ve postponed sending an email > about the testing success for today. I?ll do my best to not let > this happen again. From bsutter at redhat.com Wed Dec 18 10:54:42 2013 From: bsutter at redhat.com (Burr Sutter) Date: Wed, 18 Dec 2013 10:54:42 -0500 Subject: [aerogear-dev] Aerogear.js for CRUD In-Reply-To: <20131218164733.43acae54@kapy-ntb-x220> References: <504FFE44-06CE-4C05-A8A6-D049D2D41E00@redhat.com> <1445599908.40527893.1387224418368.JavaMail.root@redhat.com> <1928607956.40560513.1387229153309.JavaMail.root@redhat.com> <20131218164733.43acae54@kapy-ntb-x220> Message-ID: <9588A9EB-BDA3-4D42-B778-396BBED53C2E@redhat.com> It sounds like, at a minimum, we have a bug in the Forge scaffolding to support Aerogear.js My next concern would be that since this "feature" was introduced with jQuery 1.9, it could be that a LOT of the world's REST endpoints are no longer POST compatible with Aerogear.js, nothing to be done about that except to document it well for Aerogear.js when the time to promote it heavily comes up. Aerogear.js doc issues also include confusion of datamanager/store (getting started guide is not clear for when those are needed) and the seemingly missing docs for Pipe. Plus, the first example seen by the end-user should include the use of iteration through the results, not an underscore template which hides some of the details. On Dec 18, 2013, at 10:47 AM, Karel Piwko wrote: > To my understanding, HTTP 201 should always return created entity and its > content should be based on Content-Type header field. > > See http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html > > On Mon, 16 Dec 2013 16:25:53 -0500 (EST) > Vineet Reynolds Pereira wrote: > >> It would be better to treat this as a flag to be enabled during REST resource >> scaffolding. It would allow users to choose how the resource behaves - >> * send a 201 response with Location header, >> * send a 201 response with Location header and also a response entity. >> > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From kpiwko at redhat.com Wed Dec 18 10:55:42 2013 From: kpiwko at redhat.com (Karel Piwko) Date: Wed, 18 Dec 2013 16:55:42 +0100 Subject: [aerogear-dev] AeroGear Security and AeroGear Crypto on Staging In-Reply-To: References: <20131218164038.3575d07a@kapy-ntb-x220> Message-ID: <20131218165542.3ceb2520@kapy-ntb-x220> Thanks Bruno, I'll let you know next time. Karel On Wed, 18 Dec 2013 13:48:30 -0200 Bruno Oliveira wrote: > Thanks Karel, next time is possible let me know that you guys want to test. I > think what you guys are doing is important and I don?t want my release finger > in trouble. > > -- > abstractj > > On December 18, 2013 at 1:40:46 PM, Karel Piwko (kpiwko at redhat.com) wrote: > > > FYI Tadeas did a verification of crypto part yesterday, no issues > > were found. > > > > Karel > From lholmqui at redhat.com Wed Dec 18 14:45:39 2013 From: lholmqui at redhat.com (Lucas Holmquist) Date: Wed, 18 Dec 2013 14:45:39 -0500 Subject: [aerogear-dev] OAuth2 Adapter In-Reply-To: <1A14D527-BD5D-4BB4-83ED-69B69B09625A@redhat.com> References: <1C771957-D239-4BDB-B837-00A4A4E02702@redhat.com> <940734E6-6C13-49E7-B044-753E19300F7C@redhat.com> <2A3B92C8-430C-4BE2-BDCC-FB5867743898@redhat.com> <521B91D9.6040806@abstractj.org> <9A9EB7B1-64E7-40D8-8172-51623EDF2470@redhat.com> <521CD70D.9070502@abstractj.org> <8E6B69AB-3FB4-4486-B40A-7ED3CA7B9B7B@redhat.com> <4C215076-003F-4200-B316-14622036079A@redhat.com> <0EABA5A2-A352-40AD-9A91-2F929C4FE9C4@redhat.com> <0120B639-CA96-4BDD-94AB-5BFC4813BB48@redhat.com> <1A14D527-BD5D-4BB4-83ED-69B69B09625A@redhat.com> Message-ID: i've created a new example here, https://github.com/lholmquist/ag-google-drive that hopefully shows the flow a bit On Aug 29, 2013, at 2:05 PM, Lucas Holmquist wrote: > i did get it to work > On Aug 29, 2013, at 2:04 PM, Sebastien Blanc wrote: > >> This update is really cool, is the pipe test flow working ? >> >> >> On Thu, Aug 29, 2013 at 7:57 PM, Lucas Holmquist wrote: >> i've updated the sample again https://github.com/lholmquist/oauth2test >> >> this time i added a pipe object and used pipe.read to see how the flow would be >> >> >> On Aug 29, 2013, at 11:55 AM, Lucas Holmquist wrote: >> >>> i've updated the sample app with the new flow >>> >>> https://github.com/lholmquist/oauth2test >>> >>> >>> On Aug 29, 2013, at 9:23 AM, Lucas Holmquist wrote: >>> >>>> ok, Kris had some thoughts on a better flow, so i refactored the code a bit and i think i like this way a bit better. >>>> >>>> New Flow - Client Flow - Standalone for now, possible integration with pipes >>>> >>>> First Time - No Access Token stored( in localStorage ) >>>> >>>> User will create the Authorization Object stuff with settings/options >>>> >>>> var thing = AeroGear.Authorization(); >>>> >>>> thing.add({ >>>> name: "coolThing", >>>> settings: { >>>> clientId: "12345.apps.googleusercontent.com", >>>> redirectURL: "http://localhost:8000/redirector.html", >>>> tokenValidationEndpoint: "https://www.googleapis.com/oauth2/v1/tokeninfo", >>>> authEndpoint: "https://accounts.google.com/o/oauth2/auth", >>>> revokeURL: "https://accounts.google.com/o/oauth2/revoke", >>>> scopes: "https://www.googleapis.com/auth/userinfo.profile", >>>> prompt: "force" >>>> } >>>> }); >>>> should have the ability to specify more settings, based on the spec >>>> >>>> The user would then call some method( currently not good names are coming to me, maybe validate ) that takes success and error callbacks. >>>> >>>> thing.services.coolThing.validate({ >>>> success: function( response ){ >>>> console.log( "Should be response from Validating the access token", response ); >>>> }, >>>> error: function( error ) { >>>> //should contain a constructed URL for the user >>>> console.log( "error", error ); >>>> } >>>> }); >>>> Since this is the first time, the error callback will be called and will contain the constructed URL that the user should do the popup redirect dance with to get an access token. >>>> >>>> what "dance" they do is up to the developer >>>> >>>> Once that happens and they have the access token, they would call the validate method again. >>>> >>>> this makes sure that the token they recieved is validated and will also return some other meta data related to the token, like refresh time. >>>> >>>> Once the token has been validated, it will be stored in localStorage and would be accessable with the key of ag-oauth2-whatever_the_client_ID_is . >>>> >>>> so in this example it would be something like: >>>> >>>> ag-oauth2-12345.apps.googleusercontent.com >>>> There is one problem i can see here though. If the user has to applications with the same client ID but different scopes assigned, this would be a problem. That use case could be considered bad practice anyway >>>> >>>> The user can then call the "callService"( yes, again, crappy name ) method to get access to the service they want. >>>> >>>> thing.services.coolThing.callService({ >>>> serviceURL: "https://www.googleapis.com/oauth2/v2/userinfo", >>>> success: function( response ){ >>>> console.log( "Should be the response from the call", response ); >>>> }, >>>> error: function( error ) { >>>> console.log( "error", error ); >>>> } >>>> }); >>>> All these methods would have success/error callbacks. >>>> >>>> Token Expiration >>>> >>>> If the user makes a call to a service, using the callService method, and they recieve an error such as not authorized or token invalid or token expired, I'm thinking we send what the "contructed URL" should be, similar to the validate method described above. >>>> >>>> Since this is a Client Side flow, there is no refresh token, so the client wouldn't be able to refresh the access token without doing the "dance" again. >>>> >>>> >>>> >>>> >>>> On Aug 27, 2013, at 1:57 PM, Lucas Holmquist wrote: >>>> >>>>> i've hacked together a sample app that shows sort of the flow. >>>>> >>>>> https://github.com/lholmquist/oauth2test >>>>> >>>>> it is still very rough >>>>> >>>>> On Aug 27, 2013, at 12:42 PM, Bruno Oliveira wrote: >>>>> >>>>>> +1 keep it simple, please >>>>>> >>>>>> Lucas Holmquist wrote: >>>>>>> >>>>>>> On Aug 27, 2013, at 3:39 AM, Sebastien Blanc >>>>>> > wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> That sounds good ! >>>>>>>> Just one question, instead of using the callApi function couldn't we >>>>>>>> pass the oauth module (called 'thing' in your example) to the pipe >>>>>>>> directly, using the 'authenticator' setting. Behind the scene, the >>>>>>>> pipe manager will append the oauth token to the query or add the >>>>>>>> bearer header ? >>>>>>> >>>>>>> I'm not sure if that is what this is going to do. This is more of an >>>>>>> Authorization thing and i don't think it totally fits the pipeline >>>>>>> stuff. ( or it would make it a bit more complicated, and we want to keep >>>>>>> it simple ) >>>>>>> >>>>>>> >>>>>>> i should probably change the method to be "authorize" instead >>>>>>> >>>>>>>> Seb >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Aug 26, 2013 at 8:05 PM, Lucas Holmquist >>>>>>> > wrote: >>>>>>>> >>>>>>>> >>>>>>>> OAuth2 AeroGear Workflow - High Level >>>>>>>> >>>>>>>> >>>>>>>> Using Google api's >>>>>>>> >>>>>>>> /Server Side/ >>>>>>>> >>>>>>>> 1. user needs to first create an "application/project" to get an >>>>>>>> api key >>>>>>>> 2. Then they would choose the services/api's then would like >>>>>>>> there application to access >>>>>>>> 3. other google server related items.... >>>>>>>> >>>>>>>> /Client Side/ >>>>>>>> >>>>>>>> 1. Create a new OAuth2 module thing >>>>>>>> 2. Get access token for the services would need to specify the >>>>>>>> services they would like to access >>>>>>>> 3. validate the token >>>>>>>> 4. make calls to the service >>>>>>>> >>>>>>>> >>>>>>>> API >>>>>>>> >>>>>>>> |var thing = AerGear.OAuth2({ >>>>>>>> name: googleEndPoints, //Just a Name >>>>>>>> clientID: "12345" //The client ID of the app from the API console >>>>>>>> settings: { >>>>>>>> permissions: "..", >>>>>>>> ... >>>>>>>> } >>>>>>>> }).somecoolmodulename.googleEndPoints; >>>>>>>> | >>>>>>>> >>>>>>>> /Settings: Multiple settings based on paramters here >>>>>>>> / >>>>>>>> >>>>>>>> /Methods/ >>>>>>>> >>>>>>>> >>>>>>>> authenticate >>>>>>>> >>>>>>>> this will authenticate with the server to get the access token and >>>>>>>> then validate the token, once that is all good then the response >>>>>>>> is returned. >>>>>>>> >>>>>>>> |thing.authenticate({ >>>>>>>> success:{}, >>>>>>>> error:{}, >>>>>>>> settings: { >>>>>>>> //probably some settings here, like URL overides and such >>>>>>>> } >>>>>>>> }); >>>>>>>> | >>>>>>>> >>>>>>>> >>>>>>>> callApi >>>>>>>> >>>>>>>> not really a good name, but it would basically call the remote >>>>>>>> api/services. we could either do a query string option or a Head >>>>>>>> option >>>>>>>> >>>>>>>> example: >>>>>>>> >>>>>>>> |curl 'https://www.googleapis.com/oauth2/v1/userinfo?access_token=1/fFBGRNJru1FQd44AzqT3Zg' >>>>>>>> | >>>>>>>> >>>>>>>> or >>>>>>>> >>>>>>>> |curl -H "Authorization: Bearer {accessToken}" https://www.googleapis.com/oauth2/v1/userinfo >>>>>>>> | >>>>>>>> >>>>>>>> code: >>>>>>>> >>>>>>>> |thing.callApi({ >>>>>>>> service: "userinfo", //don't really like this name either >>>>>>>> success:{}, >>>>>>>> error:{}, >>>>>>>> settings: { >>>>>>>> ... //overridable baseURLs? >>>>>>>> } >>>>>>>> }); >>>>>>>> | >>>>>>>> >>>>>>>> >>>>>>>> revoke >>>>>>>> >>>>>>>> again, maybe not the best name. calls the "revoke" service, to >>>>>>>> remove access to permissions >>>>>>>> >>>>>>>> |thing.revoke({ >>>>>>>> success: {}, >>>>>>>> error: {}, >>>>>>>> settings: {} >>>>>>>> }); >>>>>>>> | >>>>>>>> >>>>>>>> Behind the scenes on all these calls, the "access_token" is >>>>>>>> beining used and possibly refreshed for the user, so they don't >>>>>>>> have to worry about it. They just need to call authenticate first. >>>>>>>> Maybe we can have a refresh method if the user wants to refresh >>>>>>>> the tokens themselves. this would do the token "dance" >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Aug 26, 2013, at 1:35 PM, Bruno Oliveira >>>>>>> > wrote: >>>>>>>> >>>>>>>>> +1 I think is a good start to us. >>>>>>>>> >>>>>>>>> Kris Borchers wrote: >>>>>>>>>> I would like to see that but what you are saying makes sense. It >>>>>>>>>> sounds like where I was headed with the Basic and Digest >>>>>>>>>> adapters before I ran into browser security issues with headers. >>>>>>>>>> I think and authorization API that basically just wraps itself >>>>>>>>>> around secured endpoints works for me. >>>>>>>>> >>>>>>>>> -- >>>>>>>>> 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 >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>> >>>> _______________________________________________ >>>> 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/20131218/cc90b6be/attachment-0001.html From daniel at passos.me Wed Dec 18 15:06:56 2013 From: daniel at passos.me (Daniel Passos) Date: Wed, 18 Dec 2013 18:06:56 -0200 Subject: [aerogear-dev] AeroGear Android 1.3.1 Staged Message-ID: Hey Everyone, AeroGear Android 1.3.1 was staged on Nexus. \o/ This release introduces key services and fixes some bugs[1] Feel free to test it[2]! [1]?https://issues.jboss.org/issues/?filter=12320567 [2]?https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-2306/ --? Daniel Passos -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20131218/fd086f21/attachment.html From bruno at abstractj.org Wed Dec 18 15:37:50 2013 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 18 Dec 2013 18:37:50 -0200 Subject: [aerogear-dev] AeroGear Android 1.3.1 Staged In-Reply-To: References: Message-ID: Ahoy, when do you plan to press the release button? -- abstractj On December 18, 2013 at 6:07:19 PM, Daniel Passos (daniel at passos.me) wrote: > > Hey Everyone, > > AeroGear Android 1.3.1 was staged on Nexus. \o/ > > This release introduces key services and fixes some bugs[1] > > Feel free to test it[2]! > > [1] https://issues.jboss.org/issues/?filter=12320567 > [2] https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-2306/ From scm.blanc at gmail.com Thu Dec 19 03:44:54 2013 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Thu, 19 Dec 2013 09:44:54 +0100 Subject: [aerogear-dev] OAuth2 Adapter In-Reply-To: References: <1C771957-D239-4BDB-B837-00A4A4E02702@redhat.com> <940734E6-6C13-49E7-B044-753E19300F7C@redhat.com> <2A3B92C8-430C-4BE2-BDCC-FB5867743898@redhat.com> <521B91D9.6040806@abstractj.org> <9A9EB7B1-64E7-40D8-8172-51623EDF2470@redhat.com> <521CD70D.9070502@abstractj.org> <8E6B69AB-3FB4-4486-B40A-7ED3CA7B9B7B@redhat.com> <4C215076-003F-4200-B316-14622036079A@redhat.com> <0EABA5A2-A352-40AD-9A91-2F929C4FE9C4@redhat.com> <0120B639-CA96-4BDD-94AB-5BFC4813BB48@redhat.com> <1A14D527-BD5D-4BB4-83ED-69B69B09625A@redhat.com> Message-ID: I just tested the demo, very cool, work as advertised ;) On Wed, Dec 18, 2013 at 8:45 PM, Lucas Holmquist wrote: > i've created a new example here, > https://github.com/lholmquist/ag-google-drive > > that hopefully shows the flow a bit > > On Aug 29, 2013, at 2:05 PM, Lucas Holmquist wrote: > > i did get it to work > On Aug 29, 2013, at 2:04 PM, Sebastien Blanc wrote: > > This update is really cool, is the pipe test flow working ? > > > On Thu, Aug 29, 2013 at 7:57 PM, Lucas Holmquist wrote: > >> i've updated the sample again https://github.com/lholmquist/oauth2test >> >> this time i added a pipe object and used pipe.read to see how the flow >> would be >> >> >> On Aug 29, 2013, at 11:55 AM, Lucas Holmquist >> wrote: >> >> i've updated the sample app with the new flow >> >> https://github.com/lholmquist/oauth2test >> >> >> On Aug 29, 2013, at 9:23 AM, Lucas Holmquist wrote: >> >> ok, Kris had some thoughts on a better flow, so i refactored the code a >> bit and i think i like this way a bit better. >> >> New Flow - Client Flow - Standalone for now, possible integration with >> pipes First Time - No Access Token stored( in localStorage ) >> >> User will create the Authorization Object stuff with settings/options >> >> var thing = AeroGear.Authorization(); >> >> thing.add({ >> name: "coolThing", >> settings: { >> clientId: "12345.apps.googleusercontent.com", >> redirectURL: "http://localhost:8000/redirector.html", >> tokenValidationEndpoint: "https://www.googleapis.com/oauth2/v1/tokeninfo", >> authEndpoint: "https://accounts.google.com/o/oauth2/auth", >> revokeURL: "https://accounts.google.com/o/oauth2/revoke", >> scopes: "https://www.googleapis.com/auth/userinfo.profile", >> prompt: "force" >> } >> }); >> >> *should have the ability to specify more settings, based on the spec* >> >> The user would then call some method( currently not good names are coming >> to me, maybe validate ) that takes success and error callbacks. >> >> thing.services.coolThing.validate({ >> success: function( response ){ >> console.log( "Should be response from Validating the access token", response ); >> }, >> error: function( error ) { >> //should contain a constructed URL for the user >> console.log( "error", error ); >> } >> }); >> >> Since this is the first time, the error callback will be called and will >> contain the constructed URL that the user should do the popup redirect >> dance with to get an access token. >> >> *what "dance" they do is up to the developer* >> >> Once that happens and they have the access token, they would call the >> validate method again. >> >> this makes sure that the token they recieved is validated and will also >> return some other meta data related to the token, like refresh time. >> >> Once the token has been validated, it will be stored in localStorage and >> would be accessable with the key of ag-oauth2-whatever_the_client_ID_is . >> >> so in this example it would be something like: >> >> ag-oauth2-12345.apps.googleusercontent.com >> >> There is one problem i can see here though. If the user has to >> applications with the same client ID but different scopes assigned, this >> would be a problem. That use case could be considered bad practice anyway >> >> The user can then call the "callService"( yes, again, crappy name ) >> method to get access to the service they want. >> >> thing.services.coolThing.callService({ >> serviceURL: "https://www.googleapis.com/oauth2/v2/userinfo", >> success: function( response ){ >> console.log( "Should be the response from the call", response ); >> }, >> error: function( error ) { >> console.log( "error", error ); >> } >> }); >> >> All these methods would have success/error callbacks. >> Token Expiration >> >> If the user makes a call to a service, using the callService method, and >> they recieve an error such as not authorized or token invalid or token >> expired, I'm thinking we send what the "contructed URL" should be, similar >> to the validate method described above. >> >> Since this is a Client Side flow, there is no refresh token, so the >> client wouldn't be able to refresh the access token without doing the >> "dance" again. >> >> >> >> On Aug 27, 2013, at 1:57 PM, Lucas Holmquist wrote: >> >> i've hacked together a sample app that shows sort of the flow. >> >> https://github.com/lholmquist/oauth2test >> >> it is still very rough >> >> On Aug 27, 2013, at 12:42 PM, Bruno Oliveira wrote: >> >> +1 keep it simple, please >> >> Lucas Holmquist wrote: >> >> >> On Aug 27, 2013, at 3:39 AM, Sebastien Blanc > >> wrote: >> >> Hi, >> That sounds good ! >> Just one question, instead of using the callApi function couldn't we >> pass the oauth module (called 'thing' in your example) to the pipe >> directly, using the 'authenticator' setting. Behind the scene, the >> pipe manager will append the oauth token to the query or add the >> bearer header ? >> >> >> I'm not sure if that is what this is going to do. This is more of an >> Authorization thing and i don't think it totally fits the pipeline >> stuff. ( or it would make it a bit more complicated, and we want to keep >> it simple ) >> >> >> i should probably change the method to be "authorize" instead >> >> Seb >> >> >> >> On Mon, Aug 26, 2013 at 8:05 PM, Lucas Holmquist > >> wrote: >> >> >> OAuth2 AeroGear Workflow - High Level >> >> >> Using Google api's >> >> /Server Side/ >> >> 1. user needs to first create an "application/project" to get an >> api key >> 2. Then they would choose the services/api's then would like >> there application to access >> 3. other google server related items.... >> >> /Client Side/ >> >> 1. Create a new OAuth2 module thing >> 2. Get access token for the services would need to specify the >> services they would like to access >> 3. validate the token >> 4. make calls to the service >> >> >> API >> >> |var thing = AerGear.OAuth2({ >> name: googleEndPoints, //Just a Name >> clientID: "12345" //The client ID of the app from the >> API console >> settings: { >> permissions: "..", >> ... >> } >> }).somecoolmodulename.googleEndPoints; >> | >> >> /Settings: Multiple settings based on paramters here >> / >> >> /Methods/ >> >> >> authenticate >> >> this will authenticate with the server to get the access token and >> then validate the token, once that is all good then the response >> is returned. >> >> |thing.authenticate({ >> success:{}, >> error:{}, >> settings: { >> //probably some settings here, like URL overides and such >> } >> }); >> | >> >> >> callApi >> >> not really a good name, but it would basically call the remote >> api/services. we could either do a query string option or a Head >> option >> >> example: >> >> |curl ' >> https://www.googleapis.com/oauth2/v1/userinfo?access_token=1/fFBGRNJru1FQd44AzqT3Zg' >> | >> >> or >> >> |curl -H "Authorization: Bearer {accessToken}" >> https://www.googleapis.com/oauth2/v1/userinfo >> | >> >> code: >> >> |thing.callApi({ >> service: "userinfo", //don't really like this name either >> success:{}, >> error:{}, >> settings: { >> ... //overridable baseURLs? >> } >> }); >> | >> >> >> revoke >> >> again, maybe not the best name. calls the "revoke" service, to >> remove access to permissions >> >> |thing.revoke({ >> success: {}, >> error: {}, >> settings: {} >> }); >> | >> >> Behind the scenes on all these calls, the "access_token" is >> beining used and possibly refreshed for the user, so they don't >> have to worry about it. They just need to call authenticate first. >> Maybe we can have a refresh method if the user wants to refresh >> the tokens themselves. this would do the token "dance" >> >> >> >> On Aug 26, 2013, at 1:35 PM, Bruno Oliveira > >> wrote: >> >> +1 I think is a good start to us. >> >> Kris Borchers wrote: >> >> I would like to see that but what you are saying makes sense. It >> sounds like where I was headed with the Basic and Digest >> adapters before I ran into browser security issues with headers. >> I think and authorization API that basically just wraps itself >> around secured endpoints works for me. >> >> >> -- >> 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 >> >> >> _______________________________________________ >> 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 >> >> >> _______________________________________________ >> 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/20131219/4d7746f4/attachment-0001.html From scm.blanc at gmail.com Thu Dec 19 03:57:53 2013 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Thu, 19 Dec 2013 09:57:53 +0100 Subject: [aerogear-dev] Aerogear.js for CRUD In-Reply-To: <9588A9EB-BDA3-4D42-B778-396BBED53C2E@redhat.com> References: <504FFE44-06CE-4C05-A8A6-D049D2D41E00@redhat.com> <1445599908.40527893.1387224418368.JavaMail.root@redhat.com> <1928607956.40560513.1387229153309.JavaMail.root@redhat.com> <20131218164733.43acae54@kapy-ntb-x220> <9588A9EB-BDA3-4D42-B778-396BBED53C2E@redhat.com> Message-ID: On Wed, Dec 18, 2013 at 4:54 PM, Burr Sutter wrote: > It sounds like, at a minimum, we have a bug in the Forge scaffolding to > support Aerogear.js > > My next concern would be that since this "feature" was introduced with > jQuery 1.9, it could be that a LOT of the world's REST endpoints are no > longer POST compatible with Aerogear.js, nothing to be done about that > except to document it well for Aerogear.js when the time to promote it > heavily comes up. > Before you used Aerogear, you had also a version using only jquery, right ? Did you had the same behavior when doing a POST ? If yes, it's not only Aerogear based apps that have an issue but all the webapps around the world using jquery's ajax 1.9 stuff. > > Aerogear.js doc issues also include confusion of datamanager/store > (getting started guide is not clear for when those are needed) and the > seemingly missing docs for Pipe. Plus, the first example seen by the > end-user should include the use of iteration through the results, not an > underscore template which hides some of the details. > Could you open a new thread/jiras for the doc issues so that we don't mix all the things in one thread ? > > > On Dec 18, 2013, at 10:47 AM, Karel Piwko wrote: > > > To my understanding, HTTP 201 should always return created entity and its > > content should be based on Content-Type header field. > > > > See http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html > > > > On Mon, 16 Dec 2013 16:25:53 -0500 (EST) > > Vineet Reynolds Pereira wrote: > > > >> It would be better to treat this as a flag to be enabled during REST > resource > >> scaffolding. It would allow users to choose how the resource behaves - > >> * send a 201 response with Location header, > >> * send a 201 response with Location header and also a response entity. > >> > > _______________________________________________ > > 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/20131219/d2a8edc2/attachment.html From daniel at passos.me Thu Dec 19 05:24:16 2013 From: daniel at passos.me (Daniel Passos) Date: Thu, 19 Dec 2013 08:24:16 -0200 Subject: [aerogear-dev] AeroGear Android 1.3.1 Staged In-Reply-To: References: Message-ID: Next Friday (ship it to maven central) --? Daniel Passos On December 18, 2013 at 6:38:02 PM, Bruno Oliveira (bruno at abstractj.org) wrote: Ahoy, when do you plan to press the release button? -- abstractj On December 18, 2013 at 6:07:19 PM, Daniel Passos (daniel at passos.me) wrote: > > Hey Everyone, > > AeroGear Android 1.3.1 was staged on Nexus. \o/ > > This release introduces key services and fixes some bugs[1] > > Feel free to test it[2]! > > [1] https://issues.jboss.org/issues/?filter=12320567 > [2] https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-2306/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20131219/ce6d8720/attachment.html From bruno at abstractj.org Thu Dec 19 06:07:34 2013 From: bruno at abstractj.org (Bruno Oliveira) Date: Thu, 19 Dec 2013 09:07:34 -0200 Subject: [aerogear-dev] OAuth2 Adapter In-Reply-To: References: <1C771957-D239-4BDB-B837-00A4A4E02702@redhat.com> <940734E6-6C13-49E7-B044-753E19300F7C@redhat.com> <2A3B92C8-430C-4BE2-BDCC-FB5867743898@redhat.com> <521B91D9.6040806@abstractj.org> <9A9EB7B1-64E7-40D8-8172-51623EDF2470@redhat.com> <521CD70D.9070502@abstractj.org> <8E6B69AB-3FB4-4486-B40A-7ED3CA7B9B7B@redhat.com> <4C215076-003F-4200-B316-14622036079A@redhat.com> <0EABA5A2-A352-40AD-9A91-2F929C4FE9C4@redhat.com> <0120B639-CA96-4BDD-94AB-5BFC4813BB48@redhat.com> <1A14D527-BD5D-4BB4-83ED-69B69B09625A@redhat.com> Message-ID: Do we have a PR for it? Works like a charm on chrome, didn?t went well for safari. But let?s start simple, attach a PR please, I?m anxious to test it. -- abstractj On December 19, 2013 at 6:45:14 AM, Sebastien Blanc (scm.blanc at gmail.com) wrote: > > I just tested the demo, very cool, work as advertised ;) > > > On Wed, Dec 18, 2013 at 8:45 PM, Lucas Holmquist wrote: > > > i've created a new example here, > > https://github.com/lholmquist/ag-google-drive > > > > that hopefully shows the flow a bit > > > > On Aug 29, 2013, at 2:05 PM, Lucas Holmquist > wrote: > > > > i did get it to work > > On Aug 29, 2013, at 2:04 PM, Sebastien Blanc > wrote: > > > > This update is really cool, is the pipe test flow working ? > > > > > > On Thu, Aug 29, 2013 at 7:57 PM, Lucas Holmquist wrote: > > > >> i've updated the sample again https://github.com/lholmquist/oauth2test > >> > >> this time i added a pipe object and used pipe.read to see how > the flow > >> would be > >> > >> > >> On Aug 29, 2013, at 11:55 AM, Lucas Holmquist > >> wrote: > >> > >> i've updated the sample app with the new flow > >> > >> https://github.com/lholmquist/oauth2test > >> > >> > >> On Aug 29, 2013, at 9:23 AM, Lucas Holmquist > wrote: > >> > >> ok, Kris had some thoughts on a better flow, so i refactored > the code a > >> bit and i think i like this way a bit better. > >> > >> New Flow - Client Flow - Standalone for now, possible integration > with > >> pipes First Time - No Access Token stored( in localStorage > ) > >> > >> User will create the Authorization Object stuff with settings/options > >> > >> var thing = AeroGear.Authorization(); > >> > >> thing.add({ > >> name: "coolThing", > >> settings: { > >> clientId: "12345.apps.googleusercontent.com", > >> redirectURL: "http://localhost:8000/redirector.html", > >> tokenValidationEndpoint: "https://www.googleapis.com/oauth2/v1/tokeninfo", > >> authEndpoint: "https://accounts.google.com/o/oauth2/auth", > >> revokeURL: "https://accounts.google.com/o/oauth2/revoke", > >> scopes: "https://www.googleapis.com/auth/userinfo.profile", > >> prompt: "force" > >> } > >> }); > >> > >> *should have the ability to specify more settings, based on > the spec* > >> > >> The user would then call some method( currently not good names > are coming > >> to me, maybe validate ) that takes success and error callbacks. > >> > >> thing.services.coolThing.validate({ > >> success: function( response ){ > >> console.log( "Should be response from Validating the access > token", response ); > >> }, > >> error: function( error ) { > >> //should contain a constructed URL for the user > >> console.log( "error", error ); > >> } > >> }); > >> > >> Since this is the first time, the error callback will be called > and will > >> contain the constructed URL that the user should do the popup > redirect > >> dance with to get an access token. > >> > >> *what "dance" they do is up to the developer* > >> > >> Once that happens and they have the access token, they would > call the > >> validate method again. > >> > >> this makes sure that the token they recieved is validated and > will also > >> return some other meta data related to the token, like refresh > time. > >> > >> Once the token has been validated, it will be stored in localStorage > and > >> would be accessable with the key of ag-oauth2-whatever_the_client_ID_is > . > >> > >> so in this example it would be something like: > >> > >> ag-oauth2-12345.apps.googleusercontent.com > >> > >> There is one problem i can see here though. If the user has to > >> applications with the same client ID but different scopes > assigned, this > >> would be a problem. That use case could be considered bad practice > anyway > >> > >> The user can then call the "callService"( yes, again, crappy > name ) > >> method to get access to the service they want. > >> > >> thing.services.coolThing.callService({ > >> serviceURL: "https://www.googleapis.com/oauth2/v2/userinfo", > >> success: function( response ){ > >> console.log( "Should be the response from the call", response > ); > >> }, > >> error: function( error ) { > >> console.log( "error", error ); > >> } > >> }); > >> > >> All these methods would have success/error callbacks. > >> Token Expiration > >> > >> If the user makes a call to a service, using the callService > method, and > >> they recieve an error such as not authorized or token invalid > or token > >> expired, I'm thinking we send what the "contructed URL" should > be, similar > >> to the validate method described above. > >> > >> Since this is a Client Side flow, there is no refresh token, > so the > >> client wouldn't be able to refresh the access token without > doing the > >> "dance" again. > >> > >> > >> > >> On Aug 27, 2013, at 1:57 PM, Lucas Holmquist > wrote: > >> > >> i've hacked together a sample app that shows sort of the flow. > >> > >> https://github.com/lholmquist/oauth2test > >> > >> it is still very rough > >> > >> On Aug 27, 2013, at 12:42 PM, Bruno Oliveira > wrote: > >> > >> +1 keep it simple, please > >> > >> Lucas Holmquist wrote: > >> > >> > >> On Aug 27, 2013, at 3:39 AM, Sebastien Blanc > >> >> > wrote: > >> > >> Hi, > >> That sounds good ! > >> Just one question, instead of using the callApi function couldn't > we > >> pass the oauth module (called 'thing' in your example) to the > pipe > >> directly, using the 'authenticator' setting. Behind the > scene, the > >> pipe manager will append the oauth token to the query or add > the > >> bearer header ? > >> > >> > >> I'm not sure if that is what this is going to do. This is more of > an > >> Authorization thing and i don't think it totally fits the pipeline > >> stuff. ( or it would make it a bit more complicated, and we want > to keep > >> it simple ) > >> > >> > >> i should probably change the method to be "authorize" instead > >> > >> Seb > >> > >> > >> > >> On Mon, Aug 26, 2013 at 8:05 PM, Lucas Holmquist > >> >> > wrote: > >> > >> > >> OAuth2 AeroGear Workflow - High Level > >> > >> > >> Using Google api's > >> > >> /Server Side/ > >> > >> 1. user needs to first create an "application/project" to > get an > >> api key > >> 2. Then they would choose the services/api's then would like > >> there application to access > >> 3. other google server related items.... > >> > >> /Client Side/ > >> > >> 1. Create a new OAuth2 module thing > >> 2. Get access token for the services would need to specify the > >> services they would like to access > >> 3. validate the token > >> 4. make calls to the service > >> > >> > >> API > >> > >> |var thing = AerGear.OAuth2({ > >> name: googleEndPoints, //Just a Name > >> clientID: "12345" //The client ID of the app from the > >> API console > >> settings: { > >> permissions: "..", > >> ... > >> } > >> }).somecoolmodulename.googleEndPoints; > >> | > >> > >> /Settings: Multiple settings based on paramters here > >> / > >> > >> /Methods/ > >> > >> > >> authenticate > >> > >> this will authenticate with the server to get the access token > and > >> then validate the token, once that is all good then the response > >> is returned. > >> > >> |thing.authenticate({ > >> success:{}, > >> error:{}, > >> settings: { > >> //probably some settings here, like URL overides and such > >> } > >> }); > >> | > >> > >> > >> callApi > >> > >> not really a good name, but it would basically call the remote > >> api/services. we could either do a query string option or a > Head > >> option > >> > >> example: > >> > >> |curl ' > >> https://www.googleapis.com/oauth2/v1/userinfo?access_token=1/fFBGRNJru1FQd44AzqT3Zg' > >> | > >> > >> or > >> > >> |curl -H "Authorization: Bearer {accessToken}" > >> https://www.googleapis.com/oauth2/v1/userinfo > >> | > >> > >> code: > >> > >> |thing.callApi({ > >> service: "userinfo", //don't really like this name either > >> success:{}, > >> error:{}, > >> settings: { > >> ... //overridable baseURLs? > >> } > >> }); > >> | > >> > >> > >> revoke > >> > >> again, maybe not the best name. calls the "revoke" service, > to > >> remove access to permissions > >> > >> |thing.revoke({ > >> success: {}, > >> error: {}, > >> settings: {} > >> }); > >> | > >> > >> Behind the scenes on all these calls, the "access_token" is > >> beining used and possibly refreshed for the user, so they don't > >> have to worry about it. They just need to call authenticate > first. > >> Maybe we can have a refresh method if the user wants to refresh > >> the tokens themselves. this would do the token "dance" > >> > >> > >> > >> On Aug 26, 2013, at 1:35 PM, Bruno Oliveira > >> >> > wrote: > >> > >> +1 I think is a good start to us. > >> > >> Kris Borchers wrote: > >> > >> I would like to see that but what you are saying makes sense. > It > >> sounds like where I was headed with the Basic and Digest > >> adapters before I ran into browser security issues with headers. > >> I think and authorization API that basically just wraps itself > >> around secured endpoints works for me. > >> > >> > >> -- > >> 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 > >> > >> > >> _______________________________________________ > >> 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 > >> > >> > >> _______________________________________________ > >> 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 From kpiwko at redhat.com Thu Dec 19 06:11:33 2013 From: kpiwko at redhat.com (Karel Piwko) Date: Thu, 19 Dec 2013 12:11:33 +0100 Subject: [aerogear-dev] AeroGear Android 1.3.1 Staged In-Reply-To: References: Message-ID: <20131219121133.4edd38f8@kapy-ntb-x220> Awesome! I plan to run regression tests but we'll probably not be able to test key services, as everybody is out these days. On Wed, 18 Dec 2013 18:06:56 -0200 Daniel Passos wrote: > Hey Everyone, > > AeroGear Android 1.3.1 was staged on Nexus. \o/ > > This release introduces key services and fixes some bugs[1] > > Feel free to test it[2]! > > [1]?https://issues.jboss.org/issues/?filter=12320567 > [2]?https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-2306/ > > --? > Daniel Passos > From lholmqui at redhat.com Thu Dec 19 07:49:51 2013 From: lholmqui at redhat.com (Luke Holmquist) Date: Thu, 19 Dec 2013 07:49:51 -0500 (EST) Subject: [aerogear-dev] OAuth2 Adapter In-Reply-To: References: <1C771957-D239-4BDB-B837-00A4A4E02702@redhat.com> <940734E6-6C13-49E7-B044-753E19300F7C@redhat.com> <2A3B92C8-430C-4BE2-BDCC-FB5867743898@redhat.com> <521B91D9.6040806@abstractj.org> <9A9EB7B1-64E7-40D8-8172-51623EDF2470@redhat.com> <521CD70D.9070502@abstractj.org> <8E6B69AB-3FB4-4486-B40A-7ED3CA7B9B7B@redhat.com> <4C215076-003F-4200-B316-14622036079A@redhat.com> <0EABA5A2-A352-40AD-9A91-2F929C4FE9C4@redhat.com> <0120B639-CA96-4BDD-94AB-5BFC4813BB48@redhat.com> <1A14D527-BD5D-4BB4-83ED-69B69B09625A@redhat.com> Message-ID: https://github.com/aerogear/aerogear-js/pull/58 I reopened it Sent from my iPhone > On Dec 19, 2013, at 6:08 AM, Bruno Oliveira wrote: > > Do we have a PR for it? Works like a charm on chrome, didn?t went well for safari. But let?s start simple, attach a PR please, I?m anxious to test it. > > -- > abstractj > >> On December 19, 2013 at 6:45:14 AM, Sebastien Blanc (scm.blanc at gmail.com) wrote: >> >> I just tested the demo, very cool, work as advertised ;) >> >> >>> On Wed, Dec 18, 2013 at 8:45 PM, Lucas Holmquist wrote: >>> >>> i've created a new example here, >>> https://github.com/lholmquist/ag-google-drive >>> >>> that hopefully shows the flow a bit >>> >>>> On Aug 29, 2013, at 2:05 PM, Lucas Holmquist >>> wrote: >>> >>> i did get it to work >>>> On Aug 29, 2013, at 2:04 PM, Sebastien Blanc >>> wrote: >>> >>> This update is really cool, is the pipe test flow working ? >>> >>> >>>> On Thu, Aug 29, 2013 at 7:57 PM, Lucas Holmquist wrote: >>>> >>>> i've updated the sample again https://github.com/lholmquist/oauth2test >>>> >>>> this time i added a pipe object and used pipe.read to see how >> the flow >>>> would be >>>> >>>> >>>> On Aug 29, 2013, at 11:55 AM, Lucas Holmquist >>>> wrote: >>>> >>>> i've updated the sample app with the new flow >>>> >>>> https://github.com/lholmquist/oauth2test >>>> >>>> >>>> On Aug 29, 2013, at 9:23 AM, Lucas Holmquist >> wrote: >>>> >>>> ok, Kris had some thoughts on a better flow, so i refactored >> the code a >>>> bit and i think i like this way a bit better. >>>> >>>> New Flow - Client Flow - Standalone for now, possible integration >> with >>>> pipes First Time - No Access Token stored( in localStorage >> ) >>>> >>>> User will create the Authorization Object stuff with settings/options >>>> >>>> var thing = AeroGear.Authorization(); >>>> >>>> thing.add({ >>>> name: "coolThing", >>>> settings: { >>>> clientId: "12345.apps.googleusercontent.com", >>>> redirectURL: "http://localhost:8000/redirector.html", >>>> tokenValidationEndpoint: "https://www.googleapis.com/oauth2/v1/tokeninfo", >>>> authEndpoint: "https://accounts.google.com/o/oauth2/auth", >>>> revokeURL: "https://accounts.google.com/o/oauth2/revoke", >>>> scopes: "https://www.googleapis.com/auth/userinfo.profile", >>>> prompt: "force" >>>> } >>>> }); >>>> >>>> *should have the ability to specify more settings, based on >> the spec* >>>> >>>> The user would then call some method( currently not good names >> are coming >>>> to me, maybe validate ) that takes success and error callbacks. >>>> >>>> thing.services.coolThing.validate({ >>>> success: function( response ){ >>>> console.log( "Should be response from Validating the access >> token", response ); >>>> }, >>>> error: function( error ) { >>>> //should contain a constructed URL for the user >>>> console.log( "error", error ); >>>> } >>>> }); >>>> >>>> Since this is the first time, the error callback will be called >> and will >>>> contain the constructed URL that the user should do the popup >> redirect >>>> dance with to get an access token. >>>> >>>> *what "dance" they do is up to the developer* >>>> >>>> Once that happens and they have the access token, they would >> call the >>>> validate method again. >>>> >>>> this makes sure that the token they recieved is validated and >> will also >>>> return some other meta data related to the token, like refresh >> time. >>>> >>>> Once the token has been validated, it will be stored in localStorage >> and >>>> would be accessable with the key of ag-oauth2-whatever_the_client_ID_is >> . >>>> >>>> so in this example it would be something like: >>>> >>>> ag-oauth2-12345.apps.googleusercontent.com >>>> >>>> There is one problem i can see here though. If the user has to >>>> applications with the same client ID but different scopes >> assigned, this >>>> would be a problem. That use case could be considered bad practice >> anyway >>>> >>>> The user can then call the "callService"( yes, again, crappy >> name ) >>>> method to get access to the service they want. >>>> >>>> thing.services.coolThing.callService({ >>>> serviceURL: "https://www.googleapis.com/oauth2/v2/userinfo", >>>> success: function( response ){ >>>> console.log( "Should be the response from the call", response >> ); >>>> }, >>>> error: function( error ) { >>>> console.log( "error", error ); >>>> } >>>> }); >>>> >>>> All these methods would have success/error callbacks. >>>> Token Expiration >>>> >>>> If the user makes a call to a service, using the callService >> method, and >>>> they recieve an error such as not authorized or token invalid >> or token >>>> expired, I'm thinking we send what the "contructed URL" should >> be, similar >>>> to the validate method described above. >>>> >>>> Since this is a Client Side flow, there is no refresh token, >> so the >>>> client wouldn't be able to refresh the access token without >> doing the >>>> "dance" again. >>>> >>>> >>>> >>>> On Aug 27, 2013, at 1:57 PM, Lucas Holmquist >> wrote: >>>> >>>> i've hacked together a sample app that shows sort of the flow. >>>> >>>> https://github.com/lholmquist/oauth2test >>>> >>>> it is still very rough >>>> >>>> On Aug 27, 2013, at 12:42 PM, Bruno Oliveira >> wrote: >>>> >>>> +1 keep it simple, please >>>> >>>> Lucas Holmquist wrote: >>>> >>>> >>>> On Aug 27, 2013, at 3:39 AM, Sebastien Blanc > >> >> >> wrote: >>>> >>>> Hi, >>>> That sounds good ! >>>> Just one question, instead of using the callApi function couldn't >> we >>>> pass the oauth module (called 'thing' in your example) to the >> pipe >>>> directly, using the 'authenticator' setting. Behind the >> scene, the >>>> pipe manager will append the oauth token to the query or add >> the >>>> bearer header ? >>>> >>>> >>>> I'm not sure if that is what this is going to do. This is more of >> an >>>> Authorization thing and i don't think it totally fits the pipeline >>>> stuff. ( or it would make it a bit more complicated, and we want >> to keep >>>> it simple ) >>>> >>>> >>>> i should probably change the method to be "authorize" instead >>>> >>>> Seb >>>> >>>> >>>> >>>> On Mon, Aug 26, 2013 at 8:05 PM, Lucas Holmquist > >> >> >> wrote: >>>> >>>> >>>> OAuth2 AeroGear Workflow - High Level >>>> >>>> >>>> Using Google api's >>>> >>>> /Server Side/ >>>> >>>> 1. user needs to first create an "application/project" to >> get an >>>> api key >>>> 2. Then they would choose the services/api's then would like >>>> there application to access >>>> 3. other google server related items.... >>>> >>>> /Client Side/ >>>> >>>> 1. Create a new OAuth2 module thing >>>> 2. Get access token for the services would need to specify the >>>> services they would like to access >>>> 3. validate the token >>>> 4. make calls to the service >>>> >>>> >>>> API >>>> >>>> |var thing = AerGear.OAuth2({ >>>> name: googleEndPoints, //Just a Name >>>> clientID: "12345" //The client ID of the app from the >>>> API console >>>> settings: { >>>> permissions: "..", >>>> ... >>>> } >>>> }).somecoolmodulename.googleEndPoints; >>>> | >>>> >>>> /Settings: Multiple settings based on paramters here >>>> / >>>> >>>> /Methods/ >>>> >>>> >>>> authenticate >>>> >>>> this will authenticate with the server to get the access token >> and >>>> then validate the token, once that is all good then the response >>>> is returned. >>>> >>>> |thing.authenticate({ >>>> success:{}, >>>> error:{}, >>>> settings: { >>>> //probably some settings here, like URL overides and such >>>> } >>>> }); >>>> | >>>> >>>> >>>> callApi >>>> >>>> not really a good name, but it would basically call the remote >>>> api/services. we could either do a query string option or a >> Head >>>> option >>>> >>>> example: >>>> >>>> |curl ' >>>> https://www.googleapis.com/oauth2/v1/userinfo?access_token=1/fFBGRNJru1FQd44AzqT3Zg' >>>> | >>>> >>>> or >>>> >>>> |curl -H "Authorization: Bearer {accessToken}" >>>> https://www.googleapis.com/oauth2/v1/userinfo >>>> | >>>> >>>> code: >>>> >>>> |thing.callApi({ >>>> service: "userinfo", //don't really like this name either >>>> success:{}, >>>> error:{}, >>>> settings: { >>>> ... //overridable baseURLs? >>>> } >>>> }); >>>> | >>>> >>>> >>>> revoke >>>> >>>> again, maybe not the best name. calls the "revoke" service, >> to >>>> remove access to permissions >>>> >>>> |thing.revoke({ >>>> success: {}, >>>> error: {}, >>>> settings: {} >>>> }); >>>> | >>>> >>>> Behind the scenes on all these calls, the "access_token" is >>>> beining used and possibly refreshed for the user, so they don't >>>> have to worry about it. They just need to call authenticate >> first. >>>> Maybe we can have a refresh method if the user wants to refresh >>>> the tokens themselves. this would do the token "dance" >>>> >>>> >>>> >>>> On Aug 26, 2013, at 1:35 PM, Bruno Oliveira > >> >> >> wrote: >>>> >>>> +1 I think is a good start to us. >>>> >>>> Kris Borchers wrote: >>>> >>>> I would like to see that but what you are saying makes sense. >> It >>>> sounds like where I was headed with the Basic and Digest >>>> adapters before I ran into browser security issues with headers. >>>> I think and authorization API that basically just wraps itself >>>> around secured endpoints works for me. >>>> >>>> >>>> -- >>>> 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 >>>> >>>> >>>> _______________________________________________ >>>> 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 >>>> >>>> >>>> _______________________________________________ >>>> 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 > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From abstractj at redhat.com Thu Dec 19 08:51:35 2013 From: abstractj at redhat.com (Bruno Oliveira) Date: Thu, 19 Dec 2013 11:51:35 -0200 Subject: [aerogear-dev] Release early, release often Message-ID: Good morning, today during the integration with the Push server we found a bug?https://issues.jboss.org/browse/AGSEC-164 For this reason AG Security/AG Security Picketlink were staged under?https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-2309. I?m planning to release tomorrow, so raise your hand if you are planning to test it. -- abstractj JBoss, a division of Red Hat From bruno at abstractj.org Thu Dec 19 08:52:30 2013 From: bruno at abstractj.org (Bruno Oliveira) Date: Thu, 19 Dec 2013 11:52:30 -0200 Subject: [aerogear-dev] Release early, release often Message-ID: Good morning, today during the integration with the Push server we found a bug https://issues.jboss.org/browse/AGSEC-164 For this reason AG Security/AG Security Picketlink were staged under https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-2309. I?m planning to release tomorrow, so raise your hand if you are planning to test it. --? abstractj JBoss, a division of Red Hat From corinnekrych at gmail.com Fri Dec 20 02:40:40 2013 From: corinnekrych at gmail.com (Corinne Krych) Date: Fri, 20 Dec 2013 08:40:40 +0100 Subject: [aerogear-dev] OAuth2 Adapter In-Reply-To: References: <1C771957-D239-4BDB-B837-00A4A4E02702@redhat.com> <940734E6-6C13-49E7-B044-753E19300F7C@redhat.com> <2A3B92C8-430C-4BE2-BDCC-FB5867743898@redhat.com> <521B91D9.6040806@abstractj.org> <9A9EB7B1-64E7-40D8-8172-51623EDF2470@redhat.com> <521CD70D.9070502@abstractj.org> <8E6B69AB-3FB4-4486-B40A-7ED3CA7B9B7B@redhat.com> <4C215076-003F-4200-B316-14622036079A@redhat.com> <0EABA5A2-A352-40AD-9A91-2F929C4FE9C4@redhat.com> <0120B639-CA96-4BDD-94AB-5BFC4813BB48@redhat.com> <1A14D527-BD5D-4BB4-83ED-69B69B09625A@redhat.com> Message-ID: Hello All, I've implemented OAuth2 for iOS [1]. I still need some cleaning/refactoring before sending a PR. Following Lucas demo, I've tested it to display a list of your Google Drive files. You can test it here [2]. I will also do a PR for our ios-cookbook to add GoogleDrive app. Note that the implementation is not yet complete, we'll need to add: -revoke -refresh Main difference with js implementation is that I don't store permanently the accessTokens, I prefer to let the application developer decide whether or not the application should save the accessToken. OAuth2 interface is here [3] Managing OAuth callback into the application was the tricky point for Google+ as iOS implementation is poorly documented (I will add a section on Readme how to configure Google project etc?), Android version should be easier. ++ Corinne [1] https://github.com/corinnekrych/aerogear-ios/tree/AGIOS-138/AeroGear-iOS/AeroGear-iOS/security/Authorizer [2] https://github.com/corinnekrych/GoogleDrive [3] https://github.com/corinnekrych/aerogear-ios/blob/AGIOS-138/AeroGear-iOS/AeroGear-iOS/security/Authorizer/AGAuthzModule.h On Dec 19, 2013, at 1:49 PM, Luke Holmquist wrote: > https://github.com/aerogear/aerogear-js/pull/58 > > I reopened it > > Sent from my iPhone > >> On Dec 19, 2013, at 6:08 AM, Bruno Oliveira wrote: >> >> Do we have a PR for it? Works like a charm on chrome, didn?t went well for safari. But let?s start simple, attach a PR please, I?m anxious to test it. >> >> -- >> abstractj >> >>> On December 19, 2013 at 6:45:14 AM, Sebastien Blanc (scm.blanc at gmail.com) wrote: >>> >>> I just tested the demo, very cool, work as advertised ;) >>> >>> >>>> On Wed, Dec 18, 2013 at 8:45 PM, Lucas Holmquist wrote: >>>> >>>> i've created a new example here, >>>> https://github.com/lholmquist/ag-google-drive >>>> >>>> that hopefully shows the flow a bit >>>> >>>>> On Aug 29, 2013, at 2:05 PM, Lucas Holmquist >>>> wrote: >>>> >>>> i did get it to work >>>>> On Aug 29, 2013, at 2:04 PM, Sebastien Blanc >>>> wrote: >>>> >>>> This update is really cool, is the pipe test flow working ? >>>> >>>> >>>>> On Thu, Aug 29, 2013 at 7:57 PM, Lucas Holmquist wrote: >>>>> >>>>> i've updated the sample again https://github.com/lholmquist/oauth2test >>>>> >>>>> this time i added a pipe object and used pipe.read to see how >>> the flow >>>>> would be >>>>> >>>>> >>>>> On Aug 29, 2013, at 11:55 AM, Lucas Holmquist >>>>> wrote: >>>>> >>>>> i've updated the sample app with the new flow >>>>> >>>>> https://github.com/lholmquist/oauth2test >>>>> >>>>> >>>>> On Aug 29, 2013, at 9:23 AM, Lucas Holmquist >>> wrote: >>>>> >>>>> ok, Kris had some thoughts on a better flow, so i refactored >>> the code a >>>>> bit and i think i like this way a bit better. >>>>> >>>>> New Flow - Client Flow - Standalone for now, possible integration >>> with >>>>> pipes First Time - No Access Token stored( in localStorage >>> ) >>>>> >>>>> User will create the Authorization Object stuff with settings/options >>>>> >>>>> var thing = AeroGear.Authorization(); >>>>> >>>>> thing.add({ >>>>> name: "coolThing", >>>>> settings: { >>>>> clientId: "12345.apps.googleusercontent.com", >>>>> redirectURL: "http://localhost:8000/redirector.html", >>>>> tokenValidationEndpoint: "https://www.googleapis.com/oauth2/v1/tokeninfo", >>>>> authEndpoint: "https://accounts.google.com/o/oauth2/auth", >>>>> revokeURL: "https://accounts.google.com/o/oauth2/revoke", >>>>> scopes: "https://www.googleapis.com/auth/userinfo.profile", >>>>> prompt: "force" >>>>> } >>>>> }); >>>>> >>>>> *should have the ability to specify more settings, based on >>> the spec* >>>>> >>>>> The user would then call some method( currently not good names >>> are coming >>>>> to me, maybe validate ) that takes success and error callbacks. >>>>> >>>>> thing.services.coolThing.validate({ >>>>> success: function( response ){ >>>>> console.log( "Should be response from Validating the access >>> token", response ); >>>>> }, >>>>> error: function( error ) { >>>>> //should contain a constructed URL for the user >>>>> console.log( "error", error ); >>>>> } >>>>> }); >>>>> >>>>> Since this is the first time, the error callback will be called >>> and will >>>>> contain the constructed URL that the user should do the popup >>> redirect >>>>> dance with to get an access token. >>>>> >>>>> *what "dance" they do is up to the developer* >>>>> >>>>> Once that happens and they have the access token, they would >>> call the >>>>> validate method again. >>>>> >>>>> this makes sure that the token they recieved is validated and >>> will also >>>>> return some other meta data related to the token, like refresh >>> time. >>>>> >>>>> Once the token has been validated, it will be stored in localStorage >>> and >>>>> would be accessable with the key of ag-oauth2-whatever_the_client_ID_is >>> . >>>>> >>>>> so in this example it would be something like: >>>>> >>>>> ag-oauth2-12345.apps.googleusercontent.com >>>>> >>>>> There is one problem i can see here though. If the user has to >>>>> applications with the same client ID but different scopes >>> assigned, this >>>>> would be a problem. That use case could be considered bad practice >>> anyway >>>>> >>>>> The user can then call the "callService"( yes, again, crappy >>> name ) >>>>> method to get access to the service they want. >>>>> >>>>> thing.services.coolThing.callService({ >>>>> serviceURL: "https://www.googleapis.com/oauth2/v2/userinfo", >>>>> success: function( response ){ >>>>> console.log( "Should be the response from the call", response >>> ); >>>>> }, >>>>> error: function( error ) { >>>>> console.log( "error", error ); >>>>> } >>>>> }); >>>>> >>>>> All these methods would have success/error callbacks. >>>>> Token Expiration >>>>> >>>>> If the user makes a call to a service, using the callService >>> method, and >>>>> they recieve an error such as not authorized or token invalid >>> or token >>>>> expired, I'm thinking we send what the "contructed URL" should >>> be, similar >>>>> to the validate method described above. >>>>> >>>>> Since this is a Client Side flow, there is no refresh token, >>> so the >>>>> client wouldn't be able to refresh the access token without >>> doing the >>>>> "dance" again. >>>>> >>>>> >>>>> >>>>> On Aug 27, 2013, at 1:57 PM, Lucas Holmquist >>> wrote: >>>>> >>>>> i've hacked together a sample app that shows sort of the flow. >>>>> >>>>> https://github.com/lholmquist/oauth2test >>>>> >>>>> it is still very rough >>>>> >>>>> On Aug 27, 2013, at 12:42 PM, Bruno Oliveira >>> wrote: >>>>> >>>>> +1 keep it simple, please >>>>> >>>>> Lucas Holmquist wrote: >>>>> >>>>> >>>>> On Aug 27, 2013, at 3:39 AM, Sebastien Blanc > >> >> >>> wrote: >>>>> >>>>> Hi, >>>>> That sounds good ! >>>>> Just one question, instead of using the callApi function couldn't >>> we >>>>> pass the oauth module (called 'thing' in your example) to the >>> pipe >>>>> directly, using the 'authenticator' setting. Behind the >>> scene, the >>>>> pipe manager will append the oauth token to the query or add >>> the >>>>> bearer header ? >>>>> >>>>> >>>>> I'm not sure if that is what this is going to do. This is more of >>> an >>>>> Authorization thing and i don't think it totally fits the pipeline >>>>> stuff. ( or it would make it a bit more complicated, and we want >>> to keep >>>>> it simple ) >>>>> >>>>> >>>>> i should probably change the method to be "authorize" instead >>>>> >>>>> Seb >>>>> >>>>> >>>>> >>>>> On Mon, Aug 26, 2013 at 8:05 PM, Lucas Holmquist > >> >> >>> wrote: >>>>> >>>>> >>>>> OAuth2 AeroGear Workflow - High Level >>>>> >>>>> >>>>> Using Google api's >>>>> >>>>> /Server Side/ >>>>> >>>>> 1. user needs to first create an "application/project" to >>> get an >>>>> api key >>>>> 2. Then they would choose the services/api's then would like >>>>> there application to access >>>>> 3. other google server related items.... >>>>> >>>>> /Client Side/ >>>>> >>>>> 1. Create a new OAuth2 module thing >>>>> 2. Get access token for the services would need to specify the >>>>> services they would like to access >>>>> 3. validate the token >>>>> 4. make calls to the service >>>>> >>>>> >>>>> API >>>>> >>>>> |var thing = AerGear.OAuth2({ >>>>> name: googleEndPoints, //Just a Name >>>>> clientID: "12345" //The client ID of the app from the >>>>> API console >>>>> settings: { >>>>> permissions: "..", >>>>> ... >>>>> } >>>>> }).somecoolmodulename.googleEndPoints; >>>>> | >>>>> >>>>> /Settings: Multiple settings based on paramters here >>>>> / >>>>> >>>>> /Methods/ >>>>> >>>>> >>>>> authenticate >>>>> >>>>> this will authenticate with the server to get the access token >>> and >>>>> then validate the token, once that is all good then the response >>>>> is returned. >>>>> >>>>> |thing.authenticate({ >>>>> success:{}, >>>>> error:{}, >>>>> settings: { >>>>> //probably some settings here, like URL overides and such >>>>> } >>>>> }); >>>>> | >>>>> >>>>> >>>>> callApi >>>>> >>>>> not really a good name, but it would basically call the remote >>>>> api/services. we could either do a query string option or a >>> Head >>>>> option >>>>> >>>>> example: >>>>> >>>>> |curl ' >>>>> https://www.googleapis.com/oauth2/v1/userinfo?access_token=1/fFBGRNJru1FQd44AzqT3Zg' >>>>> | >>>>> >>>>> or >>>>> >>>>> |curl -H "Authorization: Bearer {accessToken}" >>>>> https://www.googleapis.com/oauth2/v1/userinfo >>>>> | >>>>> >>>>> code: >>>>> >>>>> |thing.callApi({ >>>>> service: "userinfo", //don't really like this name either >>>>> success:{}, >>>>> error:{}, >>>>> settings: { >>>>> ... //overridable baseURLs? >>>>> } >>>>> }); >>>>> | >>>>> >>>>> >>>>> revoke >>>>> >>>>> again, maybe not the best name. calls the "revoke" service, >>> to >>>>> remove access to permissions >>>>> >>>>> |thing.revoke({ >>>>> success: {}, >>>>> error: {}, >>>>> settings: {} >>>>> }); >>>>> | >>>>> >>>>> Behind the scenes on all these calls, the "access_token" is >>>>> beining used and possibly refreshed for the user, so they don't >>>>> have to worry about it. They just need to call authenticate >>> first. >>>>> Maybe we can have a refresh method if the user wants to refresh >>>>> the tokens themselves. this would do the token "dance" >>>>> >>>>> >>>>> >>>>> On Aug 26, 2013, at 1:35 PM, Bruno Oliveira > >> >> >>> wrote: >>>>> >>>>> +1 I think is a good start to us. >>>>> >>>>> Kris Borchers wrote: >>>>> >>>>> I would like to see that but what you are saying makes sense. >>> It >>>>> sounds like where I was headed with the Basic and Digest >>>>> adapters before I ran into browser security issues with headers. >>>>> I think and authorization API that basically just wraps itself >>>>> around secured endpoints works for me. >>>>> >>>>> >>>>> -- >>>>> 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 >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >> >> >> _______________________________________________ >> 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 corinnekrych at gmail.com Fri Dec 20 02:40:40 2013 From: corinnekrych at gmail.com (Corinne Krych) Date: Fri, 20 Dec 2013 08:40:40 +0100 Subject: [aerogear-dev] OAuth2 Adapter In-Reply-To: References: <1C771957-D239-4BDB-B837-00A4A4E02702@redhat.com> <940734E6-6C13-49E7-B044-753E19300F7C@redhat.com> <2A3B92C8-430C-4BE2-BDCC-FB5867743898@redhat.com> <521B91D9.6040806@abstractj.org> <9A9EB7B1-64E7-40D8-8172-51623EDF2470@redhat.com> <521CD70D.9070502@abstractj.org> <8E6B69AB-3FB4-4486-B40A-7ED3CA7B9B7B@redhat.com> <4C215076-003F-4200-B316-14622036079A@redhat.com> <0EABA5A2-A352-40AD-9A91-2F929C4FE9C4@redhat.com> <0120B639-CA96-4BDD-94AB-5BFC4813BB48@redhat.com> <1A14D527-BD5D-4BB4-83ED-69B69B09625A@redhat.com> Message-ID: Hello All, I've implemented OAuth2 for iOS [1]. I still need some cleaning/refactoring before sending a PR. Following Lucas demo, I've tested it to display a list of your Google Drive files. You can test it here [2]. I will also do a PR for our ios-cookbook to add GoogleDrive app. Note that the implementation is not yet complete, we'll need to add: -revoke -refresh Main difference with js implementation is that I don't store permanently the accessTokens, I prefer to let the application developer decide whether or not the application should save the accessToken. OAuth2 interface is here [3] Managing OAuth callback into the application was the tricky point for Google+ as iOS implementation is poorly documented (I will add a section on Readme how to configure Google project etc?), Android version should be easier. ++ Corinne [1] https://github.com/corinnekrych/aerogear-ios/tree/AGIOS-138/AeroGear-iOS/AeroGear-iOS/security/Authorizer [2] https://github.com/corinnekrych/GoogleDrive [3] https://github.com/corinnekrych/aerogear-ios/blob/AGIOS-138/AeroGear-iOS/AeroGear-iOS/security/Authorizer/AGAuthzModule.h On Dec 19, 2013, at 1:49 PM, Luke Holmquist wrote: > https://github.com/aerogear/aerogear-js/pull/58 > > I reopened it > > Sent from my iPhone > >> On Dec 19, 2013, at 6:08 AM, Bruno Oliveira wrote: >> >> Do we have a PR for it? Works like a charm on chrome, didn?t went well for safari. But let?s start simple, attach a PR please, I?m anxious to test it. >> >> -- >> abstractj >> >>> On December 19, 2013 at 6:45:14 AM, Sebastien Blanc (scm.blanc at gmail.com) wrote: >>> >>> I just tested the demo, very cool, work as advertised ;) >>> >>> >>>> On Wed, Dec 18, 2013 at 8:45 PM, Lucas Holmquist wrote: >>>> >>>> i've created a new example here, >>>> https://github.com/lholmquist/ag-google-drive >>>> >>>> that hopefully shows the flow a bit >>>> >>>>> On Aug 29, 2013, at 2:05 PM, Lucas Holmquist >>>> wrote: >>>> >>>> i did get it to work >>>>> On Aug 29, 2013, at 2:04 PM, Sebastien Blanc >>>> wrote: >>>> >>>> This update is really cool, is the pipe test flow working ? >>>> >>>> >>>>> On Thu, Aug 29, 2013 at 7:57 PM, Lucas Holmquist wrote: >>>>> >>>>> i've updated the sample again https://github.com/lholmquist/oauth2test >>>>> >>>>> this time i added a pipe object and used pipe.read to see how >>> the flow >>>>> would be >>>>> >>>>> >>>>> On Aug 29, 2013, at 11:55 AM, Lucas Holmquist >>>>> wrote: >>>>> >>>>> i've updated the sample app with the new flow >>>>> >>>>> https://github.com/lholmquist/oauth2test >>>>> >>>>> >>>>> On Aug 29, 2013, at 9:23 AM, Lucas Holmquist >>> wrote: >>>>> >>>>> ok, Kris had some thoughts on a better flow, so i refactored >>> the code a >>>>> bit and i think i like this way a bit better. >>>>> >>>>> New Flow - Client Flow - Standalone for now, possible integration >>> with >>>>> pipes First Time - No Access Token stored( in localStorage >>> ) >>>>> >>>>> User will create the Authorization Object stuff with settings/options >>>>> >>>>> var thing = AeroGear.Authorization(); >>>>> >>>>> thing.add({ >>>>> name: "coolThing", >>>>> settings: { >>>>> clientId: "12345.apps.googleusercontent.com", >>>>> redirectURL: "http://localhost:8000/redirector.html", >>>>> tokenValidationEndpoint: "https://www.googleapis.com/oauth2/v1/tokeninfo", >>>>> authEndpoint: "https://accounts.google.com/o/oauth2/auth", >>>>> revokeURL: "https://accounts.google.com/o/oauth2/revoke", >>>>> scopes: "https://www.googleapis.com/auth/userinfo.profile", >>>>> prompt: "force" >>>>> } >>>>> }); >>>>> >>>>> *should have the ability to specify more settings, based on >>> the spec* >>>>> >>>>> The user would then call some method( currently not good names >>> are coming >>>>> to me, maybe validate ) that takes success and error callbacks. >>>>> >>>>> thing.services.coolThing.validate({ >>>>> success: function( response ){ >>>>> console.log( "Should be response from Validating the access >>> token", response ); >>>>> }, >>>>> error: function( error ) { >>>>> //should contain a constructed URL for the user >>>>> console.log( "error", error ); >>>>> } >>>>> }); >>>>> >>>>> Since this is the first time, the error callback will be called >>> and will >>>>> contain the constructed URL that the user should do the popup >>> redirect >>>>> dance with to get an access token. >>>>> >>>>> *what "dance" they do is up to the developer* >>>>> >>>>> Once that happens and they have the access token, they would >>> call the >>>>> validate method again. >>>>> >>>>> this makes sure that the token they recieved is validated and >>> will also >>>>> return some other meta data related to the token, like refresh >>> time. >>>>> >>>>> Once the token has been validated, it will be stored in localStorage >>> and >>>>> would be accessable with the key of ag-oauth2-whatever_the_client_ID_is >>> . >>>>> >>>>> so in this example it would be something like: >>>>> >>>>> ag-oauth2-12345.apps.googleusercontent.com >>>>> >>>>> There is one problem i can see here though. If the user has to >>>>> applications with the same client ID but different scopes >>> assigned, this >>>>> would be a problem. That use case could be considered bad practice >>> anyway >>>>> >>>>> The user can then call the "callService"( yes, again, crappy >>> name ) >>>>> method to get access to the service they want. >>>>> >>>>> thing.services.coolThing.callService({ >>>>> serviceURL: "https://www.googleapis.com/oauth2/v2/userinfo", >>>>> success: function( response ){ >>>>> console.log( "Should be the response from the call", response >>> ); >>>>> }, >>>>> error: function( error ) { >>>>> console.log( "error", error ); >>>>> } >>>>> }); >>>>> >>>>> All these methods would have success/error callbacks. >>>>> Token Expiration >>>>> >>>>> If the user makes a call to a service, using the callService >>> method, and >>>>> they recieve an error such as not authorized or token invalid >>> or token >>>>> expired, I'm thinking we send what the "contructed URL" should >>> be, similar >>>>> to the validate method described above. >>>>> >>>>> Since this is a Client Side flow, there is no refresh token, >>> so the >>>>> client wouldn't be able to refresh the access token without >>> doing the >>>>> "dance" again. >>>>> >>>>> >>>>> >>>>> On Aug 27, 2013, at 1:57 PM, Lucas Holmquist >>> wrote: >>>>> >>>>> i've hacked together a sample app that shows sort of the flow. >>>>> >>>>> https://github.com/lholmquist/oauth2test >>>>> >>>>> it is still very rough >>>>> >>>>> On Aug 27, 2013, at 12:42 PM, Bruno Oliveira >>> wrote: >>>>> >>>>> +1 keep it simple, please >>>>> >>>>> Lucas Holmquist wrote: >>>>> >>>>> >>>>> On Aug 27, 2013, at 3:39 AM, Sebastien Blanc > >> >> >>> wrote: >>>>> >>>>> Hi, >>>>> That sounds good ! >>>>> Just one question, instead of using the callApi function couldn't >>> we >>>>> pass the oauth module (called 'thing' in your example) to the >>> pipe >>>>> directly, using the 'authenticator' setting. Behind the >>> scene, the >>>>> pipe manager will append the oauth token to the query or add >>> the >>>>> bearer header ? >>>>> >>>>> >>>>> I'm not sure if that is what this is going to do. This is more of >>> an >>>>> Authorization thing and i don't think it totally fits the pipeline >>>>> stuff. ( or it would make it a bit more complicated, and we want >>> to keep >>>>> it simple ) >>>>> >>>>> >>>>> i should probably change the method to be "authorize" instead >>>>> >>>>> Seb >>>>> >>>>> >>>>> >>>>> On Mon, Aug 26, 2013 at 8:05 PM, Lucas Holmquist > >> >> >>> wrote: >>>>> >>>>> >>>>> OAuth2 AeroGear Workflow - High Level >>>>> >>>>> >>>>> Using Google api's >>>>> >>>>> /Server Side/ >>>>> >>>>> 1. user needs to first create an "application/project" to >>> get an >>>>> api key >>>>> 2. Then they would choose the services/api's then would like >>>>> there application to access >>>>> 3. other google server related items.... >>>>> >>>>> /Client Side/ >>>>> >>>>> 1. Create a new OAuth2 module thing >>>>> 2. Get access token for the services would need to specify the >>>>> services they would like to access >>>>> 3. validate the token >>>>> 4. make calls to the service >>>>> >>>>> >>>>> API >>>>> >>>>> |var thing = AerGear.OAuth2({ >>>>> name: googleEndPoints, //Just a Name >>>>> clientID: "12345" //The client ID of the app from the >>>>> API console >>>>> settings: { >>>>> permissions: "..", >>>>> ... >>>>> } >>>>> }).somecoolmodulename.googleEndPoints; >>>>> | >>>>> >>>>> /Settings: Multiple settings based on paramters here >>>>> / >>>>> >>>>> /Methods/ >>>>> >>>>> >>>>> authenticate >>>>> >>>>> this will authenticate with the server to get the access token >>> and >>>>> then validate the token, once that is all good then the response >>>>> is returned. >>>>> >>>>> |thing.authenticate({ >>>>> success:{}, >>>>> error:{}, >>>>> settings: { >>>>> //probably some settings here, like URL overides and such >>>>> } >>>>> }); >>>>> | >>>>> >>>>> >>>>> callApi >>>>> >>>>> not really a good name, but it would basically call the remote >>>>> api/services. we could either do a query string option or a >>> Head >>>>> option >>>>> >>>>> example: >>>>> >>>>> |curl ' >>>>> https://www.googleapis.com/oauth2/v1/userinfo?access_token=1/fFBGRNJru1FQd44AzqT3Zg' >>>>> | >>>>> >>>>> or >>>>> >>>>> |curl -H "Authorization: Bearer {accessToken}" >>>>> https://www.googleapis.com/oauth2/v1/userinfo >>>>> | >>>>> >>>>> code: >>>>> >>>>> |thing.callApi({ >>>>> service: "userinfo", //don't really like this name either >>>>> success:{}, >>>>> error:{}, >>>>> settings: { >>>>> ... //overridable baseURLs? >>>>> } >>>>> }); >>>>> | >>>>> >>>>> >>>>> revoke >>>>> >>>>> again, maybe not the best name. calls the "revoke" service, >>> to >>>>> remove access to permissions >>>>> >>>>> |thing.revoke({ >>>>> success: {}, >>>>> error: {}, >>>>> settings: {} >>>>> }); >>>>> | >>>>> >>>>> Behind the scenes on all these calls, the "access_token" is >>>>> beining used and possibly refreshed for the user, so they don't >>>>> have to worry about it. They just need to call authenticate >>> first. >>>>> Maybe we can have a refresh method if the user wants to refresh >>>>> the tokens themselves. this would do the token "dance" >>>>> >>>>> >>>>> >>>>> On Aug 26, 2013, at 1:35 PM, Bruno Oliveira > >> >> >>> wrote: >>>>> >>>>> +1 I think is a good start to us. >>>>> >>>>> Kris Borchers wrote: >>>>> >>>>> I would like to see that but what you are saying makes sense. >>> It >>>>> sounds like where I was headed with the Basic and Digest >>>>> adapters before I ran into browser security issues with headers. >>>>> I think and authorization API that basically just wraps itself >>>>> around secured endpoints works for me. >>>>> >>>>> >>>>> -- >>>>> 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 >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >> >> >> _______________________________________________ >> 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 Dec 20 02:49:42 2013 From: bruno at abstractj.org (Bruno Oliveira) Date: Fri, 20 Dec 2013 05:49:42 -0200 Subject: [aerogear-dev] Release early, release often In-Reply-To: References: Message-ID: Released on Nexus. -- abstractj On December 19, 2013 at 11:52:34 AM, Bruno Oliveira (bruno at abstractj.org) wrote: > > Good morning, today during the integration with the Push server > we found a bug https://issues.jboss.org/browse/AGSEC-164 > > For this reason AG Security/AG Security Picketlink were staged > under https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-2309. > I?m planning to release tomorrow, so raise your hand if you are > planning to test it. > > -- > abstractj > > JBoss, a division of Red Hat > From edewit at redhat.com Fri Dec 20 06:34:30 2013 From: edewit at redhat.com (Erik Jan de Wit) Date: Fri, 20 Dec 2013 12:34:30 +0100 Subject: [aerogear-dev] sync Message-ID: So we already agreed that CouchDB has some nice features, but why wouldn?t we just use pouchdb for javascript and touchdb? I?ve just tested the javascript and it syncs with the server perfectly, even if there are some things missing we could add them because these projects are open source. Cheers, Erik Jan From scm.blanc at gmail.com Fri Dec 20 06:45:11 2013 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Fri, 20 Dec 2013 12:45:11 +0100 Subject: [aerogear-dev] sync In-Reply-To: References: Message-ID: Sure, PouchDB is nice, and we had already plans to make PouchDB datamanager adapter (I think Luke even started on this). But for sync, in general, don't we want to be database agnostic ? On Fri, Dec 20, 2013 at 12:34 PM, Erik Jan de Wit wrote: > So we already agreed that CouchDB has some nice features, but why wouldn?t > we just use pouchdb for javascript and touchdb? I?ve just tested the > javascript and it syncs with the server perfectly, even if there are some > things missing we could add them because these projects are open source. > > Cheers, > Erik Jan > _______________________________________________ > 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/20131220/032b73a4/attachment.html From bruno at abstractj.org Fri Dec 20 07:11:50 2013 From: bruno at abstractj.org (Bruno Oliveira) Date: Fri, 20 Dec 2013 10:11:50 -0200 Subject: [aerogear-dev] Keycloak on AeroGear Message-ID: Good morning peeps, yesterday I started to replace AeroGear Security on Unified Push server by Keycloak and you might be asking: ?Why??. Keycloak is a SSO with some handy features like TOTP, OAuth2, user management support and I think we have too much to contribute, is the only way to have some success with security, ?divide to conquer" (at least for authorization and authentication). So will ag-security be discontinued? No! Keycloak is still on Alpha and we have to test it against our projects before fully replace ag-security, but the only way to upstream our needs, is to using it. This replacement only applies to authentication/authorization features, we still have a ton of projects which Keycloak is not able to replace like: TOTP, crypto and OAuth2 on mobile, our focus. - PoC So let?s talk about this replacement, any dependency on ag-security was removed from the push server and replaced by Keycloak:?https://github.com/abstractj/aerogear-unifiedpush-server/tree/openshift Based on Keycloak examples, I just did copy & paste from one of the demos (https://github.com/abstractj/auth-server/tree/openshift) to create a server. Keycloak requires Resteasy 3.0.4, for this reason I had to manually replace some modules on JBoss. To test it go to: http://push-abstractj.rhcloud.com/ag-push/ you must be redirected to Keycloak, enter:? username: john at doe.com password: password You must be redirected to agpush console, keep in mind that I took some shortcuts to get this demo working, so for example the create will fail because I removed everything related into the ember interface. Is also possible to enable TOTP, user?s registration and whatever you want. So what do you think? -- abstractj From daniel.bevenius at gmail.com Fri Dec 20 07:16:57 2013 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Fri, 20 Dec 2013 13:16:57 +0100 Subject: [aerogear-dev] Keycloak on AeroGear In-Reply-To: References: Message-ID: Sounds like a good idea and the demo worked like a charm. Nice! On 20 December 2013 13:11, Bruno Oliveira wrote: > Good morning peeps, yesterday I started to replace AeroGear Security on > Unified Push server by Keycloak and you might be asking: ?Why??. Keycloak > is a SSO with some handy features like TOTP, OAuth2, user management > support and I think we have too much to contribute, is the only way to have > some success with security, ?divide to conquer" (at least for authorization > and authentication). > > So will ag-security be discontinued? No! Keycloak is still on Alpha and we > have to test it against our projects before fully replace ag-security, but > the only way to upstream our needs, is to using it. > > This replacement only applies to authentication/authorization features, we > still have a ton of projects which Keycloak is not able to replace like: > TOTP, crypto and OAuth2 on mobile, our focus. > > - PoC > > So let?s talk about this replacement, any dependency on ag-security was > removed from the push server and replaced by Keycloak: > https://github.com/abstractj/aerogear-unifiedpush-server/tree/openshift > > Based on Keycloak examples, I just did copy & paste from one of the demos ( > https://github.com/abstractj/auth-server/tree/openshift) to create a > server. Keycloak requires Resteasy 3.0.4, for this reason I had to manually > replace some modules on JBoss. > > To test it go to: http://push-abstractj.rhcloud.com/ag-push/ you must be > redirected to Keycloak, enter: > > username: john at doe.com > password: password > > You must be redirected to agpush console, keep in mind that I took some > shortcuts to get this demo working, so for example the create will fail > because I removed everything related into the ember interface. > > Is also possible to enable TOTP, user?s registration and whatever you want. > > So 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/20131220/2ddaf79b/attachment.html From cvasilak at gmail.com Fri Dec 20 07:23:36 2013 From: cvasilak at gmail.com (Christos Vasilakis) Date: Fri, 20 Dec 2013 14:23:36 +0200 Subject: [aerogear-dev] Keycloak on AeroGear In-Reply-To: References: Message-ID: <43EF0C0F-8895-4AE0-B035-09F535D5139B@gmail.com> On Dec 20, 2013, at 2:11 PM, Bruno Oliveira wrote: > Good morning peeps, yesterday I started to replace AeroGear Security on Unified Push server by Keycloak and you might be asking: ?Why??. Keycloak is a SSO with some handy features like TOTP, OAuth2, user management support and I think we have too much to contribute, is the only way to have some success with security, ?divide to conquer" (at least for authorization and authentication). > > So will ag-security be discontinued? No! Keycloak is still on Alpha and we have to test it against our projects before fully replace ag-security, but the only way to upstream our needs, is to using it. +1 valid point and demo worked great! nice work! > > This replacement only applies to authentication/authorization features, we still have a ton of projects which Keycloak is not able to replace like: TOTP, crypto and OAuth2 on mobile, our focus. > > - PoC > > So let?s talk about this replacement, any dependency on ag-security was removed from the push server and replaced by Keycloak: https://github.com/abstractj/aerogear-unifiedpush-server/tree/openshift > > Based on Keycloak examples, I just did copy & paste from one of the demos (https://github.com/abstractj/auth-server/tree/openshift) to create a server. Keycloak requires Resteasy 3.0.4, for this reason I had to manually replace some modules on JBoss. > > To test it go to: http://push-abstractj.rhcloud.com/ag-push/ you must be redirected to Keycloak, enter: > > username: john at doe.com > password: password > > You must be redirected to agpush console, keep in mind that I took some shortcuts to get this demo working, so for example the create will fail because I removed everything related into the ember interface. > > Is also possible to enable TOTP, user?s registration and whatever you want. > > So what do you think? > > -- > abstractj > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From scm.blanc at gmail.com Fri Dec 20 07:40:42 2013 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Fri, 20 Dec 2013 13:40:42 +0100 Subject: [aerogear-dev] Keycloak on AeroGear In-Reply-To: <43EF0C0F-8895-4AE0-B035-09F535D5139B@gmail.com> References: <43EF0C0F-8895-4AE0-B035-09F535D5139B@gmail.com> Message-ID: Awesome ! But does it make sense for me to hold on the User Management stuff as that will also be migrated to KeyCloak ? Seb On Fri, Dec 20, 2013 at 1:23 PM, Christos Vasilakis wrote: > > On Dec 20, 2013, at 2:11 PM, Bruno Oliveira wrote: > > > Good morning peeps, yesterday I started to replace AeroGear Security on > Unified Push server by Keycloak and you might be asking: ?Why??. Keycloak > is a SSO with some handy features like TOTP, OAuth2, user management > support and I think we have too much to contribute, is the only way to have > some success with security, ?divide to conquer" (at least for authorization > and authentication). > > > > So will ag-security be discontinued? No! Keycloak is still on Alpha and > we have to test it against our projects before fully replace ag-security, > but the only way to upstream our needs, is to using it. > > +1 valid point and demo worked great! > > nice work! > > > > > This replacement only applies to authentication/authorization features, > we still have a ton of projects which Keycloak is not able to replace like: > TOTP, crypto and OAuth2 on mobile, our focus. > > > > - PoC > > > > So let?s talk about this replacement, any dependency on ag-security was > removed from the push server and replaced by Keycloak: > https://github.com/abstractj/aerogear-unifiedpush-server/tree/openshift > > > > Based on Keycloak examples, I just did copy & paste from one of the > demos (https://github.com/abstractj/auth-server/tree/openshift) to create > a server. Keycloak requires Resteasy 3.0.4, for this reason I had to > manually replace some modules on JBoss. > > > > To test it go to: http://push-abstractj.rhcloud.com/ag-push/ you must > be redirected to Keycloak, enter: > > > > username: john at doe.com > > password: password > > > > You must be redirected to agpush console, keep in mind that I took some > shortcuts to get this demo working, so for example the create will fail > because I removed everything related into the ember interface. > > > > Is also possible to enable TOTP, user?s registration and whatever you > want. > > > > So 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20131220/5505a962/attachment.html From bruno at abstractj.org Fri Dec 20 08:14:57 2013 From: bruno at abstractj.org (Bruno Oliveira) Date: Fri, 20 Dec 2013 11:14:57 -0200 Subject: [aerogear-dev] Keycloak on AeroGear In-Reply-To: References: <43EF0C0F-8895-4AE0-B035-09F535D5139B@gmail.com> Message-ID: Keycloak already has the user management stuff, so I think is just a matter of play with it and check if it will meet our needs, if not, we can always suggest something at keycloak-dev. Regarding hold or not, let?s not rush on it. At the moment my suggestion is to play with keycloak and check what?s missing. -- abstractj On December 20, 2013 at 10:40:51 AM, Sebastien Blanc (scm.blanc at gmail.com) wrote: > > Awesome ! > But does it make sense for me to hold on the User Management stuff > as that will also be migrated to KeyCloak ? > Seb From lholmqui at redhat.com Fri Dec 20 08:28:12 2013 From: lholmqui at redhat.com (Lucas Holmquist) Date: Fri, 20 Dec 2013 08:28:12 -0500 Subject: [aerogear-dev] OAuth2 Adapter In-Reply-To: References: <1C771957-D239-4BDB-B837-00A4A4E02702@redhat.com> <940734E6-6C13-49E7-B044-753E19300F7C@redhat.com> <2A3B92C8-430C-4BE2-BDCC-FB5867743898@redhat.com> <521B91D9.6040806@abstractj.org> <9A9EB7B1-64E7-40D8-8172-51623EDF2470@redhat.com> <521CD70D.9070502@abstractj.org> <8E6B69AB-3FB4-4486-B40A-7ED3CA7B9B7B@redhat.com> <4C215076-003F-4200-B316-14622036079A@redhat.com> <0EABA5A2-A352-40AD-9A91-2F929C4FE9C4@redhat.com> <0120B639-CA96-4BDD-94AB-5BFC4813BB48@redhat.com> <1A14D527-BD5D-4BB4-83ED-69B69B09625A@redhat.com> Message-ID: cool On Dec 20, 2013, at 2:40 AM, Corinne Krych wrote: > Hello All, > > I've implemented OAuth2 for iOS [1]. I still need some cleaning/refactoring before sending a PR. > Following Lucas demo, I've tested it to display a list of your Google Drive files. You can test it here [2]. I will also do a PR for our ios-cookbook to add GoogleDrive app. > > Note that the implementation is not yet complete, we'll need to add: > -revoke > -refresh > > Main difference with js implementation is that I don't store permanently the accessTokens, I prefer to let the application developer decide whether or not the application should save the accessToken. OAuth2 interface is here [3] I'm still not sure this is a good idea on my part, it does help if the user refreshes the page, then they still have the token. although since the access token does expire, then it might not be to bad > > Managing OAuth callback into the application was the tricky point for Google+ as iOS implementation is poorly documented (I will add a section on Readme how to configure Google project etc?), Android version should be easier. > > ++ > Corinne > [1] https://github.com/corinnekrych/aerogear-ios/tree/AGIOS-138/AeroGear-iOS/AeroGear-iOS/security/Authorizer > [2] https://github.com/corinnekrych/GoogleDrive > [3] https://github.com/corinnekrych/aerogear-ios/blob/AGIOS-138/AeroGear-iOS/AeroGear-iOS/security/Authorizer/AGAuthzModule.h > > On Dec 19, 2013, at 1:49 PM, Luke Holmquist wrote: > >> https://github.com/aerogear/aerogear-js/pull/58 >> >> I reopened it >> >> Sent from my iPhone >> >>> On Dec 19, 2013, at 6:08 AM, Bruno Oliveira wrote: >>> >>> Do we have a PR for it? Works like a charm on chrome, didn?t went well for safari. But let?s start simple, attach a PR please, I?m anxious to test it. >>> >>> -- >>> abstractj >>> >>>> On December 19, 2013 at 6:45:14 AM, Sebastien Blanc (scm.blanc at gmail.com) wrote: >>>> >>>> I just tested the demo, very cool, work as advertised ;) >>>> >>>> >>>>> On Wed, Dec 18, 2013 at 8:45 PM, Lucas Holmquist wrote: >>>>> >>>>> i've created a new example here, >>>>> https://github.com/lholmquist/ag-google-drive >>>>> >>>>> that hopefully shows the flow a bit >>>>> >>>>>> On Aug 29, 2013, at 2:05 PM, Lucas Holmquist >>>>> wrote: >>>>> >>>>> i did get it to work >>>>>> On Aug 29, 2013, at 2:04 PM, Sebastien Blanc >>>>> wrote: >>>>> >>>>> This update is really cool, is the pipe test flow working ? >>>>> >>>>> >>>>>> On Thu, Aug 29, 2013 at 7:57 PM, Lucas Holmquist wrote: >>>>>> >>>>>> i've updated the sample again https://github.com/lholmquist/oauth2test >>>>>> >>>>>> this time i added a pipe object and used pipe.read to see how >>>> the flow >>>>>> would be >>>>>> >>>>>> >>>>>> On Aug 29, 2013, at 11:55 AM, Lucas Holmquist >>>>>> wrote: >>>>>> >>>>>> i've updated the sample app with the new flow >>>>>> >>>>>> https://github.com/lholmquist/oauth2test >>>>>> >>>>>> >>>>>> On Aug 29, 2013, at 9:23 AM, Lucas Holmquist >>>> wrote: >>>>>> >>>>>> ok, Kris had some thoughts on a better flow, so i refactored >>>> the code a >>>>>> bit and i think i like this way a bit better. >>>>>> >>>>>> New Flow - Client Flow - Standalone for now, possible integration >>>> with >>>>>> pipes First Time - No Access Token stored( in localStorage >>>> ) >>>>>> >>>>>> User will create the Authorization Object stuff with settings/options >>>>>> >>>>>> var thing = AeroGear.Authorization(); >>>>>> >>>>>> thing.add({ >>>>>> name: "coolThing", >>>>>> settings: { >>>>>> clientId: "12345.apps.googleusercontent.com", >>>>>> redirectURL: "http://localhost:8000/redirector.html", >>>>>> tokenValidationEndpoint: "https://www.googleapis.com/oauth2/v1/tokeninfo", >>>>>> authEndpoint: "https://accounts.google.com/o/oauth2/auth", >>>>>> revokeURL: "https://accounts.google.com/o/oauth2/revoke", >>>>>> scopes: "https://www.googleapis.com/auth/userinfo.profile", >>>>>> prompt: "force" >>>>>> } >>>>>> }); >>>>>> >>>>>> *should have the ability to specify more settings, based on >>>> the spec* >>>>>> >>>>>> The user would then call some method( currently not good names >>>> are coming >>>>>> to me, maybe validate ) that takes success and error callbacks. >>>>>> >>>>>> thing.services.coolThing.validate({ >>>>>> success: function( response ){ >>>>>> console.log( "Should be response from Validating the access >>>> token", response ); >>>>>> }, >>>>>> error: function( error ) { >>>>>> //should contain a constructed URL for the user >>>>>> console.log( "error", error ); >>>>>> } >>>>>> }); >>>>>> >>>>>> Since this is the first time, the error callback will be called >>>> and will >>>>>> contain the constructed URL that the user should do the popup >>>> redirect >>>>>> dance with to get an access token. >>>>>> >>>>>> *what "dance" they do is up to the developer* >>>>>> >>>>>> Once that happens and they have the access token, they would >>>> call the >>>>>> validate method again. >>>>>> >>>>>> this makes sure that the token they recieved is validated and >>>> will also >>>>>> return some other meta data related to the token, like refresh >>>> time. >>>>>> >>>>>> Once the token has been validated, it will be stored in localStorage >>>> and >>>>>> would be accessable with the key of ag-oauth2-whatever_the_client_ID_is >>>> . >>>>>> >>>>>> so in this example it would be something like: >>>>>> >>>>>> ag-oauth2-12345.apps.googleusercontent.com >>>>>> >>>>>> There is one problem i can see here though. If the user has to >>>>>> applications with the same client ID but different scopes >>>> assigned, this >>>>>> would be a problem. That use case could be considered bad practice >>>> anyway >>>>>> >>>>>> The user can then call the "callService"( yes, again, crappy >>>> name ) >>>>>> method to get access to the service they want. >>>>>> >>>>>> thing.services.coolThing.callService({ >>>>>> serviceURL: "https://www.googleapis.com/oauth2/v2/userinfo", >>>>>> success: function( response ){ >>>>>> console.log( "Should be the response from the call", response >>>> ); >>>>>> }, >>>>>> error: function( error ) { >>>>>> console.log( "error", error ); >>>>>> } >>>>>> }); >>>>>> >>>>>> All these methods would have success/error callbacks. >>>>>> Token Expiration >>>>>> >>>>>> If the user makes a call to a service, using the callService >>>> method, and >>>>>> they recieve an error such as not authorized or token invalid >>>> or token >>>>>> expired, I'm thinking we send what the "contructed URL" should >>>> be, similar >>>>>> to the validate method described above. >>>>>> >>>>>> Since this is a Client Side flow, there is no refresh token, >>>> so the >>>>>> client wouldn't be able to refresh the access token without >>>> doing the >>>>>> "dance" again. >>>>>> >>>>>> >>>>>> >>>>>> On Aug 27, 2013, at 1:57 PM, Lucas Holmquist >>>> wrote: >>>>>> >>>>>> i've hacked together a sample app that shows sort of the flow. >>>>>> >>>>>> https://github.com/lholmquist/oauth2test >>>>>> >>>>>> it is still very rough >>>>>> >>>>>> On Aug 27, 2013, at 12:42 PM, Bruno Oliveira >>>> wrote: >>>>>> >>>>>> +1 keep it simple, please >>>>>> >>>>>> Lucas Holmquist wrote: >>>>>> >>>>>> >>>>>> On Aug 27, 2013, at 3:39 AM, Sebastien Blanc > >> >> >>>> wrote: >>>>>> >>>>>> Hi, >>>>>> That sounds good ! >>>>>> Just one question, instead of using the callApi function couldn't >>>> we >>>>>> pass the oauth module (called 'thing' in your example) to the >>>> pipe >>>>>> directly, using the 'authenticator' setting. Behind the >>>> scene, the >>>>>> pipe manager will append the oauth token to the query or add >>>> the >>>>>> bearer header ? >>>>>> >>>>>> >>>>>> I'm not sure if that is what this is going to do. This is more of >>>> an >>>>>> Authorization thing and i don't think it totally fits the pipeline >>>>>> stuff. ( or it would make it a bit more complicated, and we want >>>> to keep >>>>>> it simple ) >>>>>> >>>>>> >>>>>> i should probably change the method to be "authorize" instead >>>>>> >>>>>> Seb >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Aug 26, 2013 at 8:05 PM, Lucas Holmquist > >> >> >>>> wrote: >>>>>> >>>>>> >>>>>> OAuth2 AeroGear Workflow - High Level >>>>>> >>>>>> >>>>>> Using Google api's >>>>>> >>>>>> /Server Side/ >>>>>> >>>>>> 1. user needs to first create an "application/project" to >>>> get an >>>>>> api key >>>>>> 2. Then they would choose the services/api's then would like >>>>>> there application to access >>>>>> 3. other google server related items.... >>>>>> >>>>>> /Client Side/ >>>>>> >>>>>> 1. Create a new OAuth2 module thing >>>>>> 2. Get access token for the services would need to specify the >>>>>> services they would like to access >>>>>> 3. validate the token >>>>>> 4. make calls to the service >>>>>> >>>>>> >>>>>> API >>>>>> >>>>>> |var thing = AerGear.OAuth2({ >>>>>> name: googleEndPoints, //Just a Name >>>>>> clientID: "12345" //The client ID of the app from the >>>>>> API console >>>>>> settings: { >>>>>> permissions: "..", >>>>>> ... >>>>>> } >>>>>> }).somecoolmodulename.googleEndPoints; >>>>>> | >>>>>> >>>>>> /Settings: Multiple settings based on paramters here >>>>>> / >>>>>> >>>>>> /Methods/ >>>>>> >>>>>> >>>>>> authenticate >>>>>> >>>>>> this will authenticate with the server to get the access token >>>> and >>>>>> then validate the token, once that is all good then the response >>>>>> is returned. >>>>>> >>>>>> |thing.authenticate({ >>>>>> success:{}, >>>>>> error:{}, >>>>>> settings: { >>>>>> //probably some settings here, like URL overides and such >>>>>> } >>>>>> }); >>>>>> | >>>>>> >>>>>> >>>>>> callApi >>>>>> >>>>>> not really a good name, but it would basically call the remote >>>>>> api/services. we could either do a query string option or a >>>> Head >>>>>> option >>>>>> >>>>>> example: >>>>>> >>>>>> |curl ' >>>>>> https://www.googleapis.com/oauth2/v1/userinfo?access_token=1/fFBGRNJru1FQd44AzqT3Zg' >>>>>> | >>>>>> >>>>>> or >>>>>> >>>>>> |curl -H "Authorization: Bearer {accessToken}" >>>>>> https://www.googleapis.com/oauth2/v1/userinfo >>>>>> | >>>>>> >>>>>> code: >>>>>> >>>>>> |thing.callApi({ >>>>>> service: "userinfo", //don't really like this name either >>>>>> success:{}, >>>>>> error:{}, >>>>>> settings: { >>>>>> ... //overridable baseURLs? >>>>>> } >>>>>> }); >>>>>> | >>>>>> >>>>>> >>>>>> revoke >>>>>> >>>>>> again, maybe not the best name. calls the "revoke" service, >>>> to >>>>>> remove access to permissions >>>>>> >>>>>> |thing.revoke({ >>>>>> success: {}, >>>>>> error: {}, >>>>>> settings: {} >>>>>> }); >>>>>> | >>>>>> >>>>>> Behind the scenes on all these calls, the "access_token" is >>>>>> beining used and possibly refreshed for the user, so they don't >>>>>> have to worry about it. They just need to call authenticate >>>> first. >>>>>> Maybe we can have a refresh method if the user wants to refresh >>>>>> the tokens themselves. this would do the token "dance" >>>>>> >>>>>> >>>>>> >>>>>> On Aug 26, 2013, at 1:35 PM, Bruno Oliveira > >> >> >>>> wrote: >>>>>> >>>>>> +1 I think is a good start to us. >>>>>> >>>>>> Kris Borchers wrote: >>>>>> >>>>>> I would like to see that but what you are saying makes sense. >>>> It >>>>>> sounds like where I was headed with the Basic and Digest >>>>>> adapters before I ran into browser security issues with headers. >>>>>> I think and authorization API that basically just wraps itself >>>>>> around secured endpoints works for me. >>>>>> >>>>>> >>>>>> -- >>>>>> 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 >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>> >>> >>> _______________________________________________ >>> 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 corinnekrych at gmail.com Fri Dec 20 08:37:48 2013 From: corinnekrych at gmail.com (Corinne Krych) Date: Fri, 20 Dec 2013 14:37:48 +0100 Subject: [aerogear-dev] OAuth2 Adapter In-Reply-To: References: <1C771957-D239-4BDB-B837-00A4A4E02702@redhat.com> <940734E6-6C13-49E7-B044-753E19300F7C@redhat.com> <2A3B92C8-430C-4BE2-BDCC-FB5867743898@redhat.com> <521B91D9.6040806@abstractj.org> <9A9EB7B1-64E7-40D8-8172-51623EDF2470@redhat.com> <521CD70D.9070502@abstractj.org> <8E6B69AB-3FB4-4486-B40A-7ED3CA7B9B7B@redhat.com> <4C215076-003F-4200-B316-14622036079A@redhat.com> <0EABA5A2-A352-40AD-9A91-2F929C4FE9C4@redhat.com> <0120B639-CA96-4BDD-94AB-5BFC4813BB48@redhat.com> <1A14D527-BD5D-4BB4-83ED-69B69B09625A@redhat.com> Message-ID: <13E69CC3-9D1B-4EA9-A465-DCF359608AD5@gmail.com> On Dec 20, 2013, at 2:28 PM, Lucas Holmquist wrote: > cool > On Dec 20, 2013, at 2:40 AM, Corinne Krych wrote: > >> Hello All, >> >> I've implemented OAuth2 for iOS [1]. I still need some cleaning/refactoring before sending a PR. >> Following Lucas demo, I've tested it to display a list of your Google Drive files. You can test it here [2]. I will also do a PR for our ios-cookbook to add GoogleDrive app. >> >> Note that the implementation is not yet complete, we'll need to add: >> -revoke >> -refresh >> >> Main difference with js implementation is that I don't store permanently the accessTokens, I prefer to let the application developer decide whether or not the application should save the accessToken. OAuth2 interface is here [3] > I'm still not sure this is a good idea on my part, it does help if the user refreshes the page, then they still have the token. > > although since the access token does expire, then it might not be to bad it's not a bad idea storing them as they have limited life ( I've read it's more the refresh token you should not store because this one last longer) but I think this should be left to the developer to decide how he wants to deal with accessToken. Basically does the application prompt the user for authz at each load, or store the access token and prompt when expired etc.. That should be left to the developer. I would rather follow Authentication authToken strategy, we keep them in memory within authModule and pass them to the pipe. wdyt? This part still need work on my side. > >> >> Managing OAuth callback into the application was the tricky point for Google+ as iOS implementation is poorly documented (I will add a section on Readme how to configure Google project etc?), Android version should be easier. >> >> ++ >> Corinne >> [1] https://github.com/corinnekrych/aerogear-ios/tree/AGIOS-138/AeroGear-iOS/AeroGear-iOS/security/Authorizer >> [2] https://github.com/corinnekrych/GoogleDrive >> [3] https://github.com/corinnekrych/aerogear-ios/blob/AGIOS-138/AeroGear-iOS/AeroGear-iOS/security/Authorizer/AGAuthzModule.h >> >> On Dec 19, 2013, at 1:49 PM, Luke Holmquist wrote: >> >>> https://github.com/aerogear/aerogear-js/pull/58 >>> >>> I reopened it >>> >>> Sent from my iPhone >>> >>>> On Dec 19, 2013, at 6:08 AM, Bruno Oliveira wrote: >>>> >>>> Do we have a PR for it? Works like a charm on chrome, didn?t went well for safari. But let?s start simple, attach a PR please, I?m anxious to test it. >>>> >>>> -- >>>> abstractj >>>> >>>>> On December 19, 2013 at 6:45:14 AM, Sebastien Blanc (scm.blanc at gmail.com) wrote: >>>>> >>>>> I just tested the demo, very cool, work as advertised ;) >>>>> >>>>> >>>>>> On Wed, Dec 18, 2013 at 8:45 PM, Lucas Holmquist wrote: >>>>>> >>>>>> i've created a new example here, >>>>>> https://github.com/lholmquist/ag-google-drive >>>>>> >>>>>> that hopefully shows the flow a bit >>>>>> >>>>>>> On Aug 29, 2013, at 2:05 PM, Lucas Holmquist >>>>>> wrote: >>>>>> >>>>>> i did get it to work >>>>>>> On Aug 29, 2013, at 2:04 PM, Sebastien Blanc >>>>>> wrote: >>>>>> >>>>>> This update is really cool, is the pipe test flow working ? >>>>>> >>>>>> >>>>>>> On Thu, Aug 29, 2013 at 7:57 PM, Lucas Holmquist wrote: >>>>>>> >>>>>>> i've updated the sample again https://github.com/lholmquist/oauth2test >>>>>>> >>>>>>> this time i added a pipe object and used pipe.read to see how >>>>> the flow >>>>>>> would be >>>>>>> >>>>>>> >>>>>>> On Aug 29, 2013, at 11:55 AM, Lucas Holmquist >>>>>>> wrote: >>>>>>> >>>>>>> i've updated the sample app with the new flow >>>>>>> >>>>>>> https://github.com/lholmquist/oauth2test >>>>>>> >>>>>>> >>>>>>> On Aug 29, 2013, at 9:23 AM, Lucas Holmquist >>>>> wrote: >>>>>>> >>>>>>> ok, Kris had some thoughts on a better flow, so i refactored >>>>> the code a >>>>>>> bit and i think i like this way a bit better. >>>>>>> >>>>>>> New Flow - Client Flow - Standalone for now, possible integration >>>>> with >>>>>>> pipes First Time - No Access Token stored( in localStorage >>>>> ) >>>>>>> >>>>>>> User will create the Authorization Object stuff with settings/options >>>>>>> >>>>>>> var thing = AeroGear.Authorization(); >>>>>>> >>>>>>> thing.add({ >>>>>>> name: "coolThing", >>>>>>> settings: { >>>>>>> clientId: "12345.apps.googleusercontent.com", >>>>>>> redirectURL: "http://localhost:8000/redirector.html", >>>>>>> tokenValidationEndpoint: "https://www.googleapis.com/oauth2/v1/tokeninfo", >>>>>>> authEndpoint: "https://accounts.google.com/o/oauth2/auth", >>>>>>> revokeURL: "https://accounts.google.com/o/oauth2/revoke", >>>>>>> scopes: "https://www.googleapis.com/auth/userinfo.profile", >>>>>>> prompt: "force" >>>>>>> } >>>>>>> }); >>>>>>> >>>>>>> *should have the ability to specify more settings, based on >>>>> the spec* >>>>>>> >>>>>>> The user would then call some method( currently not good names >>>>> are coming >>>>>>> to me, maybe validate ) that takes success and error callbacks. >>>>>>> >>>>>>> thing.services.coolThing.validate({ >>>>>>> success: function( response ){ >>>>>>> console.log( "Should be response from Validating the access >>>>> token", response ); >>>>>>> }, >>>>>>> error: function( error ) { >>>>>>> //should contain a constructed URL for the user >>>>>>> console.log( "error", error ); >>>>>>> } >>>>>>> }); >>>>>>> >>>>>>> Since this is the first time, the error callback will be called >>>>> and will >>>>>>> contain the constructed URL that the user should do the popup >>>>> redirect >>>>>>> dance with to get an access token. >>>>>>> >>>>>>> *what "dance" they do is up to the developer* >>>>>>> >>>>>>> Once that happens and they have the access token, they would >>>>> call the >>>>>>> validate method again. >>>>>>> >>>>>>> this makes sure that the token they recieved is validated and >>>>> will also >>>>>>> return some other meta data related to the token, like refresh >>>>> time. >>>>>>> >>>>>>> Once the token has been validated, it will be stored in localStorage >>>>> and >>>>>>> would be accessable with the key of ag-oauth2-whatever_the_client_ID_is >>>>> . >>>>>>> >>>>>>> so in this example it would be something like: >>>>>>> >>>>>>> ag-oauth2-12345.apps.googleusercontent.com >>>>>>> >>>>>>> There is one problem i can see here though. If the user has to >>>>>>> applications with the same client ID but different scopes >>>>> assigned, this >>>>>>> would be a problem. That use case could be considered bad practice >>>>> anyway >>>>>>> >>>>>>> The user can then call the "callService"( yes, again, crappy >>>>> name ) >>>>>>> method to get access to the service they want. >>>>>>> >>>>>>> thing.services.coolThing.callService({ >>>>>>> serviceURL: "https://www.googleapis.com/oauth2/v2/userinfo", >>>>>>> success: function( response ){ >>>>>>> console.log( "Should be the response from the call", response >>>>> ); >>>>>>> }, >>>>>>> error: function( error ) { >>>>>>> console.log( "error", error ); >>>>>>> } >>>>>>> }); >>>>>>> >>>>>>> All these methods would have success/error callbacks. >>>>>>> Token Expiration >>>>>>> >>>>>>> If the user makes a call to a service, using the callService >>>>> method, and >>>>>>> they recieve an error such as not authorized or token invalid >>>>> or token >>>>>>> expired, I'm thinking we send what the "contructed URL" should >>>>> be, similar >>>>>>> to the validate method described above. >>>>>>> >>>>>>> Since this is a Client Side flow, there is no refresh token, >>>>> so the >>>>>>> client wouldn't be able to refresh the access token without >>>>> doing the >>>>>>> "dance" again. >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Aug 27, 2013, at 1:57 PM, Lucas Holmquist >>>>> wrote: >>>>>>> >>>>>>> i've hacked together a sample app that shows sort of the flow. >>>>>>> >>>>>>> https://github.com/lholmquist/oauth2test >>>>>>> >>>>>>> it is still very rough >>>>>>> >>>>>>> On Aug 27, 2013, at 12:42 PM, Bruno Oliveira >>>>> wrote: >>>>>>> >>>>>>> +1 keep it simple, please >>>>>>> >>>>>>> Lucas Holmquist wrote: >>>>>>> >>>>>>> >>>>>>> On Aug 27, 2013, at 3:39 AM, Sebastien Blanc > >> >> >>>>> wrote: >>>>>>> >>>>>>> Hi, >>>>>>> That sounds good ! >>>>>>> Just one question, instead of using the callApi function couldn't >>>>> we >>>>>>> pass the oauth module (called 'thing' in your example) to the >>>>> pipe >>>>>>> directly, using the 'authenticator' setting. Behind the >>>>> scene, the >>>>>>> pipe manager will append the oauth token to the query or add >>>>> the >>>>>>> bearer header ? >>>>>>> >>>>>>> >>>>>>> I'm not sure if that is what this is going to do. This is more of >>>>> an >>>>>>> Authorization thing and i don't think it totally fits the pipeline >>>>>>> stuff. ( or it would make it a bit more complicated, and we want >>>>> to keep >>>>>>> it simple ) >>>>>>> >>>>>>> >>>>>>> i should probably change the method to be "authorize" instead >>>>>>> >>>>>>> Seb >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Mon, Aug 26, 2013 at 8:05 PM, Lucas Holmquist > >> >> >>>>> wrote: >>>>>>> >>>>>>> >>>>>>> OAuth2 AeroGear Workflow - High Level >>>>>>> >>>>>>> >>>>>>> Using Google api's >>>>>>> >>>>>>> /Server Side/ >>>>>>> >>>>>>> 1. user needs to first create an "application/project" to >>>>> get an >>>>>>> api key >>>>>>> 2. Then they would choose the services/api's then would like >>>>>>> there application to access >>>>>>> 3. other google server related items.... >>>>>>> >>>>>>> /Client Side/ >>>>>>> >>>>>>> 1. Create a new OAuth2 module thing >>>>>>> 2. Get access token for the services would need to specify the >>>>>>> services they would like to access >>>>>>> 3. validate the token >>>>>>> 4. make calls to the service >>>>>>> >>>>>>> >>>>>>> API >>>>>>> >>>>>>> |var thing = AerGear.OAuth2({ >>>>>>> name: googleEndPoints, //Just a Name >>>>>>> clientID: "12345" //The client ID of the app from the >>>>>>> API console >>>>>>> settings: { >>>>>>> permissions: "..", >>>>>>> ... >>>>>>> } >>>>>>> }).somecoolmodulename.googleEndPoints; >>>>>>> | >>>>>>> >>>>>>> /Settings: Multiple settings based on paramters here >>>>>>> / >>>>>>> >>>>>>> /Methods/ >>>>>>> >>>>>>> >>>>>>> authenticate >>>>>>> >>>>>>> this will authenticate with the server to get the access token >>>>> and >>>>>>> then validate the token, once that is all good then the response >>>>>>> is returned. >>>>>>> >>>>>>> |thing.authenticate({ >>>>>>> success:{}, >>>>>>> error:{}, >>>>>>> settings: { >>>>>>> //probably some settings here, like URL overides and such >>>>>>> } >>>>>>> }); >>>>>>> | >>>>>>> >>>>>>> >>>>>>> callApi >>>>>>> >>>>>>> not really a good name, but it would basically call the remote >>>>>>> api/services. we could either do a query string option or a >>>>> Head >>>>>>> option >>>>>>> >>>>>>> example: >>>>>>> >>>>>>> |curl ' >>>>>>> https://www.googleapis.com/oauth2/v1/userinfo?access_token=1/fFBGRNJru1FQd44AzqT3Zg' >>>>>>> | >>>>>>> >>>>>>> or >>>>>>> >>>>>>> |curl -H "Authorization: Bearer {accessToken}" >>>>>>> https://www.googleapis.com/oauth2/v1/userinfo >>>>>>> | >>>>>>> >>>>>>> code: >>>>>>> >>>>>>> |thing.callApi({ >>>>>>> service: "userinfo", //don't really like this name either >>>>>>> success:{}, >>>>>>> error:{}, >>>>>>> settings: { >>>>>>> ... //overridable baseURLs? >>>>>>> } >>>>>>> }); >>>>>>> | >>>>>>> >>>>>>> >>>>>>> revoke >>>>>>> >>>>>>> again, maybe not the best name. calls the "revoke" service, >>>>> to >>>>>>> remove access to permissions >>>>>>> >>>>>>> |thing.revoke({ >>>>>>> success: {}, >>>>>>> error: {}, >>>>>>> settings: {} >>>>>>> }); >>>>>>> | >>>>>>> >>>>>>> Behind the scenes on all these calls, the "access_token" is >>>>>>> beining used and possibly refreshed for the user, so they don't >>>>>>> have to worry about it. They just need to call authenticate >>>>> first. >>>>>>> Maybe we can have a refresh method if the user wants to refresh >>>>>>> the tokens themselves. this would do the token "dance" >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Aug 26, 2013, at 1:35 PM, Bruno Oliveira > >> >> >>>>> wrote: >>>>>>> >>>>>>> +1 I think is a good start to us. >>>>>>> >>>>>>> Kris Borchers wrote: >>>>>>> >>>>>>> I would like to see that but what you are saying makes sense. >>>>> It >>>>>>> sounds like where I was headed with the Basic and Digest >>>>>>> adapters before I ran into browser security issues with headers. >>>>>>> I think and authorization API that basically just wraps itself >>>>>>> around secured endpoints works for me. >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> 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 >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>> >>>> >>>> _______________________________________________ >>>> 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 From lholmqui at redhat.com Fri Dec 20 08:52:15 2013 From: lholmqui at redhat.com (Lucas Holmquist) Date: Fri, 20 Dec 2013 08:52:15 -0500 Subject: [aerogear-dev] OAuth2 Adapter In-Reply-To: <13E69CC3-9D1B-4EA9-A465-DCF359608AD5@gmail.com> References: <1C771957-D239-4BDB-B837-00A4A4E02702@redhat.com> <940734E6-6C13-49E7-B044-753E19300F7C@redhat.com> <2A3B92C8-430C-4BE2-BDCC-FB5867743898@redhat.com> <521B91D9.6040806@abstractj.org> <9A9EB7B1-64E7-40D8-8172-51623EDF2470@redhat.com> <521CD70D.9070502@abstractj.org> <8E6B69AB-3FB4-4486-B40A-7ED3CA7B9B7B@redhat.com> <4C215076-003F-4200-B316-14622036079A@redhat.com> <0EABA5A2-A352-40AD-9A91-2F929C4FE9C4@redhat.com> <0120B639-CA96-4BDD-94AB-5BFC4813BB48@redhat.com> <1A14D527-BD5D-4BB4-83ED-69B69B09625A@redhat.com> <13E69CC3-9D1B-4EA9-A465-DCF359608AD5@gmail.com> Message-ID: On Dec 20, 2013, at 8:37 AM, Corinne Krych wrote: > > On Dec 20, 2013, at 2:28 PM, Lucas Holmquist wrote: > >> cool >> On Dec 20, 2013, at 2:40 AM, Corinne Krych wrote: >> >>> Hello All, >>> >>> I've implemented OAuth2 for iOS [1]. I still need some cleaning/refactoring before sending a PR. >>> Following Lucas demo, I've tested it to display a list of your Google Drive files. You can test it here [2]. I will also do a PR for our ios-cookbook to add GoogleDrive app. >>> >>> Note that the implementation is not yet complete, we'll need to add: >>> -revoke >>> -refresh >>> >>> Main difference with js implementation is that I don't store permanently the accessTokens, I prefer to let the application developer decide whether or not the application should save the accessToken. OAuth2 interface is here [3] >> I'm still not sure this is a good idea on my part, it does help if the user refreshes the page, then they still have the token. >> >> although since the access token does expire, then it might not be to bad > > it's not a bad idea storing them as they have limited life ( I've read it's more the refresh token you should not store because this one last longer) well in JS there is no refresh token, since we are using "implicit" flow, but i thought if the app was installed, then you should store the refresh token for future use https://developers.google.com/accounts/docs/OAuth2InstalledApp you would only need to "refresh" the refresh token if the user revokes it > but I think this should be left to the developer to decide how he wants to deal with accessToken. Basically does the application prompt the user for authz at each load, or store the access token and prompt when expired etc.. That should be left to the developer. > > I would rather follow Authentication authToken strategy, we keep them in memory within authModule and pass them to the pipe. wdyt? > This part still need work on my side. > >> >>> >>> Managing OAuth callback into the application was the tricky point for Google+ as iOS implementation is poorly documented (I will add a section on Readme how to configure Google project etc?), Android version should be easier. >>> >>> ++ >>> Corinne >>> [1] https://github.com/corinnekrych/aerogear-ios/tree/AGIOS-138/AeroGear-iOS/AeroGear-iOS/security/Authorizer >>> [2] https://github.com/corinnekrych/GoogleDrive >>> [3] https://github.com/corinnekrych/aerogear-ios/blob/AGIOS-138/AeroGear-iOS/AeroGear-iOS/security/Authorizer/AGAuthzModule.h >>> >>> On Dec 19, 2013, at 1:49 PM, Luke Holmquist wrote: >>> >>>> https://github.com/aerogear/aerogear-js/pull/58 >>>> >>>> I reopened it >>>> >>>> Sent from my iPhone >>>> >>>>> On Dec 19, 2013, at 6:08 AM, Bruno Oliveira wrote: >>>>> >>>>> Do we have a PR for it? Works like a charm on chrome, didn?t went well for safari. But let?s start simple, attach a PR please, I?m anxious to test it. >>>>> >>>>> -- >>>>> abstractj >>>>> >>>>>> On December 19, 2013 at 6:45:14 AM, Sebastien Blanc (scm.blanc at gmail.com) wrote: >>>>>> >>>>>> I just tested the demo, very cool, work as advertised ;) >>>>>> >>>>>> >>>>>>> On Wed, Dec 18, 2013 at 8:45 PM, Lucas Holmquist wrote: >>>>>>> >>>>>>> i've created a new example here, >>>>>>> https://github.com/lholmquist/ag-google-drive >>>>>>> >>>>>>> that hopefully shows the flow a bit >>>>>>> >>>>>>>> On Aug 29, 2013, at 2:05 PM, Lucas Holmquist >>>>>>> wrote: >>>>>>> >>>>>>> i did get it to work >>>>>>>> On Aug 29, 2013, at 2:04 PM, Sebastien Blanc >>>>>>> wrote: >>>>>>> >>>>>>> This update is really cool, is the pipe test flow working ? >>>>>>> >>>>>>> >>>>>>>> On Thu, Aug 29, 2013 at 7:57 PM, Lucas Holmquist wrote: >>>>>>>> >>>>>>>> i've updated the sample again https://github.com/lholmquist/oauth2test >>>>>>>> >>>>>>>> this time i added a pipe object and used pipe.read to see how >>>>>> the flow >>>>>>>> would be >>>>>>>> >>>>>>>> >>>>>>>> On Aug 29, 2013, at 11:55 AM, Lucas Holmquist >>>>>>>> wrote: >>>>>>>> >>>>>>>> i've updated the sample app with the new flow >>>>>>>> >>>>>>>> https://github.com/lholmquist/oauth2test >>>>>>>> >>>>>>>> >>>>>>>> On Aug 29, 2013, at 9:23 AM, Lucas Holmquist >>>>>> wrote: >>>>>>>> >>>>>>>> ok, Kris had some thoughts on a better flow, so i refactored >>>>>> the code a >>>>>>>> bit and i think i like this way a bit better. >>>>>>>> >>>>>>>> New Flow - Client Flow - Standalone for now, possible integration >>>>>> with >>>>>>>> pipes First Time - No Access Token stored( in localStorage >>>>>> ) >>>>>>>> >>>>>>>> User will create the Authorization Object stuff with settings/options >>>>>>>> >>>>>>>> var thing = AeroGear.Authorization(); >>>>>>>> >>>>>>>> thing.add({ >>>>>>>> name: "coolThing", >>>>>>>> settings: { >>>>>>>> clientId: "12345.apps.googleusercontent.com", >>>>>>>> redirectURL: "http://localhost:8000/redirector.html", >>>>>>>> tokenValidationEndpoint: "https://www.googleapis.com/oauth2/v1/tokeninfo", >>>>>>>> authEndpoint: "https://accounts.google.com/o/oauth2/auth", >>>>>>>> revokeURL: "https://accounts.google.com/o/oauth2/revoke", >>>>>>>> scopes: "https://www.googleapis.com/auth/userinfo.profile", >>>>>>>> prompt: "force" >>>>>>>> } >>>>>>>> }); >>>>>>>> >>>>>>>> *should have the ability to specify more settings, based on >>>>>> the spec* >>>>>>>> >>>>>>>> The user would then call some method( currently not good names >>>>>> are coming >>>>>>>> to me, maybe validate ) that takes success and error callbacks. >>>>>>>> >>>>>>>> thing.services.coolThing.validate({ >>>>>>>> success: function( response ){ >>>>>>>> console.log( "Should be response from Validating the access >>>>>> token", response ); >>>>>>>> }, >>>>>>>> error: function( error ) { >>>>>>>> //should contain a constructed URL for the user >>>>>>>> console.log( "error", error ); >>>>>>>> } >>>>>>>> }); >>>>>>>> >>>>>>>> Since this is the first time, the error callback will be called >>>>>> and will >>>>>>>> contain the constructed URL that the user should do the popup >>>>>> redirect >>>>>>>> dance with to get an access token. >>>>>>>> >>>>>>>> *what "dance" they do is up to the developer* >>>>>>>> >>>>>>>> Once that happens and they have the access token, they would >>>>>> call the >>>>>>>> validate method again. >>>>>>>> >>>>>>>> this makes sure that the token they recieved is validated and >>>>>> will also >>>>>>>> return some other meta data related to the token, like refresh >>>>>> time. >>>>>>>> >>>>>>>> Once the token has been validated, it will be stored in localStorage >>>>>> and >>>>>>>> would be accessable with the key of ag-oauth2-whatever_the_client_ID_is >>>>>> . >>>>>>>> >>>>>>>> so in this example it would be something like: >>>>>>>> >>>>>>>> ag-oauth2-12345.apps.googleusercontent.com >>>>>>>> >>>>>>>> There is one problem i can see here though. If the user has to >>>>>>>> applications with the same client ID but different scopes >>>>>> assigned, this >>>>>>>> would be a problem. That use case could be considered bad practice >>>>>> anyway >>>>>>>> >>>>>>>> The user can then call the "callService"( yes, again, crappy >>>>>> name ) >>>>>>>> method to get access to the service they want. >>>>>>>> >>>>>>>> thing.services.coolThing.callService({ >>>>>>>> serviceURL: "https://www.googleapis.com/oauth2/v2/userinfo", >>>>>>>> success: function( response ){ >>>>>>>> console.log( "Should be the response from the call", response >>>>>> ); >>>>>>>> }, >>>>>>>> error: function( error ) { >>>>>>>> console.log( "error", error ); >>>>>>>> } >>>>>>>> }); >>>>>>>> >>>>>>>> All these methods would have success/error callbacks. >>>>>>>> Token Expiration >>>>>>>> >>>>>>>> If the user makes a call to a service, using the callService >>>>>> method, and >>>>>>>> they recieve an error such as not authorized or token invalid >>>>>> or token >>>>>>>> expired, I'm thinking we send what the "contructed URL" should >>>>>> be, similar >>>>>>>> to the validate method described above. >>>>>>>> >>>>>>>> Since this is a Client Side flow, there is no refresh token, >>>>>> so the >>>>>>>> client wouldn't be able to refresh the access token without >>>>>> doing the >>>>>>>> "dance" again. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Aug 27, 2013, at 1:57 PM, Lucas Holmquist >>>>>> wrote: >>>>>>>> >>>>>>>> i've hacked together a sample app that shows sort of the flow. >>>>>>>> >>>>>>>> https://github.com/lholmquist/oauth2test >>>>>>>> >>>>>>>> it is still very rough >>>>>>>> >>>>>>>> On Aug 27, 2013, at 12:42 PM, Bruno Oliveira >>>>>> wrote: >>>>>>>> >>>>>>>> +1 keep it simple, please >>>>>>>> >>>>>>>> Lucas Holmquist wrote: >>>>>>>> >>>>>>>> >>>>>>>> On Aug 27, 2013, at 3:39 AM, Sebastien Blanc > >> >> >>>>>> wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> That sounds good ! >>>>>>>> Just one question, instead of using the callApi function couldn't >>>>>> we >>>>>>>> pass the oauth module (called 'thing' in your example) to the >>>>>> pipe >>>>>>>> directly, using the 'authenticator' setting. Behind the >>>>>> scene, the >>>>>>>> pipe manager will append the oauth token to the query or add >>>>>> the >>>>>>>> bearer header ? >>>>>>>> >>>>>>>> >>>>>>>> I'm not sure if that is what this is going to do. This is more of >>>>>> an >>>>>>>> Authorization thing and i don't think it totally fits the pipeline >>>>>>>> stuff. ( or it would make it a bit more complicated, and we want >>>>>> to keep >>>>>>>> it simple ) >>>>>>>> >>>>>>>> >>>>>>>> i should probably change the method to be "authorize" instead >>>>>>>> >>>>>>>> Seb >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Aug 26, 2013 at 8:05 PM, Lucas Holmquist > >> >> >>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> OAuth2 AeroGear Workflow - High Level >>>>>>>> >>>>>>>> >>>>>>>> Using Google api's >>>>>>>> >>>>>>>> /Server Side/ >>>>>>>> >>>>>>>> 1. user needs to first create an "application/project" to >>>>>> get an >>>>>>>> api key >>>>>>>> 2. Then they would choose the services/api's then would like >>>>>>>> there application to access >>>>>>>> 3. other google server related items.... >>>>>>>> >>>>>>>> /Client Side/ >>>>>>>> >>>>>>>> 1. Create a new OAuth2 module thing >>>>>>>> 2. Get access token for the services would need to specify the >>>>>>>> services they would like to access >>>>>>>> 3. validate the token >>>>>>>> 4. make calls to the service >>>>>>>> >>>>>>>> >>>>>>>> API >>>>>>>> >>>>>>>> |var thing = AerGear.OAuth2({ >>>>>>>> name: googleEndPoints, //Just a Name >>>>>>>> clientID: "12345" //The client ID of the app from the >>>>>>>> API console >>>>>>>> settings: { >>>>>>>> permissions: "..", >>>>>>>> ... >>>>>>>> } >>>>>>>> }).somecoolmodulename.googleEndPoints; >>>>>>>> | >>>>>>>> >>>>>>>> /Settings: Multiple settings based on paramters here >>>>>>>> / >>>>>>>> >>>>>>>> /Methods/ >>>>>>>> >>>>>>>> >>>>>>>> authenticate >>>>>>>> >>>>>>>> this will authenticate with the server to get the access token >>>>>> and >>>>>>>> then validate the token, once that is all good then the response >>>>>>>> is returned. >>>>>>>> >>>>>>>> |thing.authenticate({ >>>>>>>> success:{}, >>>>>>>> error:{}, >>>>>>>> settings: { >>>>>>>> //probably some settings here, like URL overides and such >>>>>>>> } >>>>>>>> }); >>>>>>>> | >>>>>>>> >>>>>>>> >>>>>>>> callApi >>>>>>>> >>>>>>>> not really a good name, but it would basically call the remote >>>>>>>> api/services. we could either do a query string option or a >>>>>> Head >>>>>>>> option >>>>>>>> >>>>>>>> example: >>>>>>>> >>>>>>>> |curl ' >>>>>>>> https://www.googleapis.com/oauth2/v1/userinfo?access_token=1/fFBGRNJru1FQd44AzqT3Zg' >>>>>>>> | >>>>>>>> >>>>>>>> or >>>>>>>> >>>>>>>> |curl -H "Authorization: Bearer {accessToken}" >>>>>>>> https://www.googleapis.com/oauth2/v1/userinfo >>>>>>>> | >>>>>>>> >>>>>>>> code: >>>>>>>> >>>>>>>> |thing.callApi({ >>>>>>>> service: "userinfo", //don't really like this name either >>>>>>>> success:{}, >>>>>>>> error:{}, >>>>>>>> settings: { >>>>>>>> ... //overridable baseURLs? >>>>>>>> } >>>>>>>> }); >>>>>>>> | >>>>>>>> >>>>>>>> >>>>>>>> revoke >>>>>>>> >>>>>>>> again, maybe not the best name. calls the "revoke" service, >>>>>> to >>>>>>>> remove access to permissions >>>>>>>> >>>>>>>> |thing.revoke({ >>>>>>>> success: {}, >>>>>>>> error: {}, >>>>>>>> settings: {} >>>>>>>> }); >>>>>>>> | >>>>>>>> >>>>>>>> Behind the scenes on all these calls, the "access_token" is >>>>>>>> beining used and possibly refreshed for the user, so they don't >>>>>>>> have to worry about it. They just need to call authenticate >>>>>> first. >>>>>>>> Maybe we can have a refresh method if the user wants to refresh >>>>>>>> the tokens themselves. this would do the token "dance" >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Aug 26, 2013, at 1:35 PM, Bruno Oliveira > >> >> >>>>>> wrote: >>>>>>>> >>>>>>>> +1 I think is a good start to us. >>>>>>>> >>>>>>>> Kris Borchers wrote: >>>>>>>> >>>>>>>> I would like to see that but what you are saying makes sense. >>>>>> It >>>>>>>> sounds like where I was headed with the Basic and Digest >>>>>>>> adapters before I ran into browser security issues with headers. >>>>>>>> I think and authorization API that basically just wraps itself >>>>>>>> around secured endpoints works for me. >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> 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 >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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/20131220/84f299ac/attachment-0001.html From jbalunas at redhat.com Fri Dec 20 09:35:44 2013 From: jbalunas at redhat.com (Jay Balunas) Date: Fri, 20 Dec 2013 09:35:44 -0500 Subject: [aerogear-dev] Keycloak on AeroGear In-Reply-To: References: <43EF0C0F-8895-4AE0-B035-09F535D5139B@gmail.com> Message-ID: On Dec 20, 2013, at 8:14 AM, Bruno Oliveira wrote: > Keycloak already has the user management stuff, so I think is just a matter of play with it and check if it will meet our needs, if not, we can always suggest something at keycloak-dev. +1 > > Regarding hold or not, let?s not rush on it. At the moment my suggestion is to play with keycloak and check what?s missing. +1 as well. Review it, check integration and requirements, and then after the new year we'll figure out exactly when and how to integrate with keycloak. > > -- > abstractj > > On December 20, 2013 at 10:40:51 AM, Sebastien Blanc (scm.blanc at gmail.com) wrote: >>> Awesome ! >> But does it make sense for me to hold on the User Management stuff >> as that will also be migrated to KeyCloak ? >> Seb > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From daniel at passos.me Mon Dec 23 06:44:47 2013 From: daniel at passos.me (Daniel Passos) Date: Mon, 23 Dec 2013 09:44:47 -0200 Subject: [aerogear-dev] Team meeting Message-ID: Agenda:?http://oksoclap.com/p/OWv7EcIFqT -- ?Daniel Passos -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20131223/ca43e8e4/attachment.html From daniel at passos.me Mon Dec 23 10:16:37 2013 From: daniel at passos.me (Daniel Passos) Date: Mon, 23 Dec 2013 13:16:37 -0200 Subject: [aerogear-dev] Team meeting In-Reply-To: References: Message-ID: Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2013/aerogear.2013-12-23-14.52.html Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2013/aerogear.2013-12-23-14.52.txt Log: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2013/aerogear.2013-12-23-14.52.log.html --? Daniel Passos On December 23, 2013 at 9:44:47 AM, Daniel Passos (daniel at passos.me) wrote: Agenda:?http://oksoclap.com/p/OWv7EcIFqT -- ?Daniel Passos -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20131223/464c4177/attachment.html From bruno at abstractj.org Fri Dec 27 08:19:58 2013 From: bruno at abstractj.org (Bruno Oliveira) Date: Fri, 27 Dec 2013 11:19:58 -0200 Subject: [aerogear-dev] AeroGear Crypto Java 0.1.2 released Message-ID: Good morning, just to let you know we released today the bits for digital signatures and some bug fixes. Have a happy new year sweet hearts. -- abstractj