Story
@maxkadel set up a new endpoint that goes directly to the SWORD endpoint. In testing we have https://sword.pittir-staging.hykucommons.org/ that goes to https://pittir-staging.hykucommons.org/ the former being non-proxied by Cloudeflare. The response sent that gets sent back still reflects the proxied endpoint.
Example request to new endpoint
curl -s -u test:test \
-H "Api-key: test" \
https://sword.pittir-staging.hykucommons.org/sword/v2/service_document | xmllint --format -
Example response from new endpoint
<?xml version="1.0"?>
<service xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dcterms="http://purl.org/dc/terms/" xmlns:sword="http://purl.org/net/sword/terms/" xmlns:h4csys="https://hykucommons.org/schema/system" xmlns="http://www.w3.org/2007/app">
<sword:version>2.0</sword:version>
<workspace collections="327">
<atom:title>Hyrax Sword V2 server</atom:title>
<collection href="https://pittir-staging.hykucommons.org/sword/v2/collections/test-collection-id-123">
<atom:title>General Deposit Review</atom:title>
<h4csys:type>AdminSet</h4csys:type>
.
.
.The collection href still reflects the proxied endpoint so if you have a workflow that builds off the response, then it would go back to sending requests to the proxied endpoint.
A Proposed Solution
Prefacing this by saying this is a naive solution, but we can potentially add a tenant setting to Hyku that gives us the hostname for the SWORD responses. The setting would be read by WillowSword and use that instead of the rails app's actual hostname and fallback to the actual one if nothing is set.
Story
@maxkadel set up a new endpoint that goes directly to the SWORD endpoint. In testing we have
https://sword.pittir-staging.hykucommons.org/that goes tohttps://pittir-staging.hykucommons.org/the former being non-proxied by Cloudeflare. The response sent that gets sent back still reflects the proxied endpoint.Example request to new endpoint
Example response from new endpoint
The collection href still reflects the proxied endpoint so if you have a workflow that builds off the response, then it would go back to sending requests to the proxied endpoint.
A Proposed Solution
Prefacing this by saying this is a naive solution, but we can potentially add a tenant setting to Hyku that gives us the hostname for the SWORD responses. The setting would be read by WillowSword and use that instead of the rails app's actual hostname and fallback to the actual one if nothing is set.