[
https://issues.apache.org/jira/browse/CB-1494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13458570#comment-13458570
]
Matti Paksula commented on CB-1494:
-----------------------------------
_> I think it's the entire XFF header value which should be considered here _
Yes maybe, but it makes the current codebase more confusing as it's clearly
being used as a _single address_, (named remoteAddress and being displayed as
one everywhere). We shouldn't expose proxy servers on UI etc.
_> Just taking the first address (original client ip) won't work if those
addresses are behind different NATs - you'll get multiple 192.168.1.2 values
from two different machines. And taking the last doesn't work either, as that's
just your last proxy - which in cases you're trying to handle, will be the same
all the time. _
I don't think that this is the case here: Weinre server is running in an
application server that is a sitting behind a proxy (service providers, such as
Heroku). Clients network configuration (internal addresses) are not visible in
XFF header, because the whole header is created at the point when the request
enters Herokus network. This can be verified with:
{quote}
$ ifconfig | grep 192
inet 192.168.1.118 netmask 0xffffff00 broadcast 192.168.1.255
$ curl --header "X-Forwarded-For: 10.0.0.1, something.else.com"
"http://limitless-shelf-9248.herokuapp.com";
10.0.0.1, something.else.com, 88.112.131.21%
{quote}
In above there is no 192.168.1.118. This is true also for cases when weinre
server is running inside of companys private network. (You can also copy paste
those commands and check it out)
_> I'm happy to display it like we are today, and if it causes a problem later,
we can fix it. Please make sure to HTML escape the string though, likely we
were not doing that before._
This can not be used to XSS, because if XFF contains something else than the
clients IP it will get caught here and no connection will be established:
https://github.com/apache/incubator-cordova-weinre/blob/master/weinre.server/lib/channelManager.coffee#L80
that if check stop it.
Also: this would be completely separate issue and not related to this issue
(support for proxies vs something in UI) -- what is the process here, should
one just open a new bug?
_> Adding a bullet to multiuser.html seems like a good place to doc this._
Should I contribute this with the pull-request?
_> I'd be happy to discuss tests in general at the mailing list, or in a new
bug - take your pick._
I'll open a new bug and make the first test case to get this started.
Currently it's really shaky to develop something.
Also thinking of fixing the documentation.
> Supports running server behind a proxy, such as Heroku Cedar
> ------------------------------------------------------------
>
> Key: CB-1494
> URL: https://issues.apache.org/jira/browse/CB-1494
> Project: Apache Cordova
> Issue Type: New Feature
> Components: weinre
> Reporter: Patrick Mueller
> Assignee: Patrick Mueller
>
> created for https://github.com/apache/incubator-cordova-weinre/pull/10
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
