fakefront: fix bad Domain set on cookies in some cases #497
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When simulating cloudfront events we used the WSGI SERVER_NAME variable as the cloudfront distribution hostname.
Problem: that variable seems to be the requested bind address passed to gunicorn, but that can be '0.0.0.0' to request binding to all addresses. That variable ends up being included as 'Domain=0.0.0.0' in responses to the /_/cookie endpoint, which causes the cookie never to match since 0.0.0.0 is not a valid domain.
Fix it by picking the hostname out of the HTTP Host header, which should always match the client's idea of the currently accessed host.
It seems like this has always been broken, but it was hidden since fakefront doesn't need/validate signed URLs or cookies. It was uncovered after a recent pipeline-test change which causes tests to more strictly parse returned cookies.