ipAddr sometimes wrong

[dan335]

ipAddr is correct for about 90% of users. About 10% have it as 127.0.0.1. I have HTTP_FORWARDED_COUNT set to 1. Any idea why it would sometimes be correct and sometimes not?

[mizzao]

I'm not sure, but we use the IP address that is provided by Meteor so I'd try and replicate an example where this happens and open an issue with them.

Perhaps the user is behind a corporate proxy and there are multiple X-Forwarded-For headers?

[dan335]

connection.httpHeaders shows the x-forwarded-for right? I'll try this and see what happens

Accounts.onLogin(function(info) {
    console.log(info.connection.clientAddress);
    console.log(info.connection.httpHeaders);
})

[dan335]

It looks like x-forwarded-for sometimes has two ips seperated by a comma. The first is their ip and the second is 127.0.0.1. When that happens clientAddress is 127.0.0.1 I'll post an issue for it and see what they say.

[dan335]

meteor/meteor#3981

[dan335]

What do you think about doing what glasser said in meteor/meteor#3981? Parsing x-forwarded-for and choosing the correct one?

[mizzao]

I don't know, that seems like something that we should get into Meteor core, not necessarily this package. But we could make a workaround until it is accepted, if you want to try a PR.

I think in some previous user IP packages, someone came up with the correct computation of pulling out IPs from X-Forwarded-For.

[dan335]

Here's some info I found about it. http://serverfault.com/a/414166 Sounds like it should go from right to left and pick the first one that's not a trusted ip. Trusted ips I guess could be 192.168.2.1 and 127.0.0.1.

[lorensr]

FYI for anyone getting 127.0.0.1 and no x-forwarded-for, mup ssl may be the cause: meteorhacks/cluster#54

[mizzao]

I guess for trusted IPs the user would have to be able to specify them somehow in the config for this package, possibly with subnet masks (i.e. 192.168.0.0/16, 127.0.0.1, 172.16.0.0/12, 10.0.0.0/8). Seems complicated, anyone want to implement it? :)