You are viewing a plain text version of this content. The canonical link for it is here.
Posted to pluto-user@portals.apache.org by Jason Novotny <no...@aei.mpg.de> on 2004/03/20 21:47:02 UTC

using getRemoteAddr

    Hi,

    In a WebSphere portlet I was using getRemoteAddr to monitor a client 
ip, but now it seems the spec. specifies this should return null. What 
is the reasoning behind this? Now it doesn't seem possible to migrate 
this portlet to be JSR compliant... is there a workaround?

    Thanks, Jason

Re: using getRemoteAddr

Posted by Rickard Öberg <ri...@dreambean.com>.
Stefan Hepper wrote:
>>    In a WebSphere portlet I was using getRemoteAddr to monitor a 
>> client ip, but now it seems the spec. specifies this should return 
>> null. What is the reasoning behind this? Now it doesn't seem possible 
>> to migrate this portlet to be JSR compliant... is there a workaround?
>>
>>    Thanks, Jason
> 
> Hi Jason,
> this does not work because the portlet is shielded by the portal from 
> the client. This will never work if the portlet is running remotely, 
> even in the WebSphere case it does only work for the local case.
> 
> To really get this kind of information you would need a service that the 
> portal offers to the portlet. In scenarios with proxies, caches, load 
> balancers etc in between the portal and the client there may be 
> situations where even the portal will not get access to the client IP.

But in such cases the intermediate steps should use the 
"x-forwarded-for" header, which could be used at any point in the 
processing, including the portlet invocation.

/Rickard

Re: using getRemoteAddr

Posted by Stefan Hepper <st...@hursley.ibm.com>.
Jason Novotny wrote:

> 
>    Hi,
> 
>    In a WebSphere portlet I was using getRemoteAddr to monitor a client 
> ip, but now it seems the spec. specifies this should return null. What 
> is the reasoning behind this? Now it doesn't seem possible to migrate 
> this portlet to be JSR compliant... is there a workaround?
> 
>    Thanks, Jason
> 
> 

Hi Jason,
this does not work because the portlet is shielded by the portal from 
the client. This will never work if the portlet is running remotely, 
even in the WebSphere case it does only work for the local case.

To really get this kind of information you would need a service that the 
portal offers to the portlet. In scenarios with proxies, caches, load 
balancers etc in between the portal and the client there may be 
situations where even the portal will not get access to the client IP.

Stefan