Use the x-client-ip header for file set auth to allow proxying #80
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.
The IIIF - API auth pipeline wasn't able to tell if a request was coming from the reading room because the request to the API is coming from IIIF, not from the client. It used to work because we were persisting the reading room API token, so it would get sent through in the cookie header that the IIIF server forwards to the API, but that was causing other problems.
The solution is to have the IIIF auth function add the real client IP to a custom
x-client-ip
header, which the API can then check against the list of reading room IPs. However, it's important only to use that header on FileSet auth requests, because otherwise any client could spoof a reading room IP address to get private metadata or search results. This PR addresses that by toggling the feature using an environment variable that is only set on thegetFileSetAuthFunction
resource.The PR for the IIIF side of the transaction is nulib/iiif-server-terraform#10.
This code has already been deployed to staging.