Сluster breaks connection.clientAddress

[artpolikarpov]

When I turn on cluster package connection.clientAddress becomes 127.0.0.1. How to fix that?

[arunoda]

That's because sometimes cluster proxy requests. You can get the client address with following header.

• x-forwarded-for

[artpolikarpov]

I know about x-forwarded-for. But I get no x-forwarded-for property in connection.httpHeaders object. :(

That’s all I have:

{ host: 'b1.somehost.io',
'user-agent': 'Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.118 Safari/537.36',
'accept-language': 'ru-RU,ru;q=0.8,en-US;q=0.6,en;q=0.4' } }

[arunoda]

I think, may be meteor is filtering out some headers. I could get this the raw WS connection?

[artpolikarpov]

How to check the raw connection? Now I just console.log(this.connection) inside a method on the server.

[arunoda]

There is no way to get it from meteor's APIs. May be better to ask how to access x-forwarded-for from the meteor's issue list.
I also found this behaviour.

[artpolikarpov]

I believe when my app was behind really proxy (like CloudFlare), x-forwarded-for were in connection.httpHeaders.

What do you think about this package https://github.com/gadicc/meteor-headers? Can it be helpful?

[arunoda]

If so, this seems like a bug. I can look at it.
I havn't used this package.

On Mon, Apr 6, 2015 at 1:16 AM Artem Polikarpov [email protected]
wrote:

I believe when my app was behind really proxy (like CloudFlare),
x-forwarded-for were in connection.httpHeaders.

What do you think about this package
https://github.com/gadicc/meteor-headers? Can it be helpful?

—
Reply to this email directly or view it on GitHub
#39 (comment).