You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Kiran Badi <ki...@poonam.org> on 2012/06/13 05:21:10 UTC
URL Rewriting
Hi All,
For some of the functionality, I have url in the below format
http://localhost:8080/mysite/getmyservice.do?id=17
What I was looking for is to hide the id part of the url and just show
something like
http://localhost:8080/mysite/getmyservice.do#
Is this hack possible with tomcat 7.011 or 7.027 or I need to write some
filter to do this?
I have Tomcat 7.027 on win 7 home premium and url is generated via
servlet/jsp.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: URL Rewriting
Posted by Kiran Badi <ki...@poonam.org>.
Why are you so eager to remove the ids from the URL?
Thanks Chris for reply,It was looking ugly thats the reason.Anyways, now
that I have fixed most of gaps, I think I should be fine with this.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: URL Rewriting
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Kiran,
On 6/13/12 12:16 AM, Kiran Badi wrote:
> I have bunch of functionalities which are showing up with urls as
>
> http://localhost:8080/mysite/getmyservice.do?id=17 and I just need
> to hide them and show some neat url something like
> mysite/getmyservice.do without displaying parameters.
You need to send the id somehow: your options are GET (with 'id' in
the URL), POST (with 'id' in the POST body) or using something like
Javascript to communicate with the server so that the URL doesn't show
anything.
> Will hiding the url's cause any other issues ?
The downside to using POST is that pages cannot be (easily) bookmarked
by your users, and using the BACK button on the client becomes a
miserable user experience.
Why are you so eager to remove the ids from the URL?
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk/aMvEACgkQ9CaO5/Lv0PDTYACeKB4E2nw3+EqrtwTMIxpIDE/w
Rl0An0nV8HNxyT7O8+H4Nrw9PJ+J0m48
=T1zH
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: URL Rewriting
Posted by Oguz Kologlu <oz...@hotmail.com>.
Kiren
You'll need to pass in the id somehow.
Maybe something like:
/mysite/service/17
and use the URL rewrite filter to map it to
> /mysite/getmyservice.do?id=17
Have a look at the doco for more info
Should not cause any other issues.
Oz
On 13/06/2012, at 2:16 PM, Kiran Badi wrote:
>
> On 6/13/2012 9:18 AM, Oguz Kologlu wrote:
>> There is a handy URL rewrite filter already built.
>> http://www.tuckey.org/urlrewrite/
>>
>> You can hide the ID if you post the form but you need to be a bit more specific with what you want to do
>>
>> Oz
> Thanks Oguz,
>
> I have bunch of functionalities which are showing up with urls as
>
> http://localhost:8080/mysite/getmyservice.do?id=17 and I just need to hide them and show some neat url something like mysite/getmyservice.do without displaying parameters.
>
> Will hiding the url's cause any other issues ?
>
> - Kiran
>>
>> On 13/06/2012, at 1:21 PM, Kiran Badi wrote:
>>
>>> Hi All,
>>>
>>> For some of the functionality, I have url in the below format
>>>
>>> http://localhost:8080/mysite/getmyservice.do?id=17
>>>
>>> What I was looking for is to hide the id part of the url and just show something like
>>>
>>> http://localhost:8080/mysite/getmyservice.do#
>>>
>>> Is this hack possible with tomcat 7.011 or 7.027 or I need to write some filter to do this?
>>>
>>> I have Tomcat 7.027 on win 7 home premium and url is generated via servlet/jsp.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: URL Rewriting
Posted by Kiran Badi <ki...@poonam.org>.
On 6/13/2012 9:18 AM, Oguz Kologlu wrote:
> There is a handy URL rewrite filter already built.
> http://www.tuckey.org/urlrewrite/
>
> You can hide the ID if you post the form but you need to be a bit more specific with what you want to do
>
> Oz
Thanks Oguz,
I have bunch of functionalities which are showing up with urls as
http://localhost:8080/mysite/getmyservice.do?id=17 and I just need to hide them and show some neat url something like mysite/getmyservice.do without displaying parameters.
Will hiding the url's cause any other issues ?
- Kiran
>
> On 13/06/2012, at 1:21 PM, Kiran Badi wrote:
>
>> Hi All,
>>
>> For some of the functionality, I have url in the below format
>>
>> http://localhost:8080/mysite/getmyservice.do?id=17
>>
>> What I was looking for is to hide the id part of the url and just show something like
>>
>> http://localhost:8080/mysite/getmyservice.do#
>>
>> Is this hack possible with tomcat 7.011 or 7.027 or I need to write some filter to do this?
>>
>> I have Tomcat 7.027 on win 7 home premium and url is generated via servlet/jsp.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: URL Rewriting
Posted by Oguz Kologlu <oz...@hotmail.com>.
There is a handy URL rewrite filter already built.
http://www.tuckey.org/urlrewrite/
You can hide the ID if you post the form but you need to be a bit more specific with what you want to do
Oz
On 13/06/2012, at 1:21 PM, Kiran Badi wrote:
> Hi All,
>
> For some of the functionality, I have url in the below format
>
> http://localhost:8080/mysite/getmyservice.do?id=17
>
> What I was looking for is to hide the id part of the url and just show something like
>
> http://localhost:8080/mysite/getmyservice.do#
>
> Is this hack possible with tomcat 7.011 or 7.027 or I need to write some filter to do this?
>
> I have Tomcat 7.027 on win 7 home premium and url is generated via servlet/jsp.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: URL Rewriting
Posted by Kiran Badi <ki...@poonam.org>.
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()%>/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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: URL Rewriting
Posted by André Warnier <aw...@ice-sa.com>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: URL Rewriting
Posted by Hassan Schroeder <ha...@gmail.com>.
On Wed, Jun 13, 2012 at 2:34 PM, Kiran Badi <ki...@poonam.org> wrote:
>> 1) Embed it in the URL for GET requests, either via query string or
>> as path info (e.g. /story/data/17 )
> I think this is what I am presently doing.
The query string approach, yes; personally I think the pathinfo approach
is cleaner visually.
>> 2) Use a form to POST the request with the id included (a bit clunky,
>> same security issue)
> Form will not work as data is dynamic and form I feel will not serve the
> purpose.
The data being "dynamic" isn't relevant. And this approach *is* used
by frameworks like Rails for cases where GET isn't appropriate.
But each approach has advantages and disadvantages, so...
--
Hassan Schroeder ------------------------ hassan.schroeder@gmail.com
http://about.me/hassanschroeder
twitter: @hassan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: URL Rewriting
Posted by Kiran Badi <ki...@poonam.org>.
Thanks Hassan.
> If you want 'clean' URLs you should get rid of the '.jsp' too, but ...
The bottom line is the value for 'id' needs to come from somewhere.
Your choices are:
1) Embed it in the URL for GET requests, either via query string or
as path info (e.g. /story/data/17 ) and handle the security aspect
(if any) yourself
Kiran : I think this is what I am presently doing.
>
> 2) Use a form to POST the request with the id included (a bit clunky,
> same security issue)
Form will not work as data is dynamic and form I feel will not serve the
purpose.
>
> 3) Save the 'id' in session and use that -- everyone sees the same URL
> e.g. /story/data but with unique data. Obviously, this doesn't work for
> a resource that's intended to be shared :-)
Yup I agree, session is ruled out.I just dont have that much patience to
figure the things out if I get some nasty behavior.I just dont have that
level of skill nor time.
The way I have done this is ok for me, it serves my purpose and also I
dont have the data which is kind of private.Its just that I was
exploring if we can hide the id.
HTH,
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: URL Rewriting
Posted by Hassan Schroeder <ha...@gmail.com>.
On Wed, Jun 13, 2012 at 11:12 AM, Kiran Badi <ki...@poonam.org> wrote:
> why I not getting the url of jsp something like
>
> http://localhost:8080/ourstory/myiddata.jsp
If you want 'clean' URLs you should get rid of the '.jsp' too, but ...
The bottom line is the value for 'id' needs to come from somewhere.
Your choices are:
1) Embed it in the URL for GET requests, either via query string or
as path info (e.g. /story/data/17 ) and handle the security aspect
(if any) yourself
2) Use a form to POST the request with the id included (a bit clunky,
same security issue)
3) Save the 'id' in session and use that -- everyone sees the same URL
e.g. /story/data but with unique data. Obviously, this doesn't work for
a resource that's intended to be shared :-)
HTH,
--
Hassan Schroeder ------------------------ hassan.schroeder@gmail.com
http://about.me/hassanschroeder
twitter: @hassan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: URL Rewriting
Posted by Kiran Badi <ki...@poonam.org>.
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 ?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: URL Rewriting
Posted by André Warnier <aw...@ice-sa.com>.
Kiran Badi wrote:
> Hi All,
>
> For some of the functionality, I have url in the below format
>
> http://localhost:8080/mysite/getmyservice.do?id=17
>
> What I was looking for is to hide the id part of the url and just show
> something like
>
> http://localhost:8080/mysite/getmyservice.do#
>
> Is this hack possible with tomcat 7.011 or 7.027 or I need to write some
> filter to do this?
>
> I have Tomcat 7.027 on win 7 home premium and url is generated via
> servlet/jsp.
>
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 ?)
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.
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 ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org