On Fri, May 27, 2011 at 11:20 AM, André Warnier <a...@ice-sa.com> wrote:
> Filippo Machi wrote: > >> >> we're using tomcat 7.0.12 >> >> Ok. > > >> 1) You have serverA running Tomcat, and Tomcat listens on port 8080. >>> The (network) IP address of serverA is : ........ >>> >> 85.214.x.x >> >> (apart from the loopback address 127.0.0.1) >> >>> This Tomcat has some IP-based access Valve which : >>> >>> >> we have a filter, not a valve, (a class implementing >> javax.servlet.Filter) >> that authenticates incoming request >> according to: >> - a particular key contained as parameter in the request >> - the ip of the incoming request >> - a cookie >> those checks are applied in the exact order I listed them, if all of them >> fails, then the user >> is redirected to the login page as follows >> >> request.getServletContext() >> .getRequestDispatcher(LOGIN_PAGE_REDIRECT_URL) >> .forward(request, response); >> >> I don't know whether it matters but we have a chain of filters and the >> authorization one I described is applied >> after a filter that, in some cases perform a forward >> >> >> request.getServletContext().getRequestDispatcher(remappedResource).forward(request, >> response); >> >> but I think it shouldn't be the cause of the issue... >> >> >> - for requests from 127.0.0.1, allows them through without authentication >> >>> - for requests /not/ from 127.0.0.1, requires authentication in the form >>> of >>> a cookie, and if that cookie is not present, returns a login page. >>> >>> The requester IP address is obtained by the Valve using the >>> getRemoteAddress() method. >>> >>> 2) On the same serverA, there is a cron job which runs from time to time. >>> This cron job runs a PHP script, which >>> - connects to "127.0.0.1:8080" >>> - sends a HTTP request over that connection, directed to a specific >>> Tomcat >>> application >>> - receives a response from Tomcat >>> >>> 3) there are also other clients (not on serverA), which access other >>> applications (or the same application) on serverA/Tomcat directly, by >>> addressing their requests to ? >>> (IP or name). >>> >>> >> there are other clients (browsers) accessing serverA using the server name >> >> >> (it cannot be 127.0.0.1:8080, since these clients are not on serverA) >>> >>> The IP's of those clients are : >>> >> something like 93.35.x.x >> >> >>> And what you are seeing in the logs, is that from time to time, a request >>> which seems to come from the PHP script (and should thus have a client IP >>> address of 127.0.0.1 and go through without authentication), instead >>> seems >>> to come from another IP (and thus is caught by the Valve and returns a >>> login >>> page). >>> And you also see this in the log of the PHP script : it shows that it >>> receives a login page, instead of the expected response. (*) >>> >>> >> Yes, that's exactely what we're experiencing (the only detail that differs >> it's that authentication is performed by a filter, not a valve) >> >> >> One more question : this IP-filter Valve, is that something written >>> in-house ? >>> >>> >> Yes, we coded the filter. >> >> >> I do not see anything particularly wrong in the server.xml which you > sent. > But it does confirm that you have a single <Host> in Tomcat. > > One additional question : > The crontab PHP script sends a request to Tomcat from time to time. > Is that request directed to a specific application that only the PHP script > is using, or is that same application also used by other clients ? > > > Yes, we have only one web application used by all our clients, included the php script. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
