tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: transport CONFIDENTIAL based on remote ip/host filter?
Date Tue, 05 Jun 2012 14:30:19 GMT
Hash: SHA1


I have some suggestions (inline).

On 6/4/12 5:58 PM, Timothy J Schumacher wrote:
> 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.

You can (and should) disable all of those warnings, but you should
also lock-down the browser so that a user can't visit other sites and
fail to get those warnings (because they are important warnings about
privacy and security).

If most communication is localhost, there's no reason not to use
HTTPS: you aren't talking about thousands of simultaneous requests
that burn up your CPU time with encryption operations.

> 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.

That sounds like an ff bug.

> I have tried to get the certificates loaded and setting
> preferences inside our local firefox, but so far have not had
> success.

You need to get someone else to fix that, then. You can't really
configure (on the server) yourself around client-side warnings.

> 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.

Ask for help. :)

> 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.

You shouldn't have to do that: configure ff correctly and all will be

>> 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.

As for the long-term, you should run your browsers in development
environments with cookies disabled. You'll find out really quickly the
places where your URLs aren't properly encoded. I'm sure you can fix
90% of them in a single release cycle. We take the same position when
it comes to dbcp deadlocks: out entire dev team runs with maxActive=1
and no abandonment recovery in the pool. That way, we find out
immediately if we have a potential deadlock in the code and it gets
fixed right away.

- -chris
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools -
Comment: Using GnuPG with Mozilla -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message