You may have the following element in your web app's web.xml:
<login-config>
<auth-method>some_authentication_method</auth-method>
<realm-name>some_realm_name</realm-name>
</login-config>
(If you don't, then you're probably not serving the content from a
protected context, and this issue doesn't apply to you.)
Possible values for some_authentication_method are BASIC, DIGEST, and FORM.
BASIC authentication means the user agent (e.g. the browser) will send a
cleartext username and password, which of course can be easily
intercepted and therefore compromised.
DIGEST authentication means the user agent will send a one way hash
value that was created with the username, password, and some random data
as inputs. The server has the same hash value stored, so it can
determine that the user has properly authenticated; but since it's a
one-way hash, an eavesdropper cannot work backwards and figure out the
password. And because of the random data, coordinated between the client
and server, no one can record and replay the hash value to spoof the
authentication. It's fairly secure, but not as good as SSL or TLS.
FORM authentication means the user enters authenticating information via
an HTML form, which is encoded according to the content type specified
in the "enctype" attribute of the HTML FORM element.
You need to set the "classname" attribute of the <valve> element in
server.xml appropriately, as described in the email referenced below.
The attribute value must match the authentication method chosen from the
above list. The three authenticator classes are located in package
org.apache.catalina.authenticator, and the classnames are
BasicAuthenticator, DigestAuthenticator, and FormAuthenticator.*
*So, for example, if you're using DIGEST authentication, your valve
element would look like this.*
*
<Valve className="org.apache.catalina.authenticator.DigestAuthenticator"
disableProxyCaching="false" />
BTW, switching gears, I should have mentioned the following in my
previous email. I suspect that the IE workaround you described will only
work for SSL connections. Tomcat (and presumably any other good HTTP
server) will set the cache control headers to prevent caching of any
response generated from a protected context (i.e. one in which there is
a <security-constraint> element), whether the connection is made with
HTTPS (i.e., SSL) or HTTP. The IE option you described seems to apply
only to encrypted data, so it probably won't help IE users who are
trying to download files from a protected context via HTTP.
This is a further irony, since cached SSL data is not as problematic.
It's the plaintext data you want to purge, and that's precisely the data
for which you have to permit caching because of the way IE is
implemented. (However, it's possible that the IE check option is poorly
worded. Perhaps it actually applies to any response for which the cache
control headers are set to "no-cache".)
-Mark
Panichi, Mary-Beth wrote:
Another newbie question -- how do I tell which authenticator we're
using? Does tomcat use a default one? I was looking at the API, but
there isn't enough explanation there. And I didn't see anything in the
Tomcat doco.
Thanks,
-Mary Beth
-----Original Message-----
From: Mark Leone [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 07, 2005 9:24 PM
To: Tomcat Users List
Subject: Re: Tomcat, SSL, IE, and .pdf downloads
Mary-Beth, be advised that applying the fix in Tomcat is arguably the
moral equivalent of what you said you didn't want to do (i.e., uncheck
"don't allow encrypted data to be cached to disk" in IE). By inserting
the valve that ensures that the cache-control headers are not set,
you're not only permitting IE to cache the response, but you're also
permitting any HTTP intermediaries to do so. I wouldn't be concerned
about the former (since the user can control the browser cache), but the
latter can be an issue if you have HTTP intermediaries in the path and
you don't want any copies of the response hanging around.
It would actually be more secure to just uncheck the setting in IE
(since you indicated that works), and retain the no-cache behavior for
the HTTP intermediaries; but that's probably unworkable from an interop
standpoint. All IE users would have to configure their browser properly,
or they will be told that your site is unavailable.
The unfortunate reality is that because one particular user agent (IE)
is applying more restrictive caching behavior than is warranted by the
spec, the server has to relax the caching behavior where it really needs
to be restricted in many cases, if IE compatibility with default
settings is to be maintained. There's an important lesson here, but I
don't think the party that needs to learn it is listening.
-Mark
Mark Thomas wrote:
This seems to be a popular subject today. Try looking at
http://marc.theaimsgroup.com/?l=tomcat-user&m=111811136603781&w=2
Mark
Panichi, Mary-Beth wrote:
Greetings ~
We're having issues downloading .pdf files in SSL. I've been all
over
the web trying to find solutions. The issue appears to be
interaction
between Tomcat and InternetExplorer. IE appears to be corrupting the
pdf files. There's an IE patch out there, but we've patched past
that.
The fix that they list, to uncheck the "don't allow encrypted data to
be
cached to disk," works, but it's a setting that for security reasons
we
don't want to leave unchecked.
I've tried all manner of setting headers for cache-control, etc..
We're
dynamically generating the .pdf files, and streaming them to the jsp
page. I've tried also saving the pdf's physically to the server and
then getting them, but that didn't work either.
Has anyone run into this issue? Does anyone have a solution? I've
seen
lots of suggestions out there, but nothing that actually works.
Thanks!
Mary Beth Panichi
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
