jsr372-experts@javaserverfaces-spec-public.java.net

[jsr372-experts] Re: [servlet-spec users] [jsr369-experts] Working towards Early Draft Review

From: arjan tijms <arjan.tijms_at_gmail.com>
Date: Sun, 9 Aug 2015 21:08:57 +0200

Hi,

On Sunday, August 9, 2015, Frank Caputo <frank_at_frankcaputo.de> wrote:

> > Currently it's quite hard in JSF to do a login-and-continue for JSF
> > AJAX requests. Would be great to have a solution for that.
>
> I don’t understand exactly, what you mean. Can you provide an example?
> Then I’ll see, if I can do something.


Sure. I'll first explain how it normally works in a non-AJAX scenario.

1. A user has protected view A open.
2. While having this view open the session expires or the user is
logged-out from another tab/window.
3. The user clicks on a button that causes a postback to A to happen.
4. The authentication system notices the user is not authenticated (not
logged-in) and that view A is protected.
5. The authentication system safes the full request data and writes a
login-in page to the response
6. The user authenticates
7. The authentication system redirects the user to view A and restores the
original request data

Now consider AJAX:

Current variant A:

1. A user has protected view A open.
2. While having this view open the session expires or the user is
logged-out from another tab/window.
3. The user clicks on a button that causes an AJAX request to A to happen.
4. The authentication system notices the user is not authenticated (not
logged-in) and that view A is protected.
5. The authentication system safes the full request data and writes a
login-in page to the response.
6. The JSF AJAX handler doesn't understand the login-page response and
hangs or crashes.

Current variant B:

1. A user has protected view A open.
2. While having this view open the session expires or the user is
logged-out from another tab/window.
3. The user clicks on a button that causes an AJAX request to A to happen.
4. The authentication system notices the user is not authenticated (not
logged-in) and that view A is protected.
5. The authentication system safes the full request data and writes a JSF
redirect directive to the response.
6. The user authenticates.
7. The authentication system redirects the user to the AJAX request(!) and
restores the original request data.
8. The user gets to see a nice full screen XML partial response.

As you may understand, both letting the AJAX handler crash or showing the
user a piece of XML is not so nice.


So what should happen:

1. A user has protected view A open.
2. While having this view open the session expires or the user is
logged-out from another tab/window.
3. The user clicks on a button that causes an AJAX request to A to happen.
4. The authentication system notices the user is not authenticated (not
logged-in) and that view A is protected.
5. The authentication system writes a JSF AJAX directive to the response
indicating that the view requires separate authentication (http's 401 and
403 are not entirely correct here).
6. The JSF AJAX handler understands the directive, saves the previous
request and opens a child window.
7. A login-in page is displayed in the child window.
8. The user authenticates.
9. The child window sends a signal to its parent window.
10. The AJAX handler catches this signal and repeats the same request again.

I hope it's more clear now. Let me know if there are further questions.

Kind regards,
Arjan Tijms