On 6 Dec 2002, Alexander Wallace wrote: > Thankyou david... If i run tomcat standalone I can use > request.getRemoteAddr(), request.getRemoteHost(), and > request.getRemoteUser() to get some info I would love to have, but > if apache is in front of tomcat the info is always localhost and > null for the other methods, at least the way I'm doing it... So i > was wondering if there was a way to get the same info i get with > tomcat stand alone.
I have apache in front of tomcat, and those methods work fine for me. So perhaps there is something else going on here, something in your configuration that is not right. > Pretty much what I want to do is run an app that will be open to the > public. It has a section that needs to be protected with ssl. And i > would like to use tomcat standalone but if i use tomcat's ssl, i > loose all objects i placed in the session before i swhitch to > https... Is there a way to be able to access those objects in the > non https session? AFAIK, pretty much no. Doing so would be a security risk. This has come up many times before, check the list archives. General recommendation is to not switch between http and https, always use one or the other. Also, I'm not sure I understand the need for using tomcat security constraints for forcing https usage when using apache in front of tomcat. It makes more sense to me to configure the web server instances/pieces so that resources that need to be secure are only available via https. You can control this by, for example, what DocumentRoot's the instances have, what tomcat webapps are "mounted"/available in the instances, etc. That's what I do. But maybe you're using a different model/setup/organization than I'm envisioning, one where it's not so easy to do that. (Of course, one option there is to change your model.) > On Fri, 2002-12-06 at 12:34, David Brown wrote: > > Alexander Wallace writes: > > > > > I have not tested this, but wanted to make sure before I do all the > > > necesary changes. > > > > > > I have apache in front of tomcat, apache handles the ssl > > > communication... I need to make sure that some stuff happens only via > > > ssl, and i had a filter for that. But i was recommended to use a > > > security constranint in tomcat instead. Will this work having apache on > > > top of tomcat? > > > > > > Also. I only have apache + tomcat becouse when I enabled SSL to tomcat > > > stand alone, whenever switching to ssl, i would not be able to access > > > all my session objects created before the switch. Is there a way to > > > avoid that? If is i would just remove apache from the picture. Al my > > > static content needs to come from tomcat anyway. > > > > > > Also, is there a way to read the ip address of the requesting user if > > > apache is the front to tomcat? > > > > > > I realize some of this are different topics, but have to do with the > > > same stuff... > > > > > > Thanks to all in advance! > > > > > > > > > > > > > > > > > > -- > > > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > > > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > > > > > > > > > Hello Alexander, i know tc can enable/disable dns lookups on requests (i'm > > not sure if this is what u r looking 4). a dns resolver can do reverse > > lookups but getting the ip i'm not sure if there is anyway to do this from > > within tc. all i can say is the "standard" config as laid down by apache and > > tc works 4 me. i have several servlets and jsp's running on 4 virtual hosts > > all ssl capable depending on the "webapp" deployed and the user/role defined > > in my JDBCRealm. everything runs pretty much "out-of-the-box" config. all my > > tc ssl requests go through: https://localhost:8443/<webapp>, all my cgi-bin > > requests go through htts://localhost:443/cgi-bin/<someexec> and all other > > traffic routes as: port 80 or 8080 as expected. removing apache is not > > advisable. apache has many directives that r very usefull as user access > > controls. also, u need to impart more info on ur environment and what u plan > > to do to give the gurus on this ml a better picture. if u plan to operate on > > the public wire much more consideration will need to be given b4 u expose > > ports: 80, 8080, 443, 8443 etc. hope this helps, david. > > > > -- > > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > Milt Epstein Research Programmer Integration and Software Engineering (ISE) Campus Information Technologies and Educational Services (CITES) University of Illinois at Urbana-Champaign (UIUC) [EMAIL PROTECTED] -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
