You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Once #276 is merged, the two additional CORs configs (one for the read-endpoint, one for the write-endpoint) are likely sources of confusion for anyone trying to setup a functioning Gaia hub.
This could be alleviated by a background function -- ran once on hub startup -- that performs a check to determine likely incorrect CORs configurations, and console.error with a helpful message.
Due to variance in how cloud storage drivers and Gaia can be configured, this check cannot be 100% accurate for all possible Gaia setups. This means the console error message must be something like:
Detected likely CORs configuration problems: <details...>.
This message can be ignored if you know what you are doing.
Alternatively, this detection could process.exit() with an error message along the lines of:
Detected likely CORs configuration problems <details...>.
If you know what you are doing, this check can be disabled by specifying
`ignoreCorsCheck=true` in config.json or env vars.
Note: an ignoreCorsCheck option should be implemented regardless of the above error handling. Serverless providers which perform a hub startup on every http request will want to disable this option.
A complimentary CORs check could also be performed by having the server initiate a fetch request against both the read and write endpoints, using the same CORs web browser restrictions as a client fetch request. In some ways, this check is a better indicator than driver-specific checks. It also can be a generalized function without any driver-specific code. However, this still only determines potential likely problems -- gaia hubs can be configured ways that make it impossible to internally perform the same http requests that an actual client ends up performing.
Once #276 is merged, the two additional CORs configs (one for the read-endpoint, one for the write-endpoint) are likely sources of confusion for anyone trying to setup a functioning Gaia hub.
This could be alleviated by a background function -- ran once on hub startup -- that performs a check to determine likely incorrect CORs configurations, and
console.error
with a helpful message.Due to variance in how cloud storage drivers and Gaia can be configured, this check cannot be 100% accurate for all possible Gaia setups. This means the console error message must be something like:
Alternatively, this detection could
process.exit()
with an error message along the lines of:Note: an
ignoreCorsCheck
option should be implemented regardless of the above error handling. Serverless providers which perform a hub startup on every http request will want to disable this option.A complimentary CORs check could also be performed by having the server initiate a
fetch
request against both the read and write endpoints, using the same CORs web browser restrictions as a clientfetch
request. In some ways, this check is a better indicator than driver-specific checks. It also can be a generalized function without any driver-specific code. However, this still only determines potential likely problems -- gaia hubs can be configured ways that make it impossible to internally perform the same http requests that an actual client ends up performing.👍 @kantai for the idea
The text was updated successfully, but these errors were encountered: