On Nov 10, 2008, at 4:59 PM, Julio Faerman wrote:
> On Mon, Nov 10, 2008 at 1:31 PM, Paul Sandoz <Paul.Sandoz_at_sun.com>
> wrote:
>> Hi Julio,
>>
>> It is a good start but there are two issues:
>>
>> 1) When you log in you should be redirected to a URL specific to
>> the user:
>>
>> e.g.: http://www.govdigital.com.br:9090/shopping-webapp/app/user/JohnDoe
>>
>> then that URI would be the base URI for stuff related to the
>> shopping
>> cart, but
>> not for the items you need to add.
>
> I tried to avoid a aditional security check. As i have the Principal
> from SecurityContext, i do not need the username in the URL, and so i
> do not have to worry about someone trying to get another user's
> context. Does this make sense?
>
I don't think you are viewing it from the perspective of a resource
and resource state. Do you have the RESTful Web services book? I
highly recommend it, as it has good explanations of the aspects we are
discussing.
>> 2) The URIs have verbs in them like "add" and "delete" and when a
>> GET is
>> performed the action is not safe and
>> not idempotent (repeatable with the same result). Imagine if i
>> had a
>> grease monkey script in Firefox that
>> traversed all the URLs in the HTML and performed a GET under the
>> correct
>> assumption that it should be safe
>> to do so.
>>
>> You could have the following resources:
>>
>> Shopping Car item: /item/{item}
>>
>> User: /user/{userName}
>>
>> User Shopping Cart: /user{userName}/cart
>> POST # add an item to the shopping cart
>> item = /item/{item}
>>
>> User Shopping Cart Item: /user{userName}/cart/{item}
>> DELETE # delete an item from the cart
>
> Understood,
> But if so, all links will have to post forms or fire ajax requests,
> right? Isn't a lot to ask from every "command" link?
I think it is reasonable in terms of describing how the client makes a
state change to the application. How does the client know that a link
is a command link or not? There should be no such thing as a command
link :-) How best to do that with HTML/CSS/JavaScript and the browser
is up to you :-)
> To use buttons, i
> would need multiple forms, as the HTTP method is specified in the
> form, not in the button.
>
I think so.
> I am thinking about creating a page for each style (ajax and forms),
> good idea?
Not sure.
>
> Should the javascript be "by hand" or something more practical and
> probably more usefull, like jquery or prototype?
I don't have much experience on the client side with JavaScript but i
suspect something like jQuery would help a lot.
>
>
>> A general issue is how to log out. I am not actually sure. I do not
>> know if
>> it is possible to browse my authenticated sessions in Firefox.
>> Ideally a
>> button on the web page would interact with the browser through some
>> standard
>> API.
>
> I read that a 401 response should log me out,
I think that is a response to an unauthorized request:
http://greenbytes.de/tech/webdav/rfc2616.html#status.401
> but that did not worked
> for me, and even if it did, i think it would be browser specific. As i
> am using container managed auth, i am looking for a standard JEE way
> to log out.
>
This is probably one of the draw backs of HTTP basic auth. I think it
requires a different auth mechanism where by the server can invalidate
the authentication of a user.
Paul.