I am working on an issue that we need to protect the user from modifying the URL parameters (the QueryString is visible to the user and (s)he can modify the values in it). And in case he does modify the parameters - we need to trap that the page has been resulted due to url modification. There are a couple of approaches to it
a) Change all the get to posts - This, per me, is definately the fool proof approach. However, we have links in the sites (which passes on the parameters too), and thus we will have to use the hidden forms to achieve it.
b) Have an jsp level attribute, which traps the event of something happened on the page. However, in this approach the maintainability of the code is an issue (we need to be through with setting and unsetting of the parameter).
Can somebody help me out with what can be the best approach in such scenario
theres no way u can trap what happened in the address window. remember thats part of the browser and not the page u talkin bout.
You can't stop them changing what's in the URL, but you sure as hell can stop your servlet / JSP from processing a mangled request.
My usual approach to this is to create a set of classes which model request parameters that you EXPECT to get, in each servlet. There are a variety of patterns. E.g.
I can get EITHER
1 param called param1 with value val1
1-7 params called param2
1 param called param1 with value val2
1 param called param3 with value val3
YOu get the idea. YOu can capture this sort of stuff and put it in configuration (XML, or otherwise, whatever works.)
Then you write some helper classes that read this, and when they get a request, run it through this set of checks. AS SOON as it fails a check, the request is rejected (400 is the bad request HTTP response code)
THe classes typically check for:
* Expected parameters are present.
* Each parameter is of the right length, within the right range, of the right type, and there are the appropriate numbers of instances of them.
* No mutually exclusive parameter sets are present.
* No unexpected parameters are present.
With the new servlet filter spec coming out, this becomes extremely easy to implement as a filter in front of all requests for .jsp files. Perhaps I should drag out the old code and tidy it up.....something for a rainy day I think! :-)
Anyway, you get the idea. You can't stop the user fiddling with the browser, but you can make sure it doesn't blow up your code!