Re: [aerogear-dev] [forge-dev] Aerogear.js for CRUD
by Lucas Holmquist
On Dec 17, 2013, at 4:25 AM, Sebastien Blanc <sblanc(a)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.
this should really be handled on …
[View More]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(a)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(a)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(a)redhat.com> wrote:
>>
>>> Adding forge-dev.
>>>
>>> ----- Original Message -----
>>>> From: "Burr Sutter" <bsutter(a)redhat.com>
>>>> To: "AeroGear Developer Mailing List" <aerogear-dev(a)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(a)redhat.com >
>>>> wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ----- Original Message -----
>>>>
>>>>
>>>> From: "Lucas Holmquist" < lholmqui(a)redhat.com >
>>>> To: "AeroGear Developer Mailing List" < aerogear-dev(a)lists.jboss.org >
>>>> Cc: "Vineet Reynolds Pereira" < vpereira(a)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(a)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(a)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(a)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/burr...
>>>> 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(a)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(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>> _______________________________________________
>>> forge-dev mailing list
>>> forge-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>
>>
>> _______________________________________________
>> forge-dev mailing list
>> forge-dev(a)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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>
>>
>>
>> _______________________________________________
>> forge-dev mailing list
>> forge-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/forge-dev
>
> _______________________________________________
> forge-dev mailing list
> forge-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
[View Less]
11 years, 3 months
Re: [aerogear-dev] [forge-dev] Aerogear.js for CRUD
by Vineet Reynolds Pereira
----- Original Message -----
> From: "Sebastien Blanc" <sblanc(a)redhat.com>
> To: forge-dev(a)lists.jboss.org, aerogear-dev(a)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
…
[View More]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(a)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(a)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(a)redhat.com >
> wrote:
>
>
>
>
> Adding forge-dev.
>
> ----- Original Message -----
>
>
> From: "Burr Sutter" < bsutter(a)redhat.com >
> To: "AeroGear Developer Mailing List" < aerogear-dev(a)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(a)redhat.com >
> wrote:
>
>
>
>
>
>
> ----- Original Message -----
>
>
> From: "Lucas Holmquist" < lholmqui(a)redhat.com >
> To: "AeroGear Developer Mailing List" < aerogear-dev(a)lists.jboss.org >
> Cc: "Vineet Reynolds Pereira" < vpereira(a)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(a)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(a)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(a)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/burr...
> 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(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> _______________________________________________
> forge-dev mailing list
> forge-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
>
>
> _______________________________________________
> forge-dev mailing list
> forge-dev(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
>
>
>
> _______________________________________________
> forge-dev mailing list forge-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
>
>
> _______________________________________________
> forge-dev mailing list
> forge-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
[View Less]
11 years, 3 months
Fwd: Password reset 0.1.0
by Sebastien Blanc
Sorry, just realized I replied only to AbstractJ and not the list.
---------- Forwarded message ----------
From: Sebastien Blanc <scm.blanc(a)gmail.com>
Date: Fri, Dec 13, 2013 at 6:38 PM
Subject: Re: [aerogear-dev] Password reset 0.1.0
To: Bruno Oliveira <bruno(a)abstractj.org>
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.…
[View More]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/t...
- 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 <scm.blanc(a)gmail.com>wrote:
>
>
>
> On Thu, Dec 12, 2013 at 12:56 PM, Bruno Oliveira <bruno(a)abstractj.org>wrote:
>
>> There we go answers inline.
>>
>> --
>> abstractj
>>
>> On December 12, 2013 at 8:35:26 AM, Sebastien Blanc (scm.blanc(a)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(a)doe.xn--com-9o0a 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 !
>
>
>
[View Less]
11 years, 3 months
