Authorization header removed from companion request

I’m using Uppy with the S3 Multipart plugin and hitting a Shrine companion. The companion endpoint requires authentication via header and this is having a problem. It looks like this:

1. Uppy performs OPTIONS request, which fails with a 401 but still returns a response that includes Access-Control-Expose-Headers: Link, Per-Page, Total, X-Total-Pages, Authorization.
2. Because it did not return 200, it seems to be removing headers from provided to my Uppy request in the companionHeaders key.
3. The subsequent presign request fails because it is missing the header.

If I remove the authentication requirement from my endpoint, the OPTIONS request succeeds and the subsequent presign POST includes the Authorization header even though it doesn’t need it.

If I start logging in RequestClient, I see it stripping headers in preflightAndHeaders here. I can patch the prototype like this to get things working despite the failure of the OPTIONS request.

(RequestClient.prototype as any).preflightAndHeaders = function(path: any) {
  return Promise.all([this.preflight(path), this.headers()]).then(function(_ref) {
    return _ref[1];
  });
};

This workaround got me up and running but took a bit of digging and I don’t trust it for the longterm. Would really appreciate your help with this.

[chasevida]

I had similar issues to those described here, the Authorization header was never sent. Initially I thought this was due to cors as discussed but that turned out not to be the case even when the preflight was successful, it was still not added (I think this is due to how some browsers handle certain header values for security purposes i.e. they don’t expose them). The companionHeaders didn’t seem to be passed along either and after tracing through all the code including the RequestClient I found there is an allowedHeader of uppy-auth-token which is available presumably for this very reason. So to get this working I was able to replace Authorization with uppy-auth-token and in the server use that to verify the request.

@oneEyedSunday a solution for you might look like the below which builds off of the examples documented here https://uppy.io/docs/companion/.

// server.js

const cors = require('cors')
const jwt = require('jsonwebtoken')

// Setting up the CORS
const corsOptions = {
  origin: '*',
  credentials: true,
  allowedHeaders: ['Authorization', 'Origin', 'Content-Type', 'Accept', 'uppy-auth-token'], // 'uppy-auth-token' is required!
  methods: ['GET', 'HEAD', 'PUT', 'PATCH', 'POST', 'DELETE', 'OPTIONS'], // make sure OPTIONS is included
  optionsSuccessStatus: 200,
}

app.use(cors(corsOptions))

const authorize = (req, res, next) => {
  const authHeader = req.headers.authorization || req.headers['uppy-auth-token'] // get the 'uppy-auth-token'

  if (authHeader) {
    const token = authHeader.split(' ')[1]

    jwt.verify(token, accessTokenSecret, (err, decoded) => {

      if (err) {
        return res.sendStatus(403)
      }

      next()
    })
  }
  else {
    res.sendStatus(401)
  }
}

app.use('/upload', authorize, companion.app(options))

And in the client:

// client.js

uppy.use(AwsS3Multipart, {
  ...options,
  companionHeaders: {
    'uppy-auth-token': `Bearer ${getAuthToken()}`,
  },
  companionUrl: uploadUrl,
})

[sergio-dreamcode]

Hello, I did some extra research and it is a security mechanism that browsers have related with headers, and as @subvertallchris mentioned it’s a server configuration issue, however it would be helpful if that can be documented.

What’s happening is this: Preflight request by default will only return 7 valid headers (I tested in Firefox and Chrome and not all 7 are always returned) but they are limited to the next ones (based on [0]):

• Cache-Control
• Content-Language
• Content-Length
• Content-Type
• Expires
• Last-Modified
• Pragma

So if we want the preflightAndHeaders method not to delete the Authorization header or any other header we use, we must configure the server so it allows the Authorization header in the Access-Control-Expose-Headers response header for preflight.

This StackOverflow post was helpful to me.