-
-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
fix: missing mime types and turning off autoindex for js-sdk endpoint #3395
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #3395 +/- ##
==========================================
+ Coverage 98.02% 99.01% +0.98%
==========================================
Files 3 3
Lines 203 203
==========================================
+ Hits 199 201 +2
+ Misses 4 2 -2 ☔ View full report in Codecov by Sentry. |
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.
Avoid adding a custom mime.types.
Hanno Böck has a great talk regarding this matter and different security implications about this if you're interested:
https://www.youtube.com/watch?v=8t8JYpt0egE
Just use /etc/nginx/mime.types
which already gets shipped in all nginx installations AFAIK.
And what do you say we keep each PR on changing one thing?
nginx/mime.types
Outdated
@@ -0,0 +1,99 @@ | |||
|
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 is mime.types
present in all nginx instances in /etc/nginx/mime.types
and it should be included by default. It oddly seems that is has never been included in self-hosted nginx configurations, and old onpremise instances.
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'm so glad I ask your review for this 😀. I'll update the docker compose instead and remove this.
nginx/nginx.conf
Outdated
@@ -89,8 +89,12 @@ http { | |||
proxy_pass http://relay; | |||
} | |||
location ^~ /js-sdk/ { | |||
autoindex on; | |||
root /var/www/js-sdk; | |||
include mime.types; |
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.
It's better to just remove this and include this on all blocks (in http block).
nginx/nginx.conf
Outdated
autoindex off; | ||
etag on; | ||
root /var/www/; | ||
try_files $uri =404; |
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.
What does this tries to do? nginx will return 404 by default if there is a file missing.
etag on; | ||
root /var/www/; | ||
try_files $uri =404; | ||
add_header Access-Control-Allow-Origin *; |
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 don't know the reason of this, but I will go through issues and PRs to figure out what has been broken, but generally this is a bad practice, although may be necessary in some situations, sorry I'm not in the loop completely about js-sdk
, just my two cents on this.
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.
The original sentry cdn has this for some reason. I'm trying to make it as close as possible, so there's that.
etag on; | ||
root /var/www/; | ||
try_files $uri =404; | ||
add_header Access-Control-Allow-Origin *; |
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.
Yeah, probably because sentry.io cannot add all domains and subdomains users are using. Although I'm not sure, and if it responds to any random subdomain which users point to sentry.io.
Anyway I'd suggest at least adding a comment stating that it's recommended for users to change this.
add_header Access-Control-Allow-Origin *; | |
add_header Access-Control-Allow-Origin *; # it is recommended to change this to your sentry (in most cases same as system.url-prefix) |
nginx/nginx.conf
Outdated
root /var/www/js-sdk; | ||
include mime.types; | ||
autoindex off; | ||
etag on; |
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.
Nginx enables etag
by default for static contents and 99.99% it keeps on doing this.
nginx/nginx.conf
Outdated
autoindex on; | ||
root /var/www/js-sdk; | ||
include mime.types; | ||
autoindex off; |
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.
Same as etag
.
So the previous configuration won't resolve the path properly and every Javascript assets file will always returns Content-Type of It also crosses my mind that we should probably update the nginx version? |
docker-compose.yml
Outdated
@@ -457,8 +457,8 @@ services: | |||
volumes: | |||
- type: bind | |||
read_only: true | |||
source: ./nginx | |||
target: /etc/nginx | |||
source: ./nginx/nginx.conf |
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.
docker-compose
makes some problems bind mounting a single file, I'd suggest not changing this.
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.
Then /etc/nginx/mime.types
wouldn't exists on that directory. Do you have any suggestion for this?
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.
No :)
docker-compose
makes some problems bind mounting a single file, I'd suggest not changing this.
It's OK here though as I think more about it. No other process is going to use this file and no other process is going to change this file anyway.
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.
Shall we mount the directory to some other path and do something like this instead then: https://stackoverflow.com/a/30152496/90297
As it would be quite confusing for someone to realize nginx
is the odd one out where we only mount a single file in case we want to add something new in the future?
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.
That would be a worse hack than this IMHO.
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.
see some issues that people can't build their own Docker image since they're behind some sort of hard network proxy/firewall
I wasn't recommending us to build our own image, you can override CMD
and ENTRYPOINT
from docker-compose.yml
.
Anyway, may I offer a compromise then:
- Move the
nginx.conf
file outside of thenginx
directory - Mount that file by itself
It achieves what we want both: hassle-free and not confusing for any onlookers or future maintainers.
WDYT @aldy505?
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.
1. Move the `nginx.conf` file outside of the `nginx` directory
Where do you think would be suitable? I think the appropriate directory would be nginx
directory at last.
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.
My proposal is to move to the top level instead of a dedicated directory to avoid confusion around mounting.
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 the best way to go IMHO as well.
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.
Alright, will do that.
Co-authored-by: Amin Vakil <[email protected]>
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.
LGTM
I'd say we can keep that for another PR, but also fine with bumping it here. |
nginx/nginx.conf
Outdated
autoindex on; | ||
root /var/www/js-sdk; | ||
root /var/www/; | ||
add_header Access-Control-Allow-Origin *; # It is recommended to change this to your sentry (in most cases same as system.url-prefix) |
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.
nit: Would put the comment above the line for readability.
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 has not been fixed yet.
Ping @hubertdeng123 we should be good to go now |
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.
Rejecting for two pending comments
Things weren't as smooth as I thought it would be.
Legal Boilerplate
Look, I get it. The entity doing business as "Sentry" was incorporated in the State of Delaware in 2015 as Functional Software, Inc. and is gonna need some rights from me in order to utilize my contributions in this here PR. So here's the deal: I retain all rights, title and interest in and to my contributions, and by keeping this boilerplate intact I confirm that Sentry can use, modify, copy, and redistribute my contributions, under Sentry's choice of terms.