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?
> 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? To use buttons, i
would need multiple forms, as the HTTP method is specified in the
form, not in the button.
I am thinking about creating a page for each style (ajax and forms), good idea?
Should the javascript be "by hand" or something more practical and
probably more usefull, like jquery or prototype?
> 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, 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.
> Paul.
>
>
> On Nov 9, 2008, at 2:33 PM, Julio Faerman wrote:
>
>> I have deployed the discussed sample on:
>>
>> http://www.govdigital.com.br:9090/shopping-webapp/
>>
>> My goal was to show demonstrate some FAQs. Namely:
>>
>> Implicit MVC + static resources (img/css/js)
>> HTTP Basic Authentication
>> User context without HTTP Session
>>
>> It is VERY basic, but i am willing to improve it based on further
>> discussions. Your comments will be appreciated.
>> If it fails for any reason, please let me know.
>>
>> Julio
>>
>> On Fri, Nov 7, 2008 at 4:58 PM, Craig McClanahan
>> <Craig.McClanahan_at_sun.com> wrote:
>>>
>>> Julio Faerman wrote:
>>>
>>> Other point to consider is culture. Most developers stuff the sessions
>>> because they are used to, and have doing so since, say, ASP 2.0.
>>>
>>>
>>> Or servlet 2.0, which is now twelve years old.
>>>
>>> Or JSP, which creates sessions by default unless you tell it not to. :-)
>>>
>>> In AJAX apps, it gets a little harder to get rid of the session, as
>>> you need to fire smaller requests and do not want to keep track of
>>> session information across pages, with is not nice in javascript.
>>> Perhaps a new sample app with auth and stateless server, but with
>>> contextual data. I think i can contribute this. Would it be relevant?
>>> Any considrations or features that would be intersting to demonstrate?
>>>
>>>
>>>
>>> I think that would be awesome. Regarding structure, one thing I've seen
>>> in
>>> Ruby on Rails apps is the idea that your basic server side UI based
>>> webapp
>>> should follow exactly the same RESTful design principles, and then add a
>>> couple of methods to the controller to return the underlying data (for a
>>> particular page) in XML or JSON, instead of embedded in an HTML UI.
>>> Translated to Jersey terminology, that would mean using the same resource
>>> class for, say, a list of customers for the currently logged on sales
>>> person. If the client requests HTML they get the normal UI (which might
>>> have embedded javascript inside to perform Ajax calls later); if they ask
>>> for JSON or XML they just get the underlying data.
>>>
>>> Craig
>>>
>>> On Fri, Nov 7, 2008 at 11:26 AM, Paul Sandoz <Paul.Sandoz_at_sun.com> wrote:
>>>
>>>
>>> On Nov 7, 2008, at 1:58 PM, Julio Faerman wrote:
>>>
>>>
>>>
>>> I would like to discuss this further, i think it is a very common
>>> question. Let me try do defend some "statefulness".
>>>
>>> 1- The overhead of session management is questionable, as there are
>>> efficient persistence and replication mechanisms available in modern
>>> app servers. If we are talking about a sufficiently large number of
>>> server, the overhead is tolerable.
>>>
>>>
>>>
>>> It is yet another thing to manage and consider, especially when the
>>> deployment system changes. It makes it harder to route requests to the
>>> right
>>> set of machines each time. The implications of such session state can
>>> cross
>>> many boundaries in the layered and networked system, including clients,
>>> for
>>> example i cannot switch from buying an airline ticket on my laptop,
>>> bookmarking the URL, and switching to continue the process on my phone,
>>> perhaps in another country deferring to a bunch of servers close to my
>>> location for better performance.
>>>
>>>
>>>
>>>
>>> 2- The use of HTTP-Basic auth is less secure, specially if not using SSL.
>>>
>>>
>>>
>>> As the name suggests it is basic :-) but i would argue no less basic than
>>> many Web apps that send the password typed into the HTML form as part of
>>> the
>>> POST login message. Both have to be used with SSL.
>>>
>>>
>>>
>>>
>>> 3- The session helps a lot when the information the system should
>>> provide is contextualized to the authenticated user. For example,
>>> showing the accounts of the salesperson using the system. A stateless
>>> app would require additional authorization checks to perform the same
>>> operation.
>>>
>>>
>>> When you log in you have to authenticate and that authentication grants
>>> roles. Is that not independent of the authentication mechanism? The key i
>>> think is to ensure that the contextualized information is resource state
>>> identified by a URI associated with the user, or application state that
>>> is
>>> sent by the client to the server.
>>>
>>>
>>>
>>>
>>> I tried hard to keep my current project completly "stateless", and i
>>> agree on storing the minimum possible state in the session, but the
>>> benefits of a small session outweights the cost in most applications,
>>> IMHO.
>>>
>>>
>>>
>>> I understand, pragmatically i can see why this is so. As i said i think
>>> the
>>> tools/frameworks have made it easy to leverage sessions rather than other
>>> mechanisms that do not leverage sessions that make better use of URIs.
>>>
>>> Paul.
>>>
>>>
>>>
>>> On Fri, Nov 7, 2008 at 6:25 AM, Paul Sandoz <Paul.Sandoz_at_sun.com> wrote:
>>>
>>>
>>> Hi Craig,
>>>
>>> Well said! Further more you often find that some web sites will be hidden
>>> behind one URL. It is not book markable.
>>>
>>> The current state of affairs is this: at any one point in time how to do
>>> you
>>> know web sites you are logged into? how do you log out? the browser does
>>> not
>>> know really anything, because it is all opaque through server-given
>>> opaque
>>> identifiers, usually cookies.
>>>
>>> Would it not be nice for the browser, and therefore the user, to have
>>> more
>>> control over this? Utilizing HTTP authentication can enable this because
>>> the
>>> browser is aware of the authentication process. Unfortunately browsers
>>> today
>>> do a dreadful job popping up an ugly dialog box to login. I am sure there
>>> are ways to get nice login pages working with this type of mechanism but
>>> the
>>> frameworks and tools do not encourage this type of approach, thus the
>>> least
>>> path of resistance is to use a session, which can easily come to be a
>>> decision one might regret later on.
>>>
>>> Paul.
>>>
>>> On Nov 7, 2008, at 9:11 AM, Craig McClanahan wrote:
>>>
>>>
>>>
>>> Craig McClanahan wrote:
>>>
>>>
>>> Eduardo Pérez Ureta wrote:
>>>
>>>
>>> Ideally I would like to use the servlet session.
>>>
>>>
>>> I should have responded to this particular statement in my previous
>>> response (sorry for the omission). And it relates to some comments I
>>> *did*
>>> make that might not make a lot of sense without a little bit of context.
>>>
>>> One of the key principles behind RESTful APIs is that they should be
>>> *stateless*. In other words, if the server is implemented as multiple
>>> instances of your application behind a load balancer, it should not
>>> matter
>>> if the (n)th request and the (n+1)th request are served by different
>>> instances. This is a key attribute in designing an application that can
>>> scale beyond a single server instance.
>>>
>>> When you use servlet sessions, you are risking a violation of this basic
>>> principle. Let's assume that you are taking the typical approach where
>>> a
>>> cookie is used to tell the client what session identifier to submit on
>>> subsequent requests. The usual server side implementation of a
>>> "session" is
>>> essentially a HashMap of session attributes, keyed by the session id.
>>> But
>>> the *crucial* point is that this information normally lives only within
>>> the
>>> context of a single JVM (i.e. a single instance of your server).
>>> Supporting
>>> an application that scales horizontally (that is, across multiple server
>>> instances) would require that either:
>>>
>>> * the load balancer recognize that a subsequent request belongs to an
>>> existing session on a *single* instance of your application, which means
>>> you are likely to experience service overloads if this single instance
>>> has
>>> too many active sessions. (You will often see this referred to as
>>> "sticky
>>> sessions").
>>>
>>> * the server environment recognizes that there is an existing session,
>>> but
>>> the data for it lives on some other server instance so it needs to be
>>> copied
>>> to this instance before the request can be processed. As you can
>>> imagine,
>>> there can be significant overhead in doing this sort of thing.
>>>
>>> With respect to authentication (which was the particular context of
>>> Eduardo's questions), the standard HTTP approach is to include an HTTP
>>> header named "Authorization" with each request -- most typically using
>>> the
>>> HTTP Basic authentication scheme (http://www.ietf.org/rfc/rfc2617.txt).
>>> This means that the authentication operation must occur on *every*
>>> request,
>>> but it also means that you can indeed scale your application across
>>> multiple
>>> server instances, because any one of them is capable of performing the
>>> authentication transaction. You would be wise, if you are planning on
>>> an
>>> application that does, or even *might*, require deployment of more than
>>> one
>>> instance, to keep this consideration in mind.
>>>
>>> For a Java developer who doesn't want to care about all the nuances and
>>> complexities of the HTTP protocol, my recommendation is pretty simple --
>>> figure out how to design your application without using sessions. For
>>> authentication, that's pretty simple ... just include the authorization
>>> header on each request (for human-interaction web applications, browsers
>>> even do this for you if your server is designed for HTTP Basic
>>> authentication). For application state, everything that the server
>>> needs to
>>> know about the current state should be included with each request. (The
>>> details of this topic is the source of many thesis-length dissertations,
>>> but
>>> the fundamental principle is pretty easy to grok.)
>>>
>>> Or, of course, if you *know* your application will never need more than
>>> one instance (even to ensure availability in the case of an instance
>>> failure), you can safely ignore this advice. But can you really be
>>> sure?
>>> (For a 10-user departmental app behind your company firewall, sure you
>>> can.
>>> For an Internet facing app, no way IMHO. All it takes is a single
>>> "Slashdot Effect" surge of interest in your app, which overloads your
>>> single
>>> server instance, to demonstrate to you (and to the world, unfortunately)
>>> that you weren't ready for Internet scale user traffic).
>>>
>>> Craig
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
>