-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Timothy,
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 well. >> 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/OF/sACgkQ9CaO5/Lv0PBZZwCfQw7aWlOnLkTmcrq5Mrcgt2fV fZMAnjKyB5GxcVB01BhTD7MbPAOfPOkg =Upqa -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
