Actually, a more important thing to do would be to GET RID OF THE LOGIN URL!!!
This is a primary weakness on most Do-it-Yourself security systems. Many - probably most - of them expect people to use the system honestly. Bad Guys aren't honest, and they'll bypass the login page in a heartbeat if it gets them to the goodies.
Unless you have a nice big security budget and a bunch of paranoid professionals to ensure that each and every thing ever done to the webapp over its entire lifespan is secure, you're far better off using the
J2EE builtin container-managed security system.
You do this be defining the login/loginfail JSPs in web.xml. These pages are never directly referenced by URL, Instead, when a user attempts to access a secured URL, the server takes over and presents the login page. Only if the login succeeds will the application forward to the application JSP and code. Otherwise the server will block the attempt and no URL games will get around it.
That will address the security problems and the best thing about it is that no application coding is required to make it work.
Of course, if you have a "page 2" that requires data from "page 1", that's not a security issue, it's a workflow issue. About the best you can do on that is to make page 2 reject any attempts to operate on missing data - possibly by redirecting to page 1 if the required info wasn't set up. The ability to directly access web pages can be a problem, but it's also a blessing, since directly-accessible pages can be bookmarked so that frequently-used functions can be rapidly accessed. When augmented by container-managed security, you can make an app both flexible AND secure.