Closed astrofrog closed 4 years ago
@pkgw - this seems to work, and the only errors I now see in the console are related to Access-Control-Allow-Origin
, e.g:
Failed to load resource: ... Origin https://localhost:4443 is not allowed by Access-Control-Allow-Origin
This would work properly if on beta.worldwidetelescope.org though
Hmm, did you see GetProxiedUrl()
in wwtlib/Util.cs
? It also does URL rewriting, mainly to (as the name says) shim in the CORS proxy when relevant. The logic in that function is, I think, currently busted; I restructured things in WorldWideTelescope/wwt-webgl-engine#1, which is a repo that splits out the WebGL rendering engine backend from the webclient app frontend.
edit: And, I do think that in some situations CORS and HTTPS require similar codepaths — WTML files might embed URLs that require CORS proxying or HTTP-to-HTTPS proxying, depending on the characteristics of the webclient origin.
Also, there are at least some local-static-file servers that can turn on CORS headers (namely, npx http-server --cors
), if that helps with your testing.
@pkgw - I'm not sure what the best way is to move forward with this given your work on wwt-webgl-engine - do you want me to copy over some of the restructuring you did there to this PR? At the moment I had got rid of all CORS errors but that was with a very minimal use of the SDK so many URLs were probably not being hit. Do you have more complete examples of use of the SDK that might highlight issues?
As per conversation with @astrofrog, closing this as superseded by the work in the new wwt-webgl-engine
repo, e.g. WorldWideTelescope/wwt-webgl-engine#10.
The aim of this PR is to provide a central place (
URLHelpers
) where we set/patch the domain for URLs, which allows us to switch the URLs to use e.g. beta.worldwidetelescope.org if the current protocol is https.In future we could also provide API calls to change the domains to use on-the-fly.