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()%>/getmyservice.do?id=${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/getmyservice.do?id=my-very-secret-information";>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/getmyservice.do?id=some-other-information
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: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
