Uploaded image for project: 'IGB'
  1. IGB
  2. IGBF-3211

Update logic to send redirect url to IGB Data Source endpoint

    Details

    • Type: Task
    • Status: Closed (View Workflow)
    • Priority: Blocker
    • Resolution: Done
    • Affects Version/s: None
    • Fix Version/s: None
    • Labels:
      None

      Description

      When the user clicks on Add Hub to IGB, the logic should follow the redirects and send IGB the final one. See IGBF-3196 (IGB data source logic cannot follow redirects see full comment )

        Attachments

          Issue Links

            Activity

            Hide
            karthik Karthik Raveendran added a comment -

            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.

            Show
            karthik Karthik Raveendran added a comment - 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.
            Hide
            karthik Karthik Raveendran added a comment -

            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.

            Show
            karthik Karthik Raveendran added a comment - 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.
            Hide
            ann.loraine Ann Loraine added a comment - - edited

            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.

            Show
            ann.loraine Ann Loraine added a comment - - edited 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.
            Hide
            ann.loraine Ann Loraine added a comment - - edited

            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.

            Show
            ann.loraine Ann Loraine added a comment - - edited 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.

              People

              • Assignee:
                karthik Karthik Raveendran
                Reporter:
                karthik Karthik Raveendran
              • Votes:
                0 Vote for this issue
                Watchers:
                Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: