Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Behind Amazon Beanstalk, not giving me the right ip #7

Closed
newtonianb opened this issue Dec 20, 2013 · 6 comments

Comments

@newtonianb
Copy link

commented Dec 20, 2013

I just tried this on an amazon beanstalk configuration, proxy is set to *. The issue is when I run Request::getClientIp() I get 10.107.15.71 but my client ip is really 203.61.26.1 so it's returning me this other IP I'm not sure what it is.

@fideloper

This comment has been minimized.

Copy link
Owner

commented Dec 20, 2013

Hi! Sorry to hear that!

I have a quick question that's mostly out of my own ignorance - does "behind Amazon Beanstalk" mean "it's using a Load Balancer"? My understanding is that Amazon's ElasticBeanstalk handles deployment, rather than acting as a proxy (such as a load balancer). It's sounds likely that Beanstalk is creating a load balancer for you as part of your deployment strategy?

In any case, let me run some tests against the use of the '*' option to make sure there isn't actually an issue with how I have that code setup.

  1. Can you show me your config file?
  2. Are you able to update the config file to 10.107.15.71 without that IP address changing? (This IP might change if any code changes triggers a re-deployment via Beanstalk, but that's a guess, I haven't used it before and don't know if that's the case)
@fideloper

This comment has been minimized.

Copy link
Owner

commented Dec 20, 2013

Update: I tested using * locally, and it seems to work.

Note that config should be in array if you have one or more IP addresses:

    'proxies' => array(
        '10.107.15.71'
    ),

Or a string to use *:

    'proxies' => '*',

Lastly, you can also use CIDR notation, so consider setting that IP address to attempt to capture IP's in this range: 10.107.*.* (that's 10.107.0.0 - 10.107.255.255) :

    'proxies' => array(
        `10.107.0.0/16`
    ),
@benswinburne

This comment has been minimized.

Copy link

commented Nov 19, 2014

I've just tested this, and it does indeed work when using a correct CIDR address of the Load Balancer, or * ($request->getClientIp()).

That said, Amazon does appear to vary the headers it sends for X-Forwarded-. The Symfony component relies on knowing where to find the scheme/protocol, and the forwarded for headers.

[HTTP_X_FORWARDED_FOR] => x.x.x.x
[HTTP_X_FORWARDED_PROTO] => https

Is it perhaps worth you implementing configuration options to utilise the setTrustedHeaderName method?

$request->setTrustedHeaderName('client_proto', 'HTTP_X_FORWARDED_PROTO');

That way, apps behind other load balancers which may not utilise the exact header name can be easily catered for.

@fideloper

This comment has been minimized.

Copy link
Owner

commented Nov 19, 2014

Yea that would be well worth it I think!

On Tuesday, November 18, 2014, Ben Swinburne notifications@github.com
wrote:

I've just tested this, and it does indeed work when using a correct CIDR
address of the Load Balancer, or * ($request->getClientIp()).

That said, Amazon does appear to vary the headers it sends for
X-Forwarded-. The Symfony component relies on knowing where to find the
scheme/protocol, and the forwarded for headers.

[HTTP_X_FORWARDED_FOR] => x.x.x.x
[HTTP_X_FORWARDED_PROTO] => https

Is it perhaps worth you implementing configuration options to utilise the
setTrustedHeaderName method?

$request->setTrustedHeaderName('client_proto', 'HTTP_X_FORWARDED_PROTO');

That way, apps behind other load balancers which may not utilise the exact
header name can be easily catered for.


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

@fideloper

This comment has been minimized.

Copy link
Owner

commented Jan 26, 2015

@benswinburne it's worth noting that the Header sent as "X-Forwarded_Proto" will actually become HTTP_X_FORWARDED_PROTO in PHP (and thus in Symfony's Request class).

However, this is still a great suggestion. I think HAProxy in particular uses X-Forwarded-Scheme instead of the expected X-Forwarded-Proto header, for example. (See #9)

@fideloper

This comment has been minimized.

Copy link
Owner

commented Jan 26, 2015

Also, functionality added in update to package on develop branch, ready for when Laravel 5 comes out,

Thanks again for the pointer in the direction of setTrustedHeaderName !

@fideloper fideloper closed this Jan 26, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.