Filippo Machi wrote:
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.
Mmm. That's a bit more complicated for what I had in mind.
Would it be a problem to have 2 separate instances of that application (one for the PHP
script, one for the other clients) ?
I have little time now, but what I have in mind would be roughly as follows :
- you add a second <Host> in your server.xml file, with a hostname of e.g.
"internal.company.com"
- for that second Host, you create a separate "webapps" directory, e.g.
(tomcat_dir)/webapps2
- in that directory, you copy your application, e.g. as
(tomcat_dir)/webapps2/yourapp/* (the same application name, and exactly all the same
files, no changes)
- in the local "hosts" file of your machine, you add the line
127.0.0.1 internal.company.com
- you change your PHP script to access "http://internal.company.com:8080"; instead of
"http://127.0.0.1:8080";
The rest later, I have to go now.. but think about it.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
