You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "bognár, attila" <at...@netalfa.com> on 2003/04/18 12:02:57 UTC
x-forwarded-for
Hello,
Is there a possibility to make Tomcat extract the x-forwarded-for header
from a request, and make this address the originator/source of the
request? My Tomcat is behind a (trusted) apache httpd proxy.
(I mean something with the same functionality as mod_extract_forwarded
or mod_rpaf for apache)
thanks a lot,
attila
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: x-forwarded-for
Posted by "bognár, attila" <at...@netalfa.com>.
> You can do this 3 ways
> - Hack the connectors (hard)
> - Write a filter(easy)
> - Make apache use mod_jk as your proxy ("easiest")
>
> But depending on WHY you need the source IP address whill dictate which
> method you'll need to use.
I think a filter will be the best solution (the apache httpd proxy is on
another machine and I need a pure tomcat solution, on several machines).
> -Tim
thank you very much.
attila
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: x-forwarded-for
Posted by "bognár, attila" <at...@netalfa.com>.
Tim Funk írta:
> You can fake it in a filter by using a wrapper like this:
>
> public void doFilter(ServletRequest request,
> ServletResponse response,
> FilterChain chain)
> throws java.io.IOException,
> ServletException {
>
> HttpServletRequest hreq = (HttpServletRequest)request;
>
> ServletRequest r = new HttpServletRequestWrapper(hreq) {
> public String getRemoteAddr() {
> return getRequest().getHeader("x-forwarded-for");
> }
> public String getRemoteHost() {
> return getRemoteAddr();
> }
> };
> chain.doFilter(r, response);
> }
>
> -Tim
thanks for the idea, I will meditate on it and its consequences
(benefits/drawbacks).
attila
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
forwarder servlet
Posted by ku...@inwind.it.
Hello,
A would like to write a forwarder servlet, that looks at the data coming in
and, depending on what data it is, dispatches the request to appropriate
html file or another servlet. Any example already available?
Thanks in advance,
luca
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
jsp:include problem migrating to Tomcat 4.1.18
Posted by Dave Jones <dj...@ix.netcom.com>.
Hi,
I've run into a problem migrating an application from Tomcat 3.3
to 4.1.18. Briefly, the problem is that my JSP pages, which
include several jsp:include tags, stop displaying at the first
include when an exception is thrown by a later include.
Example:
<body>
<html>
<table>
<tr><td> <----- (A)
<jsp:include page="header.jsp" flush="true" />
</td></tr>
<tr><td>
<jsp:include page="body.jsp" flush="true" />
</td></tr>
</table>
</body>
</html>
body.jsp contains html, jsp scriptlets and tags and calls to beans.
If body.jsp does not throw an exception, the page displays fine.
However, if body.jsp throws an exception, the page only displays
up to point A above.
If I comment out the include tag of header.jsp, a stack trace is
displayed (as expected).
If I replace the include tag with code from the included
header.jsp, a stack trace is displayed (as expected).
The problem only occurs when a) an exception is thrown from
body.jsp and b) the header code is included via jsp:include
instead of placed in-line.
Can anyone shed some light on this?
TIA,
Dave Jones
NetEffect
Re: [OT] redundant code generation for setters/getters
Posted by "Steven J. Owens" <pu...@darksleep.com>.
On Sun, Apr 20, 2003 at 10:14:45PM -0700, Oscar Carrillo wrote:
> I've had to make many web forms with many entries. Which means I had
> to make a bunch of accessors/mutators (setters/getters) for all the
> action classes. That can be quite cumbersome, so I made my own tool
> using basic "cat" and "sed" in Unix.
Yeah, I hate that aspect of JSP/servlet programming. Probably my
least-favorite part. For this superficial stuff, javabeans are
overkill and generate more work than they cure. You end up with a
suite of javabeans that model the user's perspective on the app, not
necessarily the object model the app should have. Then you have to
refactor the object model and yet still keep the javabeans sync'd with
the forms. Struts has the right idea, here, separate the
preprocessing of the form submit from the back-end business logic.
There seem to be a lot of good ideas in Struts (and some good
implementations), but at the same time, I shied away from using Struts
for my last project. I didn't have time to reinvent the project in
Struts, and there were too many unknowns for me to feel comfortable
with banking the project's success on both Struts and my ability to
get up to speed quickly on it.
I plan to do just that - reinvent the project in Struts, port the
entire project over to Struts - but at my leisure, not as a
deadline-driven project. I'll learn about Struts and I'll get to
experiment with Struts (and maybe even migrate that back into the
project, if the experiment goes well).
But I still think the Struts approach, from what I've read so
far, requires too much rote coding (except possibly for the dynamic
bean stuff, which I'm still learning about). But that's me, I'm lazy :-).
> I list all the names of the methods in a file and it uses a template to
> generate the methods along with the comments. I do the same for the
> declarations using the same file. I then just paste in the output.
>
> Maybe others have better ways of doing this. If so, what do you use?
A few months ago, for a project, I ended up writing an XML-driven
tool for generating beans and database access code and even the
boilerplate of the JSP code. The XML file lists the forms, each form
contains a list of input elements, each input element contains a list
of other details about the input and how it should be handled.
It's extremely kludgy and was a pain (writing java to write java
to write JSP tags that generate HTML -- done in the most obvious and
crude way possible, with lots of println statements in the generator).
I've been meaning to go back and rewrite this, in three stages.
I may have posted about this here a few months ago. I've certainly
been mulling over the design issues.
Stage 1 would be keeping the same basic approach, but cleaning
it up a bit - moving the source out to separate template files, moving
as much boilerplate code out to superclasses as possible. One
definite thought is defining a bunch of boilerplate INPUT element
classes and validation test classes.
For example, a date input element class would wrap a date and
would include parsing code and code for generating an appropriate
error message. Then a test class might be a date-range test, to make
sure the date is within a specified timespan. Other tests might
include before date, after date, value greater than, less than, etc.
So a lot of the java source gets moved out to these boilerplate
classes and the javabean itself just has instances of those classes
and getters/setters that invokes them, and the generator is a lot
cleaner.
Stage 2 would involve making the whole thing dynamic - pretty
much the same as above, except the XML file would drive the dynamic
generation of a tree of objects, instead of specific javabean source,
something like this:
formprocessor
formhandler
parameter
test
parameter
test
test
parameter
test
test
test
At that point, I'd have to add some helper code, mainly the
formprocessor.map(HttpServletRequest) method, which simulates the
<JSP:setProperty property="*"/>. formprocessor.process() then loops
through the list of parameters, tries to parse the input value,
applies the tests, and sets the results. Error handling would be
built in here as well - failed tests contain an error message (which
can be customized in the XML file and uses MessageFormat to insert
values from the test itself into the error message).
Finally, the formhandler would be one of several boilerplate
classes, or a custom class that meets the formhandler interface. The
boilerplate classes would provide a lot of obvious stuff - redirect,
re-post to another site, SOAP and XML-RPC, email the results, send a
JMS message, provide tools to make it easier to compose SQL where,
insert and update clauses for use by a database, etc.
Stage 3 (and this is where I'm going out on a limb, because I
don't know custom taglibs at all) would be switching away from using a
separate XML configuration file for the forms. Instead, ideally the
JSP page's form tags would configure the form handler. The tags would
look and feel like standard HTML form tags, i.e. <FP:FORM>,
<FP:INPUT>, <FP:SELECT>, but would allow additional attributes and
enclosed elements to act as the configuration for the formprocessor.
Instead of:
<TR>
<TD>Foo</TD>
<TD><INPUT name="foo" type="text" value="<%= beanname.getFoo() %>">
<FONT fontcolor="red"><%= beanname.getFooError() %></FONT>
</TD>
</TR>
You'd have:
<TR>
<TD>Foo</TD>
<TD><FP:INPUT name="foo" type="text"/></TD>
<TD><FP:ERROR name="foo"/></TD>
</TR>
And then, adding a few more features (see below), you might have:
<TR>
<TD>Foo</TD>
<TD><FP:INPUT name="foo" type="text" paramtype="integer" default="bar">
<FP:TEST type="range" lower="1" upper="10"/>
</FP:INPUT>
</TD>
<TD><FP:ERROR name="foo"/></TD>
</TR>
I've had some otherwise sane folks object to Stage 3, not on any
technical grounds, but on good design grounds - separation of
presentation and logic. I think that's a red herring in this case.
Presentation and logic should indeed be separate, but this is more
superficial, more on the order of logic about presentation. This is
focused at a very narrow slice, at the process of getting the data
into the logical system.
Steven J. Owens
puff@darksleep.com
"I'm going to make broad, sweeping generalizations and strong,
declarative statements, because otherwise I'll be here all night and
this document will be four times longer and much less fun to read.
Take it all with a grain of salt." - Me at http://darksleep.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: x-forwarded-for
Posted by "Bognár, Attila" <at...@netalfa.com>.
> Not to skirt around the original question, but is this what you were
> looking for. (I don't know the status of that request)
>
> http://marc.theaimsgroup.com/?l=tomcat-dev&m=104914822504371&w=2
no, extraction of X-Forwarded-For information is another thing, but I am
already using proxyPort, thanks.
attila
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
[OT] redundant code generation for setters/getters
Posted by Oscar Carrillo <to...@daydream.stanford.edu>.
Hi,
I've had to make many web forms with many entries. Which means I had to
make a bunch of accessors/mutators (setters/getters) for all the action
classes. That can be quite cumbersome, so I made my own tool using basic
"cat" and "sed" in Unix.
I list all the names of the methods in a file and it uses a template to
generate the methods along with the comments. I do the same for the
declarations using the same file. I then just paste in the output.
Maybe others have better ways of doing this. If so, what do you use?
If anyone is interested in the tool I'm developing, I'll post it on my
website. For Win32 users, you'd need cygwin of course.
Oscar
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: x-forwarded-for
Posted by Tim Funk <fu...@joedog.org>.
I am unsure of the ErrorReportValve issue. (Rarely looked at it) If you think
there is a bug with it, post an (another) email to tomcat-dev with a clear
explanation and (brief) codes snippets of the problem and solution. (the
briefer the better) With any luck, one the of the committers will take notice
(they seem very busy right now) and may provide insight. (Which I definitely
don't have)
Not to skirt around the original question, but is this what you were looking
for. (I don't know the status of that request)
http://marc.theaimsgroup.com/?l=tomcat-dev&m=104914822504371&w=2
-Tim
bognár, attila wrote:
>
>
>> I meant to say (for laziness) that every attempt should be made to not
>> write a custom valve if another mechanism might do the trick. That
>> doesn't mean you shouldn't write a valve, but doing so might be a time
>> consuming task since the docs and intricacies on doing so (or any
>> extending of tomcat) is sparse and only really exists in the source
>> code. (The disadvantage of open source).
>
>
> with such a valve I want to make, the proxying would be nearly totally
> transparent, that's why I'd like it (accesslogvalve could be configured
> the ususal way, more entries in the X-Forwarded-For header could be
> handled, the filter would not have to be added for every application -
> only for every context and my users would not need to take care of
> this). I would even contribute it to the tomcat project, since it is
> something that more people would need who have tomcat behind a proxy.
>
> and (again :-) ErrorReportValve: is the casting a bug/misfunction/meant
> that way? if this is a bug and request.getRequest() is the solution,
> what's the way to fix it, e.g. commit it to the sources (somebody
> reviews it etc.)? I can make my own version of tomcat, but if this is a
> bug, everybody would benefit if it is corrected. (I can make a bug
> report, but if I can fix it for the next release, it would be simple for
> me :-)
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: x-forwarded-for
Posted by "bognár, attila" <at...@netalfa.com>.
> I meant to say (for laziness) that every attempt should be made to not
> write a custom valve if another mechanism might do the trick. That
> doesn't mean you shouldn't write a valve, but doing so might be a time
> consuming task since the docs and intricacies on doing so (or any
> extending of tomcat) is sparse and only really exists in the source
> code. (The disadvantage of open source).
with such a valve I want to make, the proxying would be nearly totally
transparent, that's why I'd like it (accesslogvalve could be configured
the ususal way, more entries in the X-Forwarded-For header could be
handled, the filter would not have to be added for every application -
only for every context and my users would not need to take care of
this). I would even contribute it to the tomcat project, since it is
something that more people would need who have tomcat behind a proxy.
and (again :-) ErrorReportValve: is the casting a bug/misfunction/meant
that way? if this is a bug and request.getRequest() is the solution,
what's the way to fix it, e.g. commit it to the sources (somebody
reviews it etc.)? I can make my own version of tomcat, but if this is a
bug, everybody would benefit if it is corrected. (I can make a bug
report, but if I can fix it for the next release, it would be simple for
me :-)
> There are other threads in tomcat-user list where users have encountered
> this problem. A good place to research is here:
> http://marc.theaimsgroup.com/?l=tomcat-user&r=1&w=2 (I suggest search on
> MBean and Valve)
thank you very much, I will investigate on this.
attila
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: x-forwarded-for
Posted by Tim Funk <fu...@joedog.org>.
I meant to say (for laziness) that every attempt should be made to not write
a custom valve if another mechanism might do the trick. That doesn't mean you
shouldn't write a valve, but doing so might be a time consuming task since
the docs and intricacies on doing so (or any extending of tomcat) is sparse
and only really exists in the source code. (The disadvantage of open source).
I apologize for not being of more help with respect to the MBeans errors. The
JMX support in tomcat is still in an evolutionary stage (but it is great
stuff) and while I have been following its progress, I am still ignorant of
how to effectively use it. (On my todo list)
There are other threads in tomcat-user list where users have encountered this
problem. A good place to research is here:
http://marc.theaimsgroup.com/?l=tomcat-user&r=1&w=2 (I suggest search on
MBean and Valve)
-Tim
bognár, attila wrote:
> so nobody should write a custom valve? and what about the casting in
> ErrorReportValve?
>
> attila
>
>
> Tim Funk írta:
>
>> Never use any org.apache.catalina class directly. They may change
>> "without notice".
>>
>> The accesslog valve might already do what you need with this:
>> %{x-forwarded-for}i
>>
>> Also some other fun tricks:
>> %{xxx}i xxx is the name of the incoming header
>> %{xxx}c xxx is the name of a specific cookie
>> %{xxx}r xxx is an attribute in the ServletRequest
>> %{xxx}s xxx is an attribute in the HttpSession
>>
>> -Tim
>>
>> bognár, attila wrote:
>>
>>> hi,
>>>
>>> A question: why are
>>> org.apache.catalina.{RequestWrapper|HttpRequestWrapper} deprecated
>>> and not implemented?
>>>
>>>
>>> I implemented a filter which works fine. But I want that
>>> AccessLogValve also uses the result of X-Forwarded-For extraction, so
>>> I made a Valve, which could be called before AccessLogValve.
>>>
>>> My valve is called RPAFValve and does not implement Lyfecycle
>>>
>>> When I start tomcat:
>>>
>>> ServerLifecycleListener: createMBeans: MBeanException
>>> java.lang.Exception: ManagedBean is not found with RPAFValve
>>> at
>>> org.apache.catalina.mbeans.MBeanUtils.createMBean(MBeanUtils.java:782)
>>> at
>>> org.apache.catalina.mbeans.ServerLifecycleListener.createMBeans(ServerLifecycleListener.java:644)
>>>
>>> at
>>> org.apache.catalina.mbeans.ServerLifecycleListener.createMBeans(ServerLifecycleListener.java:590)
>>>
>>> at
>>> org.apache.catalina.mbeans.ServerLifecycleListener.createMBeans(ServerLifecycleListener.java:783)
>>>
>>> at
>>> org.apache.catalina.mbeans.ServerLifecycleListener.createMBeans(ServerLifecycleListener.java:751)
>>>
>>> at
>>> org.apache.catalina.mbeans.ServerLifecycleListener.createMBeans(ServerLifecycleListener.java:339)
>>>
>>> at
>>> org.apache.catalina.mbeans.ServerLifecycleListener.lifecycleEvent(ServerLifecycleListener.java:206)
>>>
>>> at
>>> org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:166)
>>>
>>> at
>>> org.apache.catalina.core.StandardServer.start(StandardServer.java:2182)
>>> at org.apache.catalina.startup.Catalina.start(Catalina.java:512)
>>> at
>>> org.apache.catalina.startup.Catalina.execute(Catalina.java:400)
>>> at
>>> org.apache.catalina.startup.Catalina.process(Catalina.java:180)
>>> at java.lang.reflect.Method.invoke(Native Method)
>>> at
>>> org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:203)
>>>
>>>
>>> on a site I found a valve where they say that mbeans-descriptor.xml
>>> from catalina.jar should be updated. is there a possibility to avoid
>>> this?
>>>
>>> my valve:
>>>
>>> RPAF is an object that extracts the header and creates a wrapper,
>>> RPAFHttpRequest is an org.apache.Catalina.HttpRequest wrapper which
>>> gives back the HttpServletRequest given back by RPAF.
>>>
>>> public class RPAFValve extends org.apache.catalina.valves.ValveBase
>>> {
>>> protected boolean active = true;
>>>
>>> protected RPAF rpaf = new RPAF();
>>>
>>> static
>>> {
>>> info = "com.netalfa.tomcat.valves.RPAFValve/0.1";
>>> }
>>>
>>> public RPAFValve()
>>> {
>>> }
>>>
>>> public void invoke(Request request, Response response,
>>> ValveContext valveContext)
>>> throws java.io.IOException, javax.servlet.ServletException
>>> {
>>> if (active)
>>> {
>>> HttpServletRequest req1 =
>>> (HttpServletRequest)request.getRequest();
>>> HttpServletRequest req2 = rpaf.rpafRequest(req1);
>>> if (req1 != req2)
>>> request = new RPAFHttpRequest((HttpRequest)request,
>>> req2);
>>> }
>>> valveContext.invokeNext(request, response);
>>> }
>>>
>>>
>>> public void setActive (boolean active)
>>> {
>>> this.active = active;
>>> }
>>>
>>> public boolean isActive ()
>>> {
>>> return active;
>>> }
>>>
>>> public void setProxy (String proxy)
>>> {
>>> rpaf.setProxy(proxy);
>>> }
>>>
>>> public String getProxy ()
>>> {
>>> return rpaf.getProxy();
>>> }
>>> }
>>>
>>> thanks,
>>>
>>> attila
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: x-forwarded-for
Posted by "bognár, attila" <at...@netalfa.com>.
so nobody should write a custom valve? and what about the casting in
ErrorReportValve?
attila
Tim Funk írta:
> Never use any org.apache.catalina class directly. They may change
> "without notice".
>
> The accesslog valve might already do what you need with this:
> %{x-forwarded-for}i
>
> Also some other fun tricks:
> %{xxx}i xxx is the name of the incoming header
> %{xxx}c xxx is the name of a specific cookie
> %{xxx}r xxx is an attribute in the ServletRequest
> %{xxx}s xxx is an attribute in the HttpSession
>
> -Tim
>
> bognár, attila wrote:
>
>> hi,
>>
>> A question: why are
>> org.apache.catalina.{RequestWrapper|HttpRequestWrapper} deprecated and
>> not implemented?
>>
>>
>> I implemented a filter which works fine. But I want that
>> AccessLogValve also uses the result of X-Forwarded-For extraction, so
>> I made a Valve, which could be called before AccessLogValve.
>>
>> My valve is called RPAFValve and does not implement Lyfecycle
>>
>> When I start tomcat:
>>
>> ServerLifecycleListener: createMBeans: MBeanException
>> java.lang.Exception: ManagedBean is not found with RPAFValve
>> at
>> org.apache.catalina.mbeans.MBeanUtils.createMBean(MBeanUtils.java:782)
>> at
>> org.apache.catalina.mbeans.ServerLifecycleListener.createMBeans(ServerLifecycleListener.java:644)
>>
>> at
>> org.apache.catalina.mbeans.ServerLifecycleListener.createMBeans(ServerLifecycleListener.java:590)
>>
>> at
>> org.apache.catalina.mbeans.ServerLifecycleListener.createMBeans(ServerLifecycleListener.java:783)
>>
>> at
>> org.apache.catalina.mbeans.ServerLifecycleListener.createMBeans(ServerLifecycleListener.java:751)
>>
>> at
>> org.apache.catalina.mbeans.ServerLifecycleListener.createMBeans(ServerLifecycleListener.java:339)
>>
>> at
>> org.apache.catalina.mbeans.ServerLifecycleListener.lifecycleEvent(ServerLifecycleListener.java:206)
>>
>> at
>> org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:166)
>>
>> at
>> org.apache.catalina.core.StandardServer.start(StandardServer.java:2182)
>> at org.apache.catalina.startup.Catalina.start(Catalina.java:512)
>> at
>> org.apache.catalina.startup.Catalina.execute(Catalina.java:400)
>> at
>> org.apache.catalina.startup.Catalina.process(Catalina.java:180)
>> at java.lang.reflect.Method.invoke(Native Method)
>> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:203)
>>
>>
>> on a site I found a valve where they say that mbeans-descriptor.xml
>> from catalina.jar should be updated. is there a possibility to avoid
>> this?
>>
>> my valve:
>>
>> RPAF is an object that extracts the header and creates a wrapper,
>> RPAFHttpRequest is an org.apache.Catalina.HttpRequest wrapper which
>> gives back the HttpServletRequest given back by RPAF.
>>
>> public class RPAFValve extends org.apache.catalina.valves.ValveBase
>> {
>> protected boolean active = true;
>>
>> protected RPAF rpaf = new RPAF();
>>
>> static
>> {
>> info = "com.netalfa.tomcat.valves.RPAFValve/0.1";
>> }
>>
>> public RPAFValve()
>> {
>> }
>>
>> public void invoke(Request request, Response response,
>> ValveContext valveContext)
>> throws java.io.IOException, javax.servlet.ServletException
>> {
>> if (active)
>> {
>> HttpServletRequest req1 =
>> (HttpServletRequest)request.getRequest();
>> HttpServletRequest req2 = rpaf.rpafRequest(req1);
>> if (req1 != req2)
>> request = new RPAFHttpRequest((HttpRequest)request,
>> req2);
>> }
>> valveContext.invokeNext(request, response);
>> }
>>
>>
>> public void setActive (boolean active)
>> {
>> this.active = active;
>> }
>>
>> public boolean isActive ()
>> {
>> return active;
>> }
>>
>> public void setProxy (String proxy)
>> {
>> rpaf.setProxy(proxy);
>> }
>>
>> public String getProxy ()
>> {
>> return rpaf.getProxy();
>> }
>> }
>>
>> thanks,
>>
>> attila
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: x-forwarded-for
Posted by Tim Funk <fu...@joedog.org>.
Never use any org.apache.catalina class directly. They may change "without
notice".
The accesslog valve might already do what you need with this:
%{x-forwarded-for}i
Also some other fun tricks:
%{xxx}i xxx is the name of the incoming header
%{xxx}c xxx is the name of a specific cookie
%{xxx}r xxx is an attribute in the ServletRequest
%{xxx}s xxx is an attribute in the HttpSession
-Tim
bognár, attila wrote:
> hi,
>
> A question: why are
> org.apache.catalina.{RequestWrapper|HttpRequestWrapper} deprecated and
> not implemented?
>
>
> I implemented a filter which works fine. But I want that AccessLogValve
> also uses the result of X-Forwarded-For extraction, so I made a Valve,
> which could be called before AccessLogValve.
>
> My valve is called RPAFValve and does not implement Lyfecycle
>
> When I start tomcat:
>
> ServerLifecycleListener: createMBeans: MBeanException
> java.lang.Exception: ManagedBean is not found with RPAFValve
> at
> org.apache.catalina.mbeans.MBeanUtils.createMBean(MBeanUtils.java:782)
> at
> org.apache.catalina.mbeans.ServerLifecycleListener.createMBeans(ServerLifecycleListener.java:644)
>
> at
> org.apache.catalina.mbeans.ServerLifecycleListener.createMBeans(ServerLifecycleListener.java:590)
>
> at
> org.apache.catalina.mbeans.ServerLifecycleListener.createMBeans(ServerLifecycleListener.java:783)
>
> at
> org.apache.catalina.mbeans.ServerLifecycleListener.createMBeans(ServerLifecycleListener.java:751)
>
> at
> org.apache.catalina.mbeans.ServerLifecycleListener.createMBeans(ServerLifecycleListener.java:339)
>
> at
> org.apache.catalina.mbeans.ServerLifecycleListener.lifecycleEvent(ServerLifecycleListener.java:206)
>
> at
> org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:166)
>
> at
> org.apache.catalina.core.StandardServer.start(StandardServer.java:2182)
> at org.apache.catalina.startup.Catalina.start(Catalina.java:512)
> at org.apache.catalina.startup.Catalina.execute(Catalina.java:400)
> at org.apache.catalina.startup.Catalina.process(Catalina.java:180)
> at java.lang.reflect.Method.invoke(Native Method)
> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:203)
>
>
> on a site I found a valve where they say that mbeans-descriptor.xml from
> catalina.jar should be updated. is there a possibility to avoid this?
>
> my valve:
>
> RPAF is an object that extracts the header and creates a wrapper,
> RPAFHttpRequest is an org.apache.Catalina.HttpRequest wrapper which
> gives back the HttpServletRequest given back by RPAF.
>
> public class RPAFValve extends org.apache.catalina.valves.ValveBase
> {
> protected boolean active = true;
>
> protected RPAF rpaf = new RPAF();
>
> static
> {
> info = "com.netalfa.tomcat.valves.RPAFValve/0.1";
> }
>
> public RPAFValve()
> {
> }
>
> public void invoke(Request request, Response response, ValveContext
> valveContext)
> throws java.io.IOException, javax.servlet.ServletException
> {
> if (active)
> {
> HttpServletRequest req1 =
> (HttpServletRequest)request.getRequest();
> HttpServletRequest req2 = rpaf.rpafRequest(req1);
> if (req1 != req2)
> request = new RPAFHttpRequest((HttpRequest)request, req2);
> }
> valveContext.invokeNext(request, response);
> }
>
>
> public void setActive (boolean active)
> {
> this.active = active;
> }
>
> public boolean isActive ()
> {
> return active;
> }
>
> public void setProxy (String proxy)
> {
> rpaf.setProxy(proxy);
> }
>
> public String getProxy ()
> {
> return rpaf.getProxy();
> }
> }
>
> thanks,
>
> attila
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: x-forwarded-for
Posted by "bognár, attila" <at...@netalfa.com>.
hi,
A question: why are
org.apache.catalina.{RequestWrapper|HttpRequestWrapper} deprecated and
not implemented?
I implemented a filter which works fine. But I want that AccessLogValve
also uses the result of X-Forwarded-For extraction, so I made a Valve,
which could be called before AccessLogValve.
My valve is called RPAFValve and does not implement Lyfecycle
When I start tomcat:
ServerLifecycleListener: createMBeans: MBeanException
java.lang.Exception: ManagedBean is not found with RPAFValve
at
org.apache.catalina.mbeans.MBeanUtils.createMBean(MBeanUtils.java:782)
at
org.apache.catalina.mbeans.ServerLifecycleListener.createMBeans(ServerLifecycleListener.java:644)
at
org.apache.catalina.mbeans.ServerLifecycleListener.createMBeans(ServerLifecycleListener.java:590)
at
org.apache.catalina.mbeans.ServerLifecycleListener.createMBeans(ServerLifecycleListener.java:783)
at
org.apache.catalina.mbeans.ServerLifecycleListener.createMBeans(ServerLifecycleListener.java:751)
at
org.apache.catalina.mbeans.ServerLifecycleListener.createMBeans(ServerLifecycleListener.java:339)
at
org.apache.catalina.mbeans.ServerLifecycleListener.lifecycleEvent(ServerLifecycleListener.java:206)
at
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:166)
at
org.apache.catalina.core.StandardServer.start(StandardServer.java:2182)
at org.apache.catalina.startup.Catalina.start(Catalina.java:512)
at org.apache.catalina.startup.Catalina.execute(Catalina.java:400)
at org.apache.catalina.startup.Catalina.process(Catalina.java:180)
at java.lang.reflect.Method.invoke(Native Method)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:203)
on a site I found a valve where they say that mbeans-descriptor.xml from
catalina.jar should be updated. is there a possibility to avoid this?
my valve:
RPAF is an object that extracts the header and creates a wrapper,
RPAFHttpRequest is an org.apache.Catalina.HttpRequest wrapper which
gives back the HttpServletRequest given back by RPAF.
public class RPAFValve extends org.apache.catalina.valves.ValveBase
{
protected boolean active = true;
protected RPAF rpaf = new RPAF();
static
{
info = "com.netalfa.tomcat.valves.RPAFValve/0.1";
}
public RPAFValve()
{
}
public void invoke(Request request, Response response, ValveContext
valveContext)
throws java.io.IOException, javax.servlet.ServletException
{
if (active)
{
HttpServletRequest req1 =
(HttpServletRequest)request.getRequest();
HttpServletRequest req2 = rpaf.rpafRequest(req1);
if (req1 != req2)
request = new RPAFHttpRequest((HttpRequest)request, req2);
}
valveContext.invokeNext(request, response);
}
public void setActive (boolean active)
{
this.active = active;
}
public boolean isActive ()
{
return active;
}
public void setProxy (String proxy)
{
rpaf.setProxy(proxy);
}
public String getProxy ()
{
return rpaf.getProxy();
}
}
thanks,
attila
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: x-forwarded-for
Posted by Tim Funk <fu...@joedog.org>.
You can fake it in a filter by using a wrapper like this:
public void doFilter(ServletRequest request,
ServletResponse response,
FilterChain chain)
throws java.io.IOException,
ServletException {
HttpServletRequest hreq = (HttpServletRequest)request;
ServletRequest r = new HttpServletRequestWrapper(hreq) {
public String getRemoteAddr() {
return getRequest().getHeader("x-forwarded-for");
}
public String getRemoteHost() {
return getRemoteAddr();
}
};
chain.doFilter(r, response);
}
-Tim
bognár, attila wrote:
>
>> I think a Valve might work too. But it is tomcat specific.
>>
>> Filters are servlet API specific(and portable) and can be constrained
>> to only execute on specific servlets, jsps, or URL patterns without
>> extra configuration effort.
>
>
> yes, but as I read javax.servlet.http.HttpServletRequest, there is no
> way to set the header information (e.g. change the source address), so I
> would be tide to tomcat (or another container) anyway, because I would
> have to fetch some internal state class where I could change it.
>
> and by writing a valve, I can change the source address at the beginning
> of the request processing (if I am not mistaken). if I design my valve
> carefully, it could be easily portable.
>
> attila
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: x-forwarded-for
Posted by "bognár, attila" <at...@netalfa.com>.
> I think a Valve might work too. But it is tomcat specific.
>
> Filters are servlet API specific(and portable) and can be constrained to
> only execute on specific servlets, jsps, or URL patterns without extra
> configuration effort.
yes, but as I read javax.servlet.http.HttpServletRequest, there is no
way to set the header information (e.g. change the source address), so I
would be tide to tomcat (or another container) anyway, because I would
have to fetch some internal state class where I could change it.
and by writing a valve, I can change the source address at the beginning
of the request processing (if I am not mistaken). if I design my valve
carefully, it could be easily portable.
attila
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: x-forwarded-for
Posted by Tim Funk <fu...@joedog.org>.
I think a Valve might work too. But it is tomcat specific.
Filters are servlet API specific(and portable) and can be constrained to only
execute on specific servlets, jsps, or URL patterns without extra
configuration effort.
-Tim
bognár, attila wrote:
>
>> - Hack the connectors (hard)
>> - Write a filter(easy)
>> - Make apache use mod_jk as your proxy ("easiest")
>
>
> I read some documentation. What's your opinion about writing a Valve? It
> is executed before the filters, isn't it? If yes, then I can configure
> tomcat to run my valve before AccessLogValve, so the logs will also
> reflect the source address before the proxy.
>
> attila
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: x-forwarded-for
Posted by "bognár, attila" <at...@netalfa.com>.
> - Hack the connectors (hard)
> - Write a filter(easy)
> - Make apache use mod_jk as your proxy ("easiest")
I read some documentation. What's your opinion about writing a Valve? It
is executed before the filters, isn't it? If yes, then I can configure
tomcat to run my valve before AccessLogValve, so the logs will also
reflect the source address before the proxy.
attila
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: x-forwarded-for
Posted by Tim Funk <fu...@joedog.org>.
You can do this 3 ways
- Hack the connectors (hard)
- Write a filter(easy)
- Make apache use mod_jk as your proxy ("easiest")
But depending on WHY you need the source IP address whill dictate which
method you'll need to use.
-Tim
bognár, attila wrote:
> Hello,
>
> Is there a possibility to make Tomcat extract the x-forwarded-for header
> from a request, and make this address the originator/source of the
> request? My Tomcat is behind a (trusted) apache httpd proxy.
>
> (I mean something with the same functionality as mod_extract_forwarded
> or mod_rpaf for apache)
>
> thanks a lot,
>
> attila
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org