Ciao André! Thaks for your answer. Let me add some further info. The service I was talking about is a php script we put in the crontab and it accesses directly to the tomcat asking the url (127.0.0.1:8080/...) I'm omitting the final part of the ip just for privacy. There are just a little set of ips that seem to be involved in the scenario I described and they don't change. About the user interaction, we experienced the issue with some pages that are asked directly to the tomcat that is listening on the port 8080. I checked the jsp page and the css file we saw is asked by the ip is refereced by the page as follows
<link rel="stylesheet" type="text/css" href="/.../services.css"> Inspecting the access log of the tomcat I found that - 151.x.x.x - - [26/May/2011:06:56:59 +0200] "GET /.../Terminal.jsp.. (this is the request of our user) - 85.18.x.x - - [26/May/2011:06:56:59 +0200] "GET /fo/Service/css/services.css (this is a css included in the jsp above but it seems to be requested by another ip and this request is authenticated using a cookie) Thanks Fil On Thu, May 26, 2011 at 12:21 PM, André Warnier <a...@ice-sa.com> wrote: > Hi. > > In addition to what you explained below, could you explain the network > setup ? > In particular, are users always accessing the tomcat server directly, or > through a firewall, and/or through a front-end like Apache httpd ? > And what is this "external service" ? is that another webserver ? > On what ports does all this run/listen/communicate ? > > Also, when you mention "85.18.x.x", is that literally "85.18.x.x", or did > you just "obscure" the real IP address for privacy reasons ? and if so, when > you say "85.18.x.x", does that mean that it is always the same IP address > exactly, or do these last "x.x" vary ? > > I guess that what I am saying really is : your explanation below is rich in > words, but relatively poor in real data, so it is a bit hard to give you > real answers. > > Also, just as a tip : if the pages returned by Tomcat (or this "external > service") contain links, and these links are sometimes relative (e.g. <a > href="/img/logo.gif"..) and sometimes absolute (e.g. <a href=" > http://someserver.company.com/img/logo.gif";..), it may be that some user > accesses take one route through the network, and other user acesses take > another route, and this may explain why getRemoteAddress sometimes shows > different addresses. > > > Filippo Machi wrote: > >> Hi all, >> we're experiencing an issue with the getRemoteAddress method >> (HttpServletRequest). >> We don't know whether is something known depending on tomcat or if it's >> something malicious, >> affecting our servers. >> We have a filter that authorizes incoming requests using different >> patterns, >> one of these is based on >> ip checking. Requested performed by localhost are granted. >> Since we have an external service, installed on the same host running the >> tomcat, and this service >> invokes b2b requests on the tomcat istance (using 127.0.0.1), we noticed >> the >> following strange behaviour: >> sometimes requests are rejected since the ip obtained invoking the >> getRemoteAddress method results >> equals to 85.18.x.x. >> How can I say that? We considered both the log of the tomcat and the log >> of >> the external service described above >> and the content matches. I mean, each time this kind of failure occurs >> (it >> happened different times), the external service >> log the http response and, since the ip checking fails, it receives an >> html >> page, the login page! >> So, a request issued by a service running on localhost and sent as a get >> to >> a tomcat istance running on localhost appears to be issued >> from the ip address I mentioned above but we are sure that the client and >> the server are talking each other. >> This failure occurs periodically, at the same hour of the day. Besides, >> since we added some logs to have a better picture, we noticed that >> sometimes even during user interactions from external but known ips some >> requests appear to be issued by the address 85.18.x.x. >> Anyway, users are able to see web pages without any issues, since in this >> case their requests are authorized by a cookie and not by ip checking. >> Has anybody a clue of what is happening? >> Thanks in advance >> fil >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
![http://someserver.company.com/img/logo.gif"](http://someserver.company.com/img/logo.gif"){kind=link}