tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kiran Badi <>
Subject Re: URL Rewriting
Date Sat, 16 Jun 2012 01:28:46 GMT
Andre, I am a big fan of yours with the way you explain the things in 
neat way.Being a moderator/owner of some of large lists of my profession 
for close to 8 years now I rarely had this kind of patience to write so 
much and so neat.

BTW For the time being, I would prefer to keep this thread on hold 
though point d is something I can experiment with.

Give me sometime to think about to redesign this piece of code.

On 6/15/2012 3:53 AM, André Warnier wrote:
> Kiran Badi wrote:
>> Please inline for my answers Andre.
>> Kiran,
>>> Why does that "id=17" visible in the URL bother you ?
>>> Is it because of some security aspect ? (that the user could change 
>>> it, and get something else than what they should be getting ?)
>> Thanks for reminding this aspect.I was not checking for empty 
>> resultset in my code.Fixed that one now.:)
>>> 1) If that is the case, then the basic logic of your application is 
>>> flawed.  If this is information that really needs to be sent by the 
>>> browser to the server, then the browser must have that information. 
>>> And if that information originally comes from the server and is sent 
>>> to the browser, then there is /nothing/ that you can do to block 
>>> some user from playing around with it, before sending it back to the 
>>> server.
>>> If you do not want the user to be able to play around with some 
>>> information, then don't send it to him in the first place. O
>> Ok let me share the way I wrote this piece,
>> href="<%=request.getContextPath()%>/${myid}"> , 
>> this is link basically where I append the id(id comes from DB) send 
>> this to the servlet and it the pulls the records from db for 
>> corresponding id and then sends it back again to JSP for display.But 
>> I am not able to figure out as why I not getting the url of jsp 
>> something like
>> http://localhost:8080/ourstory/myiddata.jsp
>> .So thought that let me try to rewrite the url in case if its possible.
>>> 2) if the browser /must/ send some information to the server as part 
>>> of the URL, then there is /nothing/ that can be done on the server 
>>> side, to stop the browser showing this information in the URL bar.
>>> To illustrate this :
>>> - imagine that the server sends a page to the browser, and this page 
>>> contains a link like :
>>> <a 
>>> href="http://localhost:8080/mysite/">click

>>> here</a>
>>> Then the user, just by moving his mouse above "click here", sees the 
>>> content of that link at the bottom of his screen, in the status bar, 
>>> right ?
>>> And the user can right-click on "click here", and choose "copy link 
>>> location".
>>> And then the user can open another browser window, and paste this 
>>> URL in the URL bar.
>>> And then the user can modify this link before hitting the return 
>>> button, so that the link now looks like
>>> http://localhost:8080/mysite/
>>> right ?
>>> And all this happens in the browser, /before/ the server even sees 
>>> this browser request.
>>> So what could the server do ?
>> This is interesting information,how about sending the info as POST 
>> rather than Get.Not sure if I can convert clicking of the link from 
>> get from post.but I will try.But again the place where I am 
>> displaying the generating the links, is not within form, they just 
>> hyperlinks with id appended to it.
>> Now I know both get/post can be broken if one wants it,thats all 
>> together is different case,but for now I need tidy and clean url with 
>> no id appended to it.
>> Does my requirement makes sense ?
> Since you ask it that way, the answer would be no.
> Step 1 : the browser contacts the server via a request with some URL 
> (doesn't really mater which one at this stage, but in this first step 
> there is no "id" yet).
> Step 2 : the server does something with that request, and returns some 
> response to the browser.  In this response, somewhere, the "id" to use 
> in step 3 must be mentioned, or some other way to retrieve the id.
> Step 3 : the browser sends another request to the server, in which 
> this "id" parameter must be included (or some other way for the server 
> to retrieve the correct id).
> Step 4 : the server receives this second request, retrieves the id, 
> and does something useful with it.
> Now, at step 3, if the browser must include this "id" value in the 
> request, it must include it somewhere.  This "somewhere" can be :
> a) in the URL of a hyperlink.  In that case, the user will see the id 
> parameter in the hyperlink, and in the browser URL bar when the user 
> clicks the hyperlink.
> b) in the body of the request. In this case, the user would not see 
> the id parameter in the URL at step 3.  But it also means that the 
> request in step 3 must be a POST request.
> That is typically done with a
> <form method="POST" action="/the/url/to/which/this/is/posted">
> ...
> <input type="hidden" name="id" value="my-id-value" />
> ...
> </form>
> You cannot do that with a simple hyperlink. Clicking a hyperlink sends 
> a GET request, not a POST request. And GET requests do not have a body.
> It also means that the server, at step 2, must compose and send this 
> html page to the browser, with the <form> in it, and the hidden "id" 
> parameter.
> It also means that the user can, after step 2, do a "view page 
> source", and see the hidden "id" value.  The user can also save this 
> page to a disk file, edit it to change the hidden value, then recall 
> this file in the browser, and press the submit button.
> c) at step 2, the server could send the "id" parameter inside an 
> encrypted cookie. At step 3, the browser would send this cookie back 
> to the server.  The application on the server then needs to retrieve 
> this cookie (at step 4), decode it, and retrieve the "id" value from it.
> The user could still, after step 2, play tricks with the cookie and 
> change the "id" value, but it would be a lot more difficult (he would 
> have to decrypt the cookie, extract and replace the id value, 
> re-encrypt the cookie properly, and arrange to send it back to the 
> server), at step 3.
> If the encryption is well done, the server would detect that the value 
> of "id" has been modified.
> d) the server never sends the "id" value to the browser, thus 
> preventing the user to play tricks with it.  To achieve this, at step 
> 2 the server would create a session, and store the id value in that 
> session (on the server side). Then still at step 2 it would send back 
> to the browser a pointer to this session (for example, a JSESSIONID 
> cookie). At step 3 the browser would send back this session pointer to 
> the server, the server would retrieve the session, including the saved 
> "id" value.
> e) there may be more esoteric ways of having the browser send back the 
> id to the server, involving javascript functions on the browser side. 
> But for that, the browser has to receive the id from the server at 
> some point.  And that always means that it is insecure, because no 
> matter which way this is done, once the browser has it, the user can 
> always find a way to play with it.  The browser is under the full 
> control of the user (and what looks to the server as a browser, may 
> not even be a browser at all. Think of wget for example).
> (d) is the most secure method, and it is also the easiest to 
> implement, because Tomcat already has all the mechanisms in place to 
> create and store and retrieve sessions data. And it can work with a 
> simple hyperlink.
> (c) is as secure as the cookie encryption/decryption method is 
> secure.  It can also work with a simple hyperlink. But it is a lot 
> more complicated to set up.
> (a) is what you do not want
> (b) is moderately complex, and not secure
> To be complete, I should add that there exists a method (e), which (at 
> step 2) involves creating a pair of quantum-entangled photons on the 
> server side, and sending one of them to the browser. The browser would 
> send back this photon to the server at step 3 (without having looked 
> at it), and the server would then match it up with its twin, to 
> retrieve the appropriate id.  This requires a special extension to 
> websockets, thus at least Tomcat 7.
> Unfortunately, the details of this method are still classified and OT 
> on this list.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message