Redirecting links with passwords is raising some CORS issues and the suggestions online is that the changes need to made in the servers where the links are served. Reading up on CORS to bypass the errors.

While using the fetch API, bypassing the CORS issue seems to be possible for http://igbquickload.org/secureQuickloadTestSites/secureSiteTest but the response sent back does not have a 401 Unauthorised status. Instead the status is 0, however, the status in postman sends a 401 with a HTML body which is the correct response. Conclusion: probably because CORS headers sent in the request is incorrect or a CORS middleware issue at the server-side.

Using ajax, CORS issue persists but I was able to bypass that. The problem however is handling the datatype of the response between json and html. The response is html but that throws a CORS error when handled and json throws a unexpected token error. At one point the basic authentication modal appeared once but I was unable to replicate the same results after that.

Another problem is that after the authorization issue is resolved, handling redirection could be problematic because it depends on the response provided by the server we are hitting.

Discussion from scrum:

• We have not observed any track hubs having this problem.
• Question: The track hub scheme / protocol was originally developed to enable users to connect the UCSC Genome Browser to new data that the user deploys on their host or hosts.

Upon discussion, we realized the CORS or redirection issues will never take place for the Track Hub metadata files because these are actually only read ever read by the middleware converter code. That is, the Django back end will retrieve/read the remote Track Hub metadata files and translate them into igb quickload metadata files, which IGB requests from the the middleware.

Seems like this issue is not really related to the Track Hub code itself because the "converted" quickload metadata "files" will never be password-protected or redirected because we control the middleware.

Looks like this is not a problem related to track hubs because the middleware handles (or should handle) redirections related to retrieving metadata files from track hubs and there's no way the UCSC Genome Browser will ever be able to display data or track hubs that are password-protected due to how the UCSC browser is implemented.

Just for fun, look into whether UCSC Genome Browser can display data from a password-protected track hub site (where the metadata files require password authentication) or if it can display data files that are password-protected. Check the help list for people requesting such a feature : password protection for data or metafile files.

Moving to Closed.