Uploaded image for project: 'Data Management'
  1. Data Management
  2. DM-21921

Firefly interaction with asynchronous TAP broken after TAP update

    XMLWordPrintable

    Details

      Description

      Apparently due to the deployment of a more rigorous implementation of TAP by the LSST API Aspect group, and the more consistent application of authorization redirects, the existing Firefly TAP query service fails to operate correctly any more.

      The problem has been narrowed down to the retrieval of the results from the asynchronous query generated in response to user queries in the UI; by all signs, the query is being submitted successfully, and Firefly is following its status successfully as it executes, but the results are not successfully retrieved.

      The current TAP service returns results at a different, non-NCSA hostname from the TAP service itself, informing the client of this with an HTTP redirect. The problem is associated with the following of the redirect. It is suspected that the problem is that the Authorization: Bearer headers needed for the TAP service itself are being passed to the redirected request, and are causing an error there.

      (NB: The synchronous TAP queries used by Firefly to retrieve TAP_SCHEMA data are working correctly.)

      The displayed error is:

      Table Load Error:
      Failed to retrieve data

      This is a complete blocker to the operation of the Portal software for LSST.

        Attachments

          Activity

          Hide
          gpdf Gregory Dubois-Felsmann added a comment -
          Show
          gpdf Gregory Dubois-Felsmann added a comment - Represented by https://jira.ipac.caltech.edu/browse/FIREFLY-414 within IPAC.
          Hide
          cbanek Christine Banek added a comment -

          Since it is basically impossible to know if you should add the auth token to the redirected response (both from an IVOA level, as well as an HTTP level), that you make this a configuration option to either pass the token or not.  If/when we decide to move to a hosted object store, then we will probably use the LSST token on the redirect.  Right now, I'm using a Google bucket, as we don't have an object store, and Google doesn't know what to do with our authorization header, and therefore throws an error.

           

          Here's a pretty good stack overflow about how this happens other places too:

          https://stackoverflow.com/questions/28564961/authorization-header-is-lost-on-redirect

          Also see the rebuild_auth function in requests:

          https://requests.kennethreitz.org/en/master/api/

          Show
          cbanek Christine Banek added a comment - Since it is basically impossible to know if you should add the auth token to the redirected response (both from an IVOA level, as well as an HTTP level), that you make this a configuration option to either pass the token or not.  If/when we decide to move to a hosted object store, then we will probably use the LSST token on the redirect.  Right now, I'm using a Google bucket, as we don't have an object store, and Google doesn't know what to do with our authorization header, and therefore throws an error.   Here's a pretty good stack overflow about how this happens other places too: https://stackoverflow.com/questions/28564961/authorization-header-is-lost-on-redirect Also see the rebuild_auth function in requests: https://requests.kennethreitz.org/en/master/api/
          Hide
          gpdf Gregory Dubois-Felsmann added a comment -

          Under test on lsst-int

          Show
          gpdf Gregory Dubois-Felsmann added a comment - Under test on lsst-int
          Hide
          gpdf Gregory Dubois-Felsmann added a comment -

          This fix is working as expected and necessary on lsst-lsp-int and should now be incorporated into a SUIT (Portal application) release.

          Show
          gpdf Gregory Dubois-Felsmann added a comment - This fix is working as expected and necessary on lsst-lsp-int and should now be incorporated into a SUIT (Portal application) release.
          Hide
          gpdf Gregory Dubois-Felsmann added a comment -

          Fixed in Firefly release-2019.3.1.

          Fix deployed to LSP as part of suit 1.1.1 release, which includes Firefly release-2019.3.2.

          Show
          gpdf Gregory Dubois-Felsmann added a comment - Fixed in Firefly release-2019.3.1 . Fix deployed to LSP as part of suit 1.1.1 release , which includes Firefly release-2019.3.2 .

            People

            Assignee:
            gpdf Gregory Dubois-Felsmann
            Reporter:
            gpdf Gregory Dubois-Felsmann
            Reviewers:
            Gregory Dubois-Felsmann
            Watchers:
            Brian Van Klaveren, Christine Banek, Frossie Economou, Gregory Dubois-Felsmann, Trey Roby
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved:

                Jenkins Builds

                No builds found.