This repository has been archived by the owner. It is now read-only.
add reverse-proxy for CSP violations #1426
Closed
Comments
vladikoff
added a commit
to vladikoff/fxa-content-server
that referenced
this issue
Oct 15, 2015
vladikoff
added a commit
to vladikoff/fxa-content-server
that referenced
this issue
Oct 15, 2015
vladikoff
added a commit
to vladikoff/fxa-content-server
that referenced
this issue
Oct 16, 2015
vladikoff
added a commit
to vladikoff/fxa-content-server
that referenced
this issue
Oct 27, 2015
vladikoff
added a commit
to vladikoff/fxa-content-server
that referenced
this issue
Nov 3, 2015
vladikoff
added a commit
to vladikoff/fxa-content-server
that referenced
this issue
Nov 4, 2015
vladikoff
added a commit
to vladikoff/fxa-content-server
that referenced
this issue
Nov 12, 2015
vladikoff
added a commit
that referenced
this issue
Nov 13, 2015
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
When a Content Security Policy violation report URL lives in the same origin as the page which included the CSP header, the report will contain more information, which can be very helpful to track down what exactly is causing the problem. We're currently sending violation reports to a separate server (and will probably continue this in the future). To do both, we need to configure a reverse proxy, so CSP reports from e.g.
https://accounts.stage.mozaws.net/signupcan be reported tohttps://accounts.stage.mozaws/net/_/csp-violationand then get forwarded tohttps://fxa-csp-violations.stage.mozaws.net/_/csp-violation. We should probably build this as an nginx rule, but it could also be done with a route in the node.js server.In stage/production we use the nginx configuration to deliver the CSP header anyways, so it's a good fit to use the nginx config for the reverse proxy too: it's easier to keep the header and the proxy in sync by having them live in the same config file.
The text was updated successfully, but these errors were encountered: