Getting the Client address from request

[Tamás Cservenák]

Hi there,
i am curious, is there any way to get the _real_ client address from
Request.getClientInfo()?

I am talking about the situation, when you have your Restlet App (whether
standalone, or running in Servlet Container) fronted by mod_proxy + httpd...

Something like this (example found on the net, in PHP):
http://www.zen-cart.com/forum/showpost.php?p=437632&postcount=8

The ClientInfo.getAddresses() "smells" like right place to sniff around, but
i don't get the Javadoc and what it really does



-- 
Thanks,
~t~

Re: Getting the Client address from request

[Thierry Boileau]

Hello Tamás

the ClientInfo.getAddresses() method relies on the content of the 
"X-Forwarded-For" HTTP header. Basically, it contains a coma separated 
list of the IPS of the originating client and the intermediate proxies 
as follow:

X-Forwarded-For: client1, proxy1, proxy2

The first value of this list is the IP of the originating client. This 
value is also returned by the ClientInfo#getAddress() method.


=> http://en.wikipedia.org/wiki/X-Forwarded-For

Best regards,
Thierry Boileau
--
Restlet ~ Core developer ~ http://www.restlet.org 
Noelios Technologies ~ Co-founder ~ http://www.noelios.com 




Hi there,

i am curious, is there any way to get the _real_ client address from 
Request.getClientInfo()?


I am talking about the situation, when you have your Restlet App 
(whether standalone, or running in Servlet Container) fronted by 
mod_proxy + httpd...


Something like this (example found on the net, in PHP):
http://www.zen-cart.com/forum/showpost.php?p=437632&postcount=8 



The ClientInfo.getAddresses() "smells" like right place to sniff 
around, but i don't get the Javadoc and what it really does




--
Thanks,
~t~

Re: Getting the Client address from request

[Tamás Cservenák]

Hm,
mod_proxy AFAIK does inserts the 'X-Forwarded-For' HTTP Header, and I am
using the ClientInfo.getAddress() so, if I understand correctly, that
should work correctly, returning always the _true_ client address?

Users are reporting that the Application, when fronted with mod_proxy, is
always logging 127.0.0.1 as client address. Will look into this more.

What will be returned by this method, if there is no 'X-Forwarded-For' HTTP
Header?

Thanks,
~t~

On Fri, Nov 21, 2008 at 9:05 AM, Thierry Boileau <
[EMAIL PROTECTED]> wrote:

>  Hello Tamás
>
> the ClientInfo.getAddresses() method relies on the content of the
> "X-Forwarded-For" HTTP header. Basically, it contains a coma separated list
> of the IPS of the originating client and the intermediate proxies as follow:
> X-Forwarded-For: client1, proxy1, proxy2
>
> The first value of this list is the IP of the originating client. This
> value is also returned by the ClientInfo#getAddress() method.
>
> => http://en.wikipedia.org/wiki/X-Forwarded-For
>
>  Best regards,
> Thierry Boileau
> --
>  Restlet ~ Core developer ~ http://www.restlet.org
> Noelios Technologies ~ Co-founder ~ http://www.noelios.com
>
>
> Hi there,
>  i am curious, is there any way to get the _real_ client address from
> Request.getClientInfo()?
>
>  I am talking about the situation, when you have your Restlet App (whether
> standalone, or running in Servlet Container) fronted by mod_proxy + httpd...
>
>  Something like this (example found on the net, in PHP):
> http://www.zen-cart.com/forum/showpost.php?p=437632&postcount=8
>
>  The ClientInfo.getAddresses() "smells" like right place to sniff around,
> but i don't get the Javadoc and what it really does
>
>
>
> --
> Thanks,
> ~t~
>
>


-- 
Thanks,
~t~

Re: Getting the Client address from request

[Tamás Cservenák]

Sure!
Thanks for the tip. That means, that the Application must be aware that it
is fronted by mod_proxy? Is there some possibility (or even theoretical
chance) to have some kind of "fallback" mechanism? Will look into restlet
sources today...

We already have figured out some means to detect mod_proxy and it's
misconfiguration, since it was resulting in the most user responses, and
almost everyone was having simply misconfigured mod_proxy...

You can follow the progress here:
https://issues.sonatype.org/browse/NEXUS-959

Thanks
~t~

On Fri, Nov 21, 2008 at 11:23 AM, Thierry Boileau <
[EMAIL PROTECTED]> wrote:

>  Hi Tamas,
>
> Oops, I have to complete my previous answer (looks like I forgot
> something).
> By default, the ClientInfo.getAddress() is based on this instruction (in
> HttpClientCall#getLocalAddress):
> InetAddress.getLocalHost().getHostAddress().
> If this instruction fails (host is unknown for example), it returns
> 127.0.0.1...
>
> The ClientInfo#getAddresses() relies on the "X-Forwarded-For" header *only*
> if the "useForwardedForHeader" parameter is set to true (false by default).
> This is one common parameter of the server connectors (
> http://wiki.restlet.org/docs_1.1/13-restlet/27-restlet/37-restlet.html).
> Here is a way to set it to true:
>
> Server server = new Server(Protocol.HTTP, 8182, component);
> component.getServers().add(server);
>  server.getContext().getParameters().add("useForwardedForHeader", "true");
>
> In this case, the ClientInfo#getAddress() method returns the first IP address 
> listed in the "X-Forwarded-For" header which should be the IP of the client.
> I presume that the setting the parameter to true will help you. Could you 
> keep us informed?
>
>
>  Best regards,
> Thierry Boileau
> --
>  Restlet ~ Core developer ~ http://www.restlet.org
> Noelios Technologies ~ Co-founder ~ http://www.noelios.com
>
> Hm,
>  mod_proxy AFAIK does inserts the 'X-Forwarded-For' HTTP Header, and I am
> using the ClientInfo.getAddress() so, if I understand correctly, that
> should work correctly, returning always the _true_ client address?
>
>  Users are reporting that the Application, when fronted with mod_proxy, is
> always logging 127.0.0.1 as client address. Will look into this more.
>
>  What will be returned by this method, if there is no 'X-Forwarded-For'
> HTTP Header?
>
>  Thanks,
> ~t~
>
> On Fri, Nov 21, 2008 at 9:05 AM, Thierry Boileau <
> [EMAIL PROTECTED]> wrote:
>
>>  Hello Tamás
>>
>> the ClientInfo.getAddresses() method relies on the content of the
>> "X-Forwarded-For" HTTP header. Basically, it contains a coma separated list
>> of the IPS of the originating client and the intermediate proxies as follow:
>> X-Forwarded-For: client1, proxy1, proxy2
>>
>> The first value of this list is the IP of the originating client. This
>> value is also returned by the ClientInfo#getAddress() method.
>>
>> => http://en.wikipedia.org/wiki/X-Forwarded-For
>>
>>  Best regards,
>> Thierry Boileau
>> --
>>  Restlet ~ Core developer ~ http://www.restlet.org
>> Noelios Technologies ~ Co-founder ~ http://www.noelios.com
>>
>> Hi there,
>>  i am curious, is there any way to get the _real_ client address from
>> Request.getClientInfo()?
>>
>>  I am talking about the situation, when you have your Restlet App
>> (whether standalone, or running in Servlet Container) fronted by mod_proxy +
>> httpd...
>>
>>  Something like this (example found on the net, in PHP):
>> http://www.zen-cart.com/forum/showpost.php?p=437632&postcount=8
>>
>>  The ClientInfo.getAddresses() "smells" like right place to sniff around,
>> but i don't get the Javadoc and what it really does
>>
>>  --
>> Thanks,
>> ~t~
>>
>>
> --
> Thanks,
> ~t~
>
>


-- 
Thanks,
~t~

Re: Getting the Client address from request

[Thierry Boileau]

Hi Tamas,

Oops, I have to complete my previous answer (looks like I forgot something).
By default, the ClientInfo.getAddress() is based on this instruction (in 
HttpClientCall#getLocalAddress):

InetAddress.getLocalHost().getHostAddress().
If this instruction fails (host is unknown for example), it returns  
127.0.0.1...


The ClientInfo#getAddresses() relies on the "X-Forwarded-For" header 
*only* if the "useForwardedForHeader" parameter is set to true (false by 
default). This is one common parameter of the server connectors 
(http://wiki.restlet.org/docs_1.1/13-restlet/27-restlet/37-restlet.html). 
Here is a way to set it to true:


Server server = new Server(Protocol.HTTP, 8182, component);
component.getServers().add(server);
server.getContext().getParameters().add("useForwardedForHeader", "true");

In this case, the ClientInfo#getAddress() method returns the first IP address listed in 
the "X-Forwarded-For" header which should be the IP of the client.
I presume that the setting the parameter to true will help you. Could you keep 
us informed?


Best regards,
Thierry Boileau
--
Restlet ~ Core developer ~ http://www.restlet.org 
Noelios Technologies ~ Co-founder ~ http://www.noelios.com 


Hm,

mod_proxy AFAIK does inserts the 'X-Forwarded-For' HTTP Header, and I 
am using the ClientInfo.getAddress() so, if I understand 
correctly, that should work correctly, returning always the _true_ 
client address?


Users are reporting that the Application, when fronted with mod_proxy, 
is always logging 127.0.0.1  as client address. Will 
look into this more.


What will be returned by this method, if there is no 'X-Forwarded-For' 
HTTP Header?


Thanks,
~t~

On Fri, Nov 21, 2008 at 9:05 AM, Thierry Boileau 
<[EMAIL PROTECTED] > wrote:


Hello Tamás

the ClientInfo.getAddresses() method relies on the content of the
"X-Forwarded-For" HTTP header. Basically, it contains a coma
separated list of the IPS of the originating client and the
intermediate proxies as follow:
X-Forwarded-For: client1, proxy1, proxy2

The first value of this list is the IP of the originating client.
This value is also returned by the ClientInfo#getAddress() method.

=> http://en.wikipedia.org/wiki/X-Forwarded-For

Best regards,
Thierry Boileau
--
Restlet ~ Core developer ~ http://www.restlet.org

Noelios Technologies ~ Co-founder ~ http://www.noelios.com




Hi there,

i am curious, is there any way to get the _real_ client address
from Request.getClientInfo()?

I am talking about the situation, when you have your Restlet App
(whether standalone, or running in Servlet Container) fronted by
mod_proxy + httpd...

Something like this (example found on the net, in PHP):
http://www.zen-cart.com/forum/showpost.php?p=437632&postcount=8


The ClientInfo.getAddresses() "smells" like right place to sniff
around, but i don't get the Javadoc and what it really does

-- 
Thanks,

~t~



--
Thanks,
~t~

Re: Getting the Client address from request

[John D. Mitchell]

On Friday 2008.11.21, at 02:35 , Tamás Cservenák wrote:
[...]
Thanks for the tip. That means, that the Application must be aware  
that it is fronted by mod_proxy? Is there some possibility (or even  
theoretical chance) to have some kind of "fallback" mechanism? Will  
look into restlet sources today...


Well, yes and no.

I don't know of any guaranteed, general way to know that it's a proxy  
and not an original client -- that's a large rabbit hole.


One hack would be to change the getAddresses() code can do the  
underlying call to InetAddress.getLocalHost().getHostAddress() and  
only if it fails or returns localhost then try the extraction of "X- 
Forwarded-For:" and only if that fails too then return localhost.   
This handles the dominant case, such as yours, where there's a  
fronting proxy on the local machine.



However, I think this entire approach of having getAddresses() hide  
the reality of X-Forwarded-For: from the applications is actually a  
bad idea.  Different applications and/or in different deployment  
environments do really need to understand the difference between the  
upstream client, whether or not an X-Forwarded-For: exists or not, and  
can decide for itself whether or not it needs the information out of X- 
Forwarded-For: header (and how much to trust that information).


So, I'd move the X-Forwarded-For: stuff out of getAddresses() and into  
a getForwardedAddresses().  Then all applications can do what's  
correct for them.


Take care,
John

Re: Getting the Client address from request

[Tamás Cservenák]

Hi there,
yes, i must agree with you.

(and follows a monologue :)

But the problem is with those companies/users/people, that their ITs guys --
for some reason, even today in 2009 -- are not accepting the fact that
fronting a Jetty (or any other _modern_ Servlet Container) with a httpd +
mod_proxy is just an overhead (not to mention that it kills Jetty's advanced
connection pooling). Ok, there are situations where you want to have some
sort of integration with some existing vhosts, etc.

I'm just saying that people chooses "too easy and almost automatically" to
front Java Server Container with mod_proxy, even if they don't have to (so,
excluding the really justified cases). Simply because they were doing it
before 6 years.

Personally, OSes has many other advanced tools (like iptables and forwarding
port 80 to higher one, and avoiding the need for running java as root, etc),
that makes httpd used for only one Java app a nonsense. Again, let's exclude
the _justified_ cases of using mod_proxy.

Luckily, in this case the IP address is taking part in logs and feeds only,
so they are not vital or security related at all (but they could be). It is
simply annoying to always have "127.0.0.1" in them, instead of "real" IP.


Thanks,
~t~

On Fri, Nov 21, 2008 at 6:54 PM, John D. Mitchell <[EMAIL PROTECTED]>wrote:

> On Friday 2008.11.21, at 02:35 , Tamás Cservenák wrote:
> [...]
>
>> Thanks for the tip. That means, that the Application must be aware that it
>> is fronted by mod_proxy? Is there some possibility (or even theoretical
>> chance) to have some kind of "fallback" mechanism? Will look into restlet
>> sources today...
>>
>
> Well, yes and no.
>
> I don't know of any guaranteed, general way to know that it's a proxy and
> not an original client -- that's a large rabbit hole.
>
> One hack would be to change the getAddresses() code can do the underlying
> call to InetAddress.getLocalHost().getHostAddress() and only if it fails or
> returns localhost then try the extraction of "X-Forwarded-For:" and only if
> that fails too then return localhost.  This handles the dominant case, such
> as yours, where there's a fronting proxy on the local machine.
>
>
> However, I think this entire approach of having getAddresses() hide the
> reality of X-Forwarded-For: from the applications is actually a bad idea.
>  Different applications and/or in different deployment environments do
> really need to understand the difference between the upstream client,
> whether or not an X-Forwarded-For: exists or not, and can decide for itself
> whether or not it needs the information out of X-Forwarded-For: header (and
> how much to trust that information).
>
> So, I'd move the X-Forwarded-For: stuff out of getAddresses() and into a
> getForwardedAddresses().  Then all applications can do what's correct for
> them.
>
> Take care,
> John
>
>


-- 
Thanks,
~t~

RE: Getting the Client address from request

[Jerome Louvel]

Hi all,
 
I agree with John regarding the current API : we should refactor. So, I've 
entered a RFE:
 
"Add Request#getForwardedAddresses() method"
http://restlet.tigris.org/issues/show_bug.cgi?id=668
 
Tamas, if you are interested in working on a patch, that would be cool!
 
Best regards,
Jérôme Louvel
--
Restlet ~ Founder and Lead developer ~  <http://www.restlet.org/> 
http://www.restlet.org
Noelios Technologies ~ Co-founder ~  <http://www.noelios.com/> 
http://www.noelios.com
 

  _  

De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Tamás Cservenák
Envoyé : samedi 22 novembre 2008 17:15
À : discuss@restlet.tigris.org
Objet : Re: Getting the Client address from request


Hi there, 

yes, i must agree with you. 

(and follows a monologue :)

But the problem is with those companies/users/people, that their ITs guys -- 
for some reason, even today in 2009 -- are not accepting the fact that fronting 
a Jetty (or any other _modern_ Servlet Container) with a httpd + mod_proxy is 
just an overhead (not to mention that it kills Jetty's advanced connection 
pooling). Ok, there are situations where you want to have some sort of 
integration with some existing vhosts, etc. 

I'm just saying that people chooses "too easy and almost automatically" to 
front Java Server Container with mod_proxy, even if they don't have to (so, 
excluding the really justified cases). Simply because they were doing it before 
6 years.

Personally, OSes has many other advanced tools (like iptables and forwarding 
port 80 to higher one, and avoiding the need for running java as root, etc), 
that makes httpd used for only one Java app a nonsense. Again, let's exclude 
the _justified_ cases of using mod_proxy.

Luckily, in this case the IP address is taking part in logs and feeds only, so 
they are not vital or security related at all (but they could be). It is simply 
annoying to always have "127.0.0.1" in them, instead of "real" IP.


Thanks,
~t~


On Fri, Nov 21, 2008 at 6:54 PM, John D. Mitchell <[EMAIL PROTECTED]> wrote:


On Friday 2008.11.21, at 02:35 , Tamás Cservenák wrote:
[...] 


Thanks for the tip. That means, that the Application must be aware that it is 
fronted by mod_proxy? Is there some possibility (or even theoretical chance) to 
have some kind of "fallback" mechanism? Will look into restlet sources today...



Well, yes and no.

I don't know of any guaranteed, general way to know that it's a proxy and not 
an original client -- that's a large rabbit hole.

One hack would be to change the getAddresses() code can do the underlying call 
to InetAddress.getLocalHost().getHostAddress() and only if it fails or returns 
localhost then try the extraction of "X-Forwarded-For:" and only if that fails 
too then return localhost.  This handles the dominant case, such as yours, 
where there's a fronting proxy on the local machine.


However, I think this entire approach of having getAddresses() hide the reality 
of X-Forwarded-For: from the applications is actually a bad idea.  Different 
applications and/or in different deployment environments do really need to 
understand the difference between the upstream client, whether or not an 
X-Forwarded-For: exists or not, and can decide for itself whether or not it 
needs the information out of X-Forwarded-For: header (and how much to trust 
that information).

So, I'd move the X-Forwarded-For: stuff out of getAddresses() and into a 
getForwardedAddresses().  Then all applications can do what's correct for them.

Take care,
John






-- 
Thanks,
~t~

Re: Getting the Client address from request

[Tamás Cservenák]

Hi there,

thanks for asking, but...

I would like to, but currently at Sonatype we are very focused on the
upcoming release, so i cannot participate currently :(


~t~


On Wed, Nov 26, 2008 at 4:23 PM, Jerome Louvel
<[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I agree with John regarding the current API : we should refactor. So, I've
> entered a RFE:
>
> "Add Request#getForwardedAddresses() method"
> http://restlet.tigris.org/issues/show_bug.cgi?id=668
>
> Tamas, if you are interested in working on a patch, that would be cool!
>
> Best regards,
> Jérôme Louvel
> --
> Restlet ~ Founder and Lead developer ~ http://www.restlet.org
> Noelios Technologies ~ Co-founder ~ http://www.noelios.com
>
> 
> De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de
> Tamás Cservenák
> Envoyé : samedi 22 novembre 2008 17:15
> À : discuss@restlet.tigris.org
> Objet : Re: Getting the Client address from request
>
> Hi there,
> yes, i must agree with you.
> (and follows a monologue :)
> But the problem is with those companies/users/people, that their ITs guys --
> for some reason, even today in 2009 -- are not accepting the fact that
> fronting a Jetty (or any other _modern_ Servlet Container) with a httpd +
> mod_proxy is just an overhead (not to mention that it kills Jetty's advanced
> connection pooling). Ok, there are situations where you want to have some
> sort of integration with some existing vhosts, etc.
> I'm just saying that people chooses "too easy and almost automatically" to
> front Java Server Container with mod_proxy, even if they don't have to (so,
> excluding the really justified cases). Simply because they were doing it
> before 6 years.
> Personally, OSes has many other advanced tools (like iptables and forwarding
> port 80 to higher one, and avoiding the need for running java as root, etc),
> that makes httpd used for only one Java app a nonsense. Again, let's exclude
> the _justified_ cases of using mod_proxy.
> Luckily, in this case the IP address is taking part in logs and feeds only,
> so they are not vital or security related at all (but they could be). It is
> simply annoying to always have "127.0.0.1" in them, instead of "real" IP.
>
> Thanks,
> ~t~
>
> On Fri, Nov 21, 2008 at 6:54 PM, John D. Mitchell <[EMAIL PROTECTED]>
> wrote:
>>
>> On Friday 2008.11.21, at 02:35 , Tamás Cservenák wrote:
>> [...]
>>>
>>> Thanks for the tip. That means, that the Application must be aware that
>>> it is fronted by mod_proxy? Is there some possibility (or even theoretical
>>> chance) to have some kind of "fallback" mechanism? Will look into restlet
>>> sources today...
>>
>> Well, yes and no.
>>
>> I don't know of any guaranteed, general way to know that it's a proxy and
>> not an original client -- that's a large rabbit hole.
>>
>> One hack would be to change the getAddresses() code can do the underlying
>> call to InetAddress.getLocalHost().getHostAddress() and only if it fails or
>> returns localhost then try the extraction of "X-Forwarded-For:" and only if
>> that fails too then return localhost.  This handles the dominant case, such
>> as yours, where there's a fronting proxy on the local machine.
>>
>>
>> However, I think this entire approach of having getAddresses() hide the
>> reality of X-Forwarded-For: from the applications is actually a bad idea.
>>  Different applications and/or in different deployment environments do
>> really need to understand the difference between the upstream client,
>> whether or not an X-Forwarded-For: exists or not, and can decide for itself
>> whether or not it needs the information out of X-Forwarded-For: header (and
>> how much to trust that information).
>>
>> So, I'd move the X-Forwarded-For: stuff out of getAddresses() and into a
>> getForwardedAddresses().  Then all applications can do what's correct for
>> them.
>>
>> Take care,
>> John
>>
>
>
>
> --
> Thanks,
> ~t~
>



-- 
Thanks,
~t~