On 12.02.2016 20:08, Christopher Schultz wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

André,

On 2/12/16 1:11 PM, André Warnier (tomcat) wrote:
Sorry, I lost the original message, so I can't respond in-thread. I
only saw the last message, but to that, isn't this what the Op is
asking for :

http://tomcat.apache.org/tomcat-7.0-doc/servletapi/javax/servlet/http/
HttpServletRequest.html



No matter which jar these things are in, if these methods get
called, they should return the current URI which the client called
to trigger the current webapp, no ? (I'm talking of getRequestURL()
and siblings).

Mark's response accurately points out that anything the library does
to try to determine which application it's running under can
relatively easily be subverted by the application itself.

For your example above, it would be easy to simply wrap the
HttpServletRequest object and override "getRequestURL" and friends.

If you don't trust the code calling you, then you can't trust anything
up the stack.


Ok, sorry, I have not really followed the thread since the beginning. I did not realise that there was a question of not trusting the *code* of the webapps themselves.
I though it was only not trusting the client (browser or whatever).

But let me then push the question one level deeper, at the Java level : is there a way by which some code about to call a method, could find out if this method is "the genuine article", or has been overridden by a wrapper for instance ?

(And I do realise that this is not really applicable here, it is more by 
curiosity)
I mean, the JVM of course must know; but is there a way by which the code can ask the JVM about this ? Or alternatively, can the code "force" the JVM to execute the real method of the original parent (in this case HttpServletRequest) instead of a perhaps wrapper object's method ?



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to