Best strategy to handle page navigation in JSP

Question

I am exploring JSP to implement dynamic web pages. One issue to solve is navigation between pages. Users have the possibility to go back and forward in their browsers.

This has to be handled. If someone logs out (for example), we don't want someone else to retrieve the session or data by clicking 'go back'. Another example is that we don't want to resubmit forms twice.

I am looking for tips and advices to solve page navigation issues. I would like to create a list of issues one has to take care of + possible solutions:

Issues:

Making sure sessions cannot be retrieved/hijacked with go back/forward clicks
Making sure forms and not submitted twice
Making sure users cannot fiddle cookies or URL data or hidden fields to break control flow and security

Solutions:

Implement a stack of visited pages
When a page is invoked, register the moment it is displayed to differentiate new requests from 'go back'
Control current session

P.S.: I have seen this question, but there is no real answer to it.

@jimy No not really. In JSP, you can mix Java with HTML. When you display a JSP page, the java part can decide to display something different each time it is invoked. Problem is that user can navigate forward and backward. — Jérôme Verstrynge, Jun 15 '11 at 05:11
Are you using only JSP pages on purpose? Are you aware that even though you can write Java code (= scriptlets) inside JSP pages, it is often discouraged as JSP is mostly used as a "dumb" view component which just displays whatever gets passed to it from the actual business logic from backend (i.e. servlets, MVC controllers etc). — deltaforce2, Jun 15 '11 at 05:48
@deltaforce2 I have a lot of operational Java code which I want to use for a web application. I find JSP attractive, because it mixes HTML & Java. Now, maybe I need to invest time in reading about frameworks such as Struts. — Jérôme Verstrynge, Jun 15 '11 at 06:27

Buhake Sindi · Answer 1 · 2011-06-15T05:49:40.370

To prevent double submission, I will use an example Apache Struts 1 used by using HttpSession.

What Struts did was to generate a random token that is stored in a session and added in a form page in a presentation layer (JSP). When a user submit a form, it checks from the session to see if the token given by the form is exactly the same session found in the session. If it's true, then process the request else it's a double submission.

Example:

public class AuthenticationAction extends Action {

    public void displayLogout(ActionMapping mapping, ActionForm form,
                        HttpServletRequest request, HttpServletResponse response) throws Exception {

        saveToken(request);
        return mapping.findForward("displayLogout");
    }

    public ActionForward doLogout(ActionMapping mapping, ActionForm form,
                        HttpServletRequest request, HttpServletResponse response) throws Exception {

        if (isValidToken(request)) {
            //It wasn't yet a double submission, delete token generated by Struts
            resetToken(request);
            //logout.
            ...
            //return back home
            return mapping.findForward("home");
        } else {
            //Double submission..
            throw new Exception("double submission");
        }
    }
}

A better tutorial is found here.

I also found this: http://www.visualbuilder.com/jsp/struts/tutorial/struts-solution-to-duplicate-form-submission-%28token-mechanism%29/ — Jérôme Verstrynge, Jun 15 '11 at 07:35

score 1 · Answer 2 · answered Jun 15 '11 at 09:30

1

Hmm, you can also use the Spring Webflow framework if you want, but the use of the back and refresh not submitting your forms twice can easely be solved by defining your controller right. I think the use of REST can also help solve some problems.

The hiddenfield manipulation is another thing since a hiddenfield can always be viewed in the source of your page. And if the field can be viewed then it is open to manipulation.

answered Jun 15 '11 at 09:30

Lyrion

426
6
21

I think REST is an over-engineered technology... but for the rest (bad pun) I am +1... – Jérôme Verstrynge Jun 15 '11 at 10:44

score 1 · Accepted Answer · edited Jun 20 '20 at 09:12

1

Making sure sessions cannot be retrieved/hijacked with go back/forward clicks

Just disable browser cache of those pages. See also Prevent user from seeing previously visited secured page after logout.

Making sure forms and not submitted twice

Generate a long, unique and impossible-to-guess string, store it in both the session ..

String token = UUID.randomUUID().toString();
((Set<String>) session.getAttribute("tokens")).add(token);
request.setAttribute("token", token);
request.getRequestDispatcher("/WEB-INF/page.jsp").forward(request, response);

.. and as a hidden input field of the form.

<input type="hidden" name="token" value="${token}" />

Upon submit, compare and remove the key in the session. If it was in the session, then proceed with submit.

if (((Set<String>) session.getAttribute("tokens")).remove(request.getParameter("token")) {
    // Valid token. Proceed with submit.
} else {
    // Invalid token. Possible double submit.
}

Making sure users cannot fiddle cookies or URL data or hidden fields to break control flow and security

Just write robust code yourself or use an existing and robust MVC framework like JSF2, Spring-MVC, Struts2, etc.

Solutions:

Implement a stack of visited pages

When a page is invoked, register the moment it is displayed to differentiate new requests from 'go back'

Control current session

Cumbersome.

edited Jun 20 '20 at 09:12

Community

1
1

answered Jun 15 '11 at 11:58

BalusC

1,082,665
372
3,610
3,555

Just a little question about the hidden field, now even like that if i check the source code before submit i can still see what the token was or is? And upon submit and such, this means you need to have ahead of knowledge which tokens there will be, and if you have them in a session why not use the session instead of the hidden field? – Lyrion Jun 15 '11 at 12:49
@Rafael: truly you can see it. I don't see how that's a problem. As to using the session exclusively, how would you use the session to prevent double submits? Invalidate it on every submit or something? That's plain cumbersome. Also, how would you take the possibility into consideration that the user has multiple windows/tabs open in the same session? – BalusC Jun 15 '11 at 12:55
All i am basicly saying if someone is able to see the hidden field he can still break the flow of things. And to prevent double submits it all depends on what kind of website it is. If it's for example a sales website, let them paying double isn't that bad ;) – Lyrion Jun 15 '11 at 13:10
1

@Rafael: The worst thing which can happen is that the form won't be submitted because the token is invalid. I'm not sure how that is bad since it's the enduser itself who caused this. – BalusC Jun 15 '11 at 13:19

score 0 · Answer 4 · answered Jun 15 '11 at 07:42

0

To avoid re-inventing the wheel, using an existing framework seems to be the best solution. Struts looks like a good candidate. A simple introduction tutorial is available.

answered Jun 15 '11 at 07:42

Jérôme Verstrynge

57,710
92
283
453

1

Struts 2 is a newer framework to Struts. I have never used it but make sure it helps with your double submission problem. – Buhake Sindi Jun 15 '11 at 07:49

Best strategy to handle page navigation in JSP

4 Answers4