After a short break and really busy time I have decided to put together this quick article which tries to put some light into the Session Management and maybe little about the authentication process within AribaWeb.
We will start with this simplified object collaboration diagram that captures the request/response process.
**The rectangles represent various objects, which are involved in the communication and the lines between these rectangles represent the relationships (association, composition, dependencies or inheritance) between them. Messages are shown as a labeled arrow that indicated direction of the message.
Request / Response process - Simplified collaboration diagram
On the picture above the AWDispatcherServlet dispatches the request depending if it's Direct or Component action into AWRequestHandler impl. class. It then continues down to the AWPage. I think the most interesting part is in the AWRequestContext class which is in the middle of this process where:
- It initiates the checks for request as well as the session
- Here is the place where your security starts because it calls validation methods from your AWComponent and SessionHandler where you can decide if your session is valid. If you decide that is not valid you can kick user back to your defined login page (showLoginPage() method)
- We can also say that from this context AW starts the execution of all three phases (applyValues, invokeAction, renderResponse) even the code itself is inside the AWRequestHandler.
Let's check out some example.We will continue from my last example where I showed you how to layout your application and do not rely on the flat project structure. So this is my project.
I think the explanation for this layout was already written in my previous articles. But lets focus for now on the WebApplication class that registers custom session validator.
I usually register the session validation logic inside my application (the subclass of the AWServletApplication) just like on the picture bellow. In this case we have SessionHandler called MyLoginSessionhandler.
There are three empty methods for which you should provide your own implementation. The first method requireSessionValidationForAllComponents() turns on/off your validation logic and in this step we are telling the AW that we do not want to validate a session therefore we always jump directly into the app homepage.
What if we want to implement some authentication and have custom login page to be shown if the user is not properly authenticated. It's pretty simple to do because if you remember the diagram on the top we are going to attach our functionality to the process that is invoked by AWRequestContext in the handleRequest() method. And this functionality is going to be enabled inside our MyLoginSessionHandler and our LoginPage.
First thing to do is to enable the validation for the components with the requireSessionValidationForAllComponentActions() method and then return the LoginPage for the invalid session. In this case we modified the code the step above (see pic. bellow) and now we always show the LoginPage because the method validateSession() returns false.
Our LoginPage component should also override the shouldValidateSession() method to turn off the validation completely for this LoginPage.
This all cannot really work without storing user specific information into session. This is usually done inside the AWSession that wraps the http session. This is perfect place to store current user or his/her username or anything you do not want to load every time user clicks on the button.
And the login() method logic can look like this:
- It resets the Navigation Bar state
- Initialize the session
- Redirect the request back to the homepage
Once we have this code in place we can modify the SessionHandler to use our new session class. As you can see this is our third modification of this class and now with proper code.
Logoff action is going to be really simple. When we decided to use the AWSession we must also follow its rule how the session is closed. For this reason AWSession has method terminate() which does not destroy the session immediately but at the end of the cycle but also does clean up many things.
Note: Please never call invalidate() on the HttpSession. The reason is simple while AW is trying to render the page it is still using the session and trying to read some stored information from it and when you do invalidate it's gone and your app fail to render the page.
Other areas to investigate:
Please see this as a pure introduction and if you are serious about the authentication you want to check out how the AWLocalLoginSessionHandler.CompletionCallback works. You will find out that at the end there is something called AWFormRedirect which is also used allot when you are using direct actions.
Source code from this article on the request: email@example.com