Authorization Header not working

Support
1

Authorization Header not working

In version 2 which I was previously using, the getAuthorizationHeader file works just fine, but trying to migrate to version 3 and it’s no longer working. The bearer token doesn’t appear to be sent in the in the request headers in v3.

v3

What steps can we follow to reproduce the bug?

  1. First step
  2. Second step
  3. …
const queryString = window.location.search;

const accessToken = queryString.slice(1);

/**
 * Returns the Authorization header as part of an Object.
 *
 * @export
 * @param {Object} [server={}]
 * @param {Object} [server.requestOptions]
 * @param {string|function} [server.requestOptions.auth]
 * @returns {Object} { Authorization }
 */
export default function getAuthorizationHeader({ requestOptions } = {}) {
  const headers = {};

  // Check for OHIF.user since this can also be run on the server
  // const accessToken = user && user.getAccessToken && user.accessToken;

  if (accessToken) {
    headers.Authorization = `Bearer ${atob(accessToken)}`;
  }

  return headers;
}

// new data source

  dataSources: [
    {
      namespace: '@ohif/extension-default.dataSourcesModule.dicomweb',
      sourceName: 'dicomweb',
      configuration: {
        friendlyName: 'AWS S3 Static wado server',
        // name: 'aws',
        // wadoUriRoot: 'https://d33do7qe4w26qo.cloudfront.net/dicomweb',
        // qidoRoot: 'https://d33do7qe4w26qo.cloudfront.net/dicomweb',
        // wadoRoot: 'https://d33do7qe4w26qo.cloudfront.net/dicomweb',
        name: 'dicom-server',
        wadoUriRoot: 'https://rsdicomsrvr.azurewebsites.net/v1',
        qidoRoot: 'https://rsdicomsrvr.azurewebsites.net/v1',
        wadoRoot: 'https://rsdicomsrvr.azurewebsites.net/v1',
        qidoSupportsIncludeField: true,
        imageRendering: 'wadors',
        thumbnailRendering: 'wadors',
        enableStudyLazyLoad: true,
        supportsFuzzyMatching: false,
        supportsWildcard: true,
        staticWado: true,
        singlepart: 'bulkdata,video',
        // whether the data source should use retrieveBulkData to grab metadata,
        // and in case of relative path, what would it be relative to, options
        // are in the series level or study level (some servers like series some study)
        bulkDataURI: {
          enabled: true,
          relativeResolution: 'studies',
        },
        omitQuotationForMultipartRequest: true,
      },
    },]
2

I think this is because most “getAuthorizationHeader” requests are made through “UserAuthenticationProvider” and “userAuthenticationService”.

namespace: ‘@ohif/extension-default.dataSourcesModule.dicomweb’
extensions > default > src > DicomWebDataSource > index.js

3

This is werid, does it still happen in the latest master commit?