-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 André,
On 2/12/16 2:35 PM, André Warnier (tomcat) wrote: > 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/htt p/ >> >>> 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 ? Not really. Let's take the HttpServletRequest object for instance. The object you get just implements an interface, so the runtime type is unpredictable. The container is allowed to give you anything it wants, and it's allowed to change its mind at any point. You can't tell the difference between an HttpServletRequest (implementing) object created by the container versus one created by the application. You could maybe white-list classes in "org.apache.catalina.*" packages, but then your library becomes brittle and will fail of Tomcat changes its implementation, or the library needs to be portable to other containers. > (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 ? No: this would break one of the basic concepts of OO design, which is that objects implementing an interface (generically, including adhering to the contract defined by an class's superclass "interface") should be treated as implementations of that interface. The runtime type isn't supposed to matter. Yes, you can use reflection/introspection to pull-apart the runtime type, but you can never really be able to make good decisions about the information you find in there. - -chris -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAla+YY4ACgkQ9CaO5/Lv0PDeYACcCiFmRaPX9i6HjmQ0ifnr45qA K5wAoKBqKvMjvCbKn+5R2ZXRPzd/hVfF =mkxD -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
