1

My boss asked me to alter our Java Webapp such that users cannot go to places in our Webapp by typing URLs into their browser location bar.

I told her that I can not disable their location bars.

I told her the way this is usually done is to launch a WebApp in a new customized browser window sans a location bar.

That was not acceptable to her.

I already have a Java Filter class set up to enforce various rules. So, I was thinking of this approach

  1. Implement a system wide "writeFlagCookie" javascript function to write a cookie anytime a user initiates a GET by clicking on a link or a button.

  2. Everywhere the WebApp does a redirect or a forward, put a flag variable, say "wasRedirected" into the HTTP session.

  3. In my Filter, intercept each request and check for the request type.

  4. If it is a POST, I know a human didn't type the URL into their browser, so I automatically let it through.

  5. If it is a GET, look for a javascript generated cookie, or the flag stored in the session to indicate a redirect or a forward. If I find neither send the user back to the page they just tried to leave from.

Though it will be a lot of work, it sounds too simple to be adequate.

Is there anyway this approach can bite me in the ass?

My boss wants two problems solved

  1. Users going to screens out of sequence and getting error messages. This includes multi-screen forms ( which we have to keep ) and users using a back button.

  2. Preventing the user from leaving particular pages and going to other parts of the application until they fill out what we want them to fill out on those screens.

I have ideas how to solve #1 & #2, also laborious, but my boss likes the idea of disabling typing URLs for navigation for a catch-all solution.

Maybe once she sees how much work is involved in disabling typed navigation I can market her on just solving those problems.

Thanks

Steve

Steve
  • 121
  • 1
    Do they have a session? Can you store the (current) page in the session? Can you define the list of acceptable previous pages in the current page? Does it matter if they login to the main page and then go to a bookmark of an acceptable page from the main page? Also... What is the business problem that is attempting to be solved? (Disable the location bar is a do this solution, which may not solve the actual problem - see What is the XY problem?) –  May 08 '13 at 20:48
  • I edited my original post per your comment. Thank You. – Steve May 08 '13 at 21:05
  • 1
    @MichaelT: I think you have hit the nail on the head - disabling the nav. bar is a band-aid on a broken bone. If you apply enough band-aids it might help for a short time, but better to put it in a cast...... – mattnz May 09 '13 at 04:58

2 Answers2

4

Apart fro "one-page design", the other common way this is accomplished is via means of a session identifier (which generally prevents users from saving a bookmark and coming back to it; tabbed browsing may or may not be prevented depending on browser implementation), coupled with a "request token". All links in each page served to the browser that redirect within the application have a query string with a GUID (or the GUID's stored in ViewState to make it completely inaccessible), which was generated by the server when rendering the page.

The server remembers this GUID and the page last served in the session store, and if a request comes from that session that does not have a request token or doesn't have the right one (indicating the user's been using their back/forward buttons), the user is directed to a simple page telling them politely not to do that, with a link back to the last page the server actively served them. Therefore, in order to successfully jump around using the location bar, the user must be smarter than the average bear and include the token in their hand-typed request.

This is a little simpler to implement in an existing multi-page architecture than moving to one-page (IMO a pretty serious redesign), and follows the 80/20 rule of keeping the vast majority of your users honest with minimal effort; the other 20% will need more advanced anti-tampering, possibly by remembering the available links of the current page and performing the same redirect if they are going somewhere they couldn't have gotten to with a link, with or without the correct GUID.

KeithS
  • 22,104
  • "or the GUID's stored in ViewState to make it completely inaccessible". I'm using Java & Spring/JSPs. Would you know if there is something similar to a viewstate in that platform that I can use to make the GUID invisible? – Steve May 09 '13 at 03:11
  • Spring MVC's Webflow apparently has some ViewState-mimicking components. You can also simply create a form with a hidden field containing the GUID, and make all links perform a submit action to send it to you. – KeithS May 09 '13 at 04:00
  • Keith you have given me ideas for several options I did not have before. Thank you so much. – Steve May 09 '13 at 15:44
2

I think you might be talking about single page design, where the HTML is loaded from the server for the home URL, but all navigation is performed via AJAX requests. This prevents the history of the browser from changing, and the user has no other URL they can navigate too.

One Page Design

MSDN One Page Design

Community
  • 1
Reactgular
  • 13,080