-
-
Notifications
You must be signed in to change notification settings - Fork 368
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
Update Symfony documentation #923
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ker0x thank you very much for this.
TBH, I was planning to do it this week 😄
I think the bridge is now stable enough to make this move and encourage new comers to use it
@mnapoli it would be nice to tag a new version of the bridge to get the latest fixes from brefphp/symfony-bridge#37, brefphp/symfony-bridge#39 and brefphp/symfony-bridge#41 without having to require dev-master
🙂
Here is a first round of review !
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here are some other small things I noticed 🙂
9b62e9a
to
b4c960d
Compare
…the recipe, fix wording
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a minor comment but all seem good to me ✔️
Thanks @ker0x
Co-authored-by: Thibault RICHARD <[email protected]>
My knowledge in Symfony is completely |
@deleugpn I understand that you are not knowledgable with Symfony. I'll try to ask on Slack if Symfony users could check this PR and review/approve it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you.
I've added some thoughts. Feel free to skip, ignore or add to a follow-up PR.
# trust "X-Forwarded-*" headers coming from API Gateway | ||
trusted_headers: ['x-forwarded-for', 'x-forwarded-proto', 'x-forwarded-port'] | ||
# trust the remote address because API Gateway has no fixed IP or CIDR range that we can target | ||
trusted_proxies: '127.0.0.1,REMOTE_ADDR' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't $_SERVER['REMOTE_ADDR']
always 127.0.0.1 on Lambda?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it is https://github.com/brefphp/bref/blob/master/src/Event/Http/FpmHandler.php#L184
So we could change it to only keep the IP
trusted_proxies: '127.0.0.1,REMOTE_ADDR' | |
trusted_proxies: '127.0.0.1' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
to whitelist [every CloudFront IP](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/LocationsOfEdgeServers.html) | ||
**When using CloudFront** on top of API Gateway, you will not be able to retrieve the client IP address, and you will instead get one of Cloudfront's IP when | ||
calling `Request::getClientIp()`. If you really need this, you will need to | ||
whitelist [every CloudFront IP](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/LocationsOfEdgeServers.html) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know you did not change this. But this is not really true.
You can just update your index.php file with:
// Get user IP:
if (isset($_SERVER['LAMBDA_REQUEST_CONTEXT'])) {
$context = json_decode($_SERVER['LAMBDA_REQUEST_CONTEXT'], true);
$_SERVER['HTTP_X_FORWARDED_FOR'] = $context['identity']['sourceIp'] ?? '';
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was some discussions about this on Slack and it seems to work fine but we weren't able to say if this is working in all scenarios. And I wasn't able to find AWS docs that states clearly what they put in it.
If you are sure about that, I'm a 💯 to document it 👍
|
||
```bash | ||
php bin/console assets:install --env prod | ||
# if using Webpack Encore, additionally run | ||
yarn encore production | ||
aws s3 sync public/ s3://<bucket-name>/ --delete --exclude index.php | ||
aws s3 sync public/ s3://<bucket-name>/ \ | ||
--delete \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you delete stuff, it would mean that there is some downtime for your application. (ie no assets)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True, I think the solution is to sync twice. First without --delete
and then with the --delete
option.
Or do you have another solution ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll just leave the old files :)
--delete \ | ||
--exclude index.php \ | ||
--exclude public/build/manifest.json \ | ||
--exclude public/build/entrypoint.json |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, one should configure cace control (But only if one use unique filenames, ie hashes)
--cache-control max-age=31449600,immutable
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
File hasing is enabled by default with Webpack Encore. But I'm not sure it's true for third party bundles providing assets (like EasyAdmin or Sonata for example) moved by bin/console assets:install
in bundles
.
|
||
```yaml | ||
# config/packages/prod/framework.yaml | ||
# config/packages/prod/assets.yaml | ||
|
||
framework: | ||
assets: | ||
base_urls: 'https://<bucket-name>.s3.amazonaws.com' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we really care about S3? Why not do cloudfront directly?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is simpler to setup for beginners and if you put Cloudfront in front of your app, then this is not needed I think.
@Nyholm thank you, this is very much appreciated. I think we can address the trusted proxies IP here, and I'll open a follow-up PR for assets and the source IP thing because they could need more work to get them right. This would allow us to move this PR forward and merge it. |
Thank you all! |
Due to recent changes in the Symfony Bridge package and my personal experience using Bref with Symfony, I have updated the documentation accordingly.
All feedbacks and improvments are welcome 😃!
When this PR will be reviewed and approved, a new released of the the
symfony-bridge
should be made because currently the bridge don't require bref to be install.