Dave Pawson wrote:
2009/2/6 Caldarale, Charles R <chuck.caldar...@unisys.com>:
From: Dave Pawson [mailto:dave.paw...@gmail.com]
Subject: Re: TC6 ${CATALINA_HOME}/conf/web.xml Is this the
place to constrain the mime type?
Unless the client specifies that one single mime
type (and no other), I want to reject it
Unless you have an extremely specialized client in mind, you will be rejecting
all requests. No browser will ever limit itself to a single mime type.
That's it. Again, my code, hence very specialised.
No browsers, IE or FF! Just my java end point.
I believe that what Chuck is trying to tell you - and in many more words
than his - is this :
Your service, whatever it is, will have a listening TCP port, waiting
for requests from your clients.
Thus, any of many available programs out there (not talking only about
browsers), can connect to that TCP port, and basically send anything
they want to it. Including things resembling the requests you are
expecting, with whatever HTTP headers they want to specify, including
those which you would maybe use to attempt to distinguish your genuine
clients from the others.
Thus, rejecting requests on the base of something they include or not,
unless the something is some secret encrypted key available only to your
server and its genuine clients, will not be a good enough measure if
your goal is to avoid someone downloading something from your server
that they shouldn't.
I (or anyone else on this list) can fake any such HTTP request, at any
time, within 1 minute of you giving us the hostname and port, and
download one of your xml templates.
And we would not even have to write any new program to do it.
If there is a secret key, and if it is fixed, then anyone once capturing
a packet between your clients and your server, would be able to re-use
that key and fake one of your clients forever.
If the key is variable, but based on some simple algorithm, then 1) you
would still have to develop the algorithm and 2) unless you are a
cryptographic expert, someone will break it if there is enough interest
to justify it, and even only for the fun of it.
If security is one of your purposes thus, do not try to use things like
content-type headers or the like, use a secure form of communication
developed by experts and available for free, such as HTTPS.
You would just have to plug-in the pieces, and then develop your
application as if the security layer wasn't even there.
And if security is not in the picture, then forgive me the above
lecture, I got lost somewhere along about what your purpose really is.
But if you're still interested, I have a similar lecture about the
difference between Valves and servlets (or servlet filters), and why one
may be more adapted than the other to any particular purpose.
Not at any deep Tomcat/Java level though.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
