Hi Frank,
It's been a few months now, still waiting if the explanation was clear or
not ;)
Kind regards,
Arjan Tijms
On Sun, Aug 9, 2015 at 9:08 PM, arjan tijms <arjan.tijms_at_gmail.com> wrote:
> 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
>