See inline comments below.
Thanks again for your time!
Tim
On 6/4/2012 2:35 PM, Konstantin Kolinko wrote:
2012/6/4 Timothy J Schumacher<tim.schumac...@colorado.edu>:
On 5/31/2012 1:30 PM, Konstantin Kolinko wrote:
2012/5/31 Timothy J Schumacher<tim.schumac...@colorado.edu>:
Hi,
We are using Apache Tomcat 6.0.35
with
# java -version
java version "1.6.0_30"
Java(TM) SE Runtime Environment (build 1.6.0_30-b12)
Java HotSpot(TM) Client VM (build 20.5-b03, mixed mode, sharing)
in redhat linux.
I am wondering if there is a way to use transport CONFIDENTIAL for all
hosts
that are not localhost? I am guessing the servlet spec does not allow
this,
it seems to be all or none in the web.xml config. Perhaps there is a way
configure transport NONE in web.xml and then manually configure a
valve/filter in context.xml that would enforce CONFIDENTIAL to all remote
hosts but let localhost pass without redirects to port 443?
Any ideas are appreciated!
<Connector ... address="127.0.0.1" secure="true" />
It will
1. Listen on localhost only.
2. Be treated by Tomcat as if it were an HTTPS connection.
Hi Konstantine, thanks this works! I have one more question. I assume that
setting secure="true" means that the cookie JSESSIONID has "Secure" set.
This causes my browser (an old version of FF) to not send the cookie which
I assume is due to the fact that the communication is over a plain http
connection. Since we have not diligently coded encodeURLs everywhere the
application loses the session on occasion. Is there a way to tell the
component that sets the cookie to not set "Secure" only for this particular
connector?
Why do you want to avoid HTTPS so much?
We make a piece of IT equipment with tomcat running inside serving an
application that acts as the administration console for the device.
There is also a firefox browser running inside the equipment that
exposes the web application in question on the front panel touchscreen
of the device. The device also can be plugged into a network to
facilitate remote management via the web application. We run the local
firefox in kiosk mode, and when the device is powered on, firefox
prompts the user about security certificate warnings and alerts the user
when you are about to view encrypted pages and when you are about to
leave encrypted pages. On top of that, if the user isn't there to
accept the warnings/prompts the local browser seems to timeout and
become unresponsive which requires a restart of firefox. I have tried
to get the certificates loaded and setting preferences inside our local
firefox, but so far have not had success. We just want the local front
panel to show the login screen and not prompt/warn the user and I
suppose the real fix is to learn the proper way to set up the local
firefox but all attempts at getting this correct have been unsuccessful
so far. Since I am more familiar with tomcat and the tomcat
documentation is easier to follow than the old firefox docs, I thought
it could be easier to accomplish this by just configuring something that
makes tomcat treat the local firefox differently.
The recipe that I gave you is usually used in the scenario when Tomcat
is behind a proxy that uses HTTP protocol (instead of AJP one).
That is: a proxy (a.g. Apache HTTPD) does HTTPS, decodes the
connection and forwards request through HTTP.
The "secure" attribute that I mentioned is similar to "proxyHost" and
"proxyPort" connector attributes. It is not there to fool the picture,
but to provide some information to Tomcat that it does not know by
itself.
In that scenario the browser will not have any problems with secure
cookies, because from its side it sees the site through HTTPS.
I think that in your case you can turn off cookies support in browser
and to rely on sessionid being encoded in URLs. URLs are not a
subject to "secure cookies" limitation.
I was afraid this could be the answer... Unfortunately we have not been
very good about using url encoding in our app and there are lots of jsps
with lots of links that need to be wrapped with encodeURL calls but that
is our problem :) I was just hoping for "a big hammer" to get it fixed
in the short term.
I do not remember any option to turn off "secure" bit in cookies. If
there were one, I think it would be on Context. If you want to
implement a trick, I think a Valve can affect create session cookie or
"set-cookie" header, clearing the flag.
I will give the valve idea a try. That seems promising.
You can look into the code for more details. If you want to try
running Tomcat with a debugger, there are tips in the FAQ, or ask
here.
YMMV.
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
