Companion - setup issues (password argument / cipher?)

Uppy
1

Hi all, I really love the concept and execution of the product, am really hoping to make it a key part of an upcoming project.

I had some issues following the Companion tutorial. Some of the anchor links are disconnected and it feels like it’s been rewritten without being fully checked? I noticed a few references to the uppy-server rename, perhaps someone who knows the system well could take a look, I feel unqualitied to make a PR, though if we can get this sorted I may be able to work out what went wrong and do so in return :slight_smile:

Companion installed via a vanilla express app + the npm install @uppy/companion line. I could not get the standalone install + “companion” to work.

Ref. getting up and running with the Companion + Oauth side of the server (all other components working correctly - direct uploads, URL uploads including WebSockets reverse proxying back through nginx on the Companion component).

Both with Dropbox and Google Drive I get this message:

TypeError [ERR_INVALID_ARG_TYPE]: The "password" argument must be one of type string, Buffer, TypedArray, or DataView. Received type undefined at Cipher.createCipher (internal/crypto/cipher.js:90:11) at new Cipher (internal/crypto/cipher.js:126:16) at Object.createCipher (crypto.js:101:10) at module.exports.encrypt (/home/deploy/node_modules/@uppy/companion/lib/server/helpers/utils.js:92:27) at setState (/home/deploy/node_modules/@uppy/companion/lib/server/helpers/oauth-state.js:19:12) at Object.module.exports.generateState (/home/deploy/node_modules/@uppy/companion/lib/server/helpers/oauth-state.js:8:12) at connect (/home/deploy/node_modules/@uppy/companion/lib/server/controllers/connect.js:12:28) at Layer.handle [as handle_request] (/home/deploy/node_modules/express/lib/router/layer.js:95:5) at next (/home/deploy/node_modules/express/lib/router/route.js:137:13) at exports.hasSessionAndProvider (/home/deploy/node_modules/@uppy/companion/lib/server/middlewares.js:11:12)

I’m not 100% certain my keys are correctly installed (though I believe they are - in the express server providerOptions hash) but this feels like a package version issue? Readout of some components below, hopefully its of help.

node -v 
v10.11.0
npm -v
6.4.1
 sudo nginx -v
nginx version: nginx/1.14.0 (Ubuntu)
nodejs -v
v8.10.0
2

Express js server setup:

var express = require('express')

var bodyParser = require('body-parser')

var session = require('express-session')

var companion = require('@uppy/companion')

 

var app = express()

app.use(bodyParser.json())

app.use(express.static('html'))

app.use(session({secret:xxxxxxxx}))

app.use((req, res, next) => {
  res.setHeader('Access-Control-Allow-Origin', req.headers.origin || '*')
  res.setHeader(
    'Access-Control-Allow-Methods',
    'GET, POST, OPTIONS, PUT, PATCH, DELETE'
  )
  res.setHeader(
    'Access-Control-Allow-Headers',
    'Authorization, Origin, Content-Type, Accept'
  )
  res.setHeader('Access-Control-Allow-Credentials', 'true')
  next()
})

// Routes
app.get('/', (req, res) => {
  res.setHeader('Content-Type', 'text/plain')
  res.send('Welcome to Companion')
})

// be sure to place this anywhere after app.use(bodyParser.json()) and app.use(session({...})
const options = {
  providerOptions: {
    dropbox: {
      key: "xx", secret: "xx"
    },
  },
  server: {
    host: 'localhost:3020',
    protocol: 'http',
  },
  filePath: '/home/deploy/companion-data/'
}
 
app.use(companion.app(options))

// handle 404
app.use((req, res, next) => {
  return res.status(404).json({ message: 'Not Found' })
})

// handle server errors
app.use((err, req, res, next) => {
  console.error('\x1b[31m', err.stack, '\x1b[0m')
  res.status(err.status || 500).json({ message: err.message, error: err })
})

companion.socket(app.listen(3020), options)

console.log('Welcome to Companion!')
console.log(`Listening on http://0.0.0.0:${3020}`)
3

(Partial) SOLUTION. I’ve not quite solved this yet… options block:

const options = {
  providerOptions: {
    dropbox: {
      key: "xx",
      secret: "yy"
    },
  },
  server: {
    host: 'my-actual-companionnginx-url',
    protocol: 'https',
  },

  sendSelfEndpoint: "my-actual-companion-url??",

  secret: 'blah',
  filePath: '/home/deploy/companion-data/',
  debug: true
}

Now at least am connection to Dropbox and coming back - not yet connecting to select files…

4

Some of the anchor links are disconnected and it feels like it’s been rewritten without being fully checked?

That sounds about right…sorry for the trouble! :see_no_evil:

That error is SUPER cryptic, but it happens because there is another option, secret, that is required. This secret is used for encryption of authentication keys (keys for Dropbox etc are stored encrypted in the user’s browser, rather than on Companion servers, so that hacking a Companion server doesn’t leak any user data).

Making the errors nicer is on our TODO list, like so many things :sweat_smile: In the standalone server, we generate a random one if it’s not defined, but it should ideally be consistent across server restarts and stuff.

You can generate one using the Node REPL:

fs.writeFileSync('secret.dat', crypto.randomBytes(32))

then use it like so:

const options = {
  secret: fs.readFileSync('/path/to/secret.dat')
}

e; Oh, I missed that you already added it in your latest post. Are you seeing any errors in the browser / browser console / Companion console output with that setup?

5

Hi Renee,
Yes I think I’ve gotten Dropbox sync working in it’s entirety. Not 100% sure which step was the clincher but once I finally got the errors before the browser redirected to Dropbox solved it started to click into place.
I think the mashup of standalone and custom server variables/setup in the tutorial are what is fundamentally confusing, and a longer form step by step setup guide might be helpful — ie. clean Ubuntu server, install tusd (and how to make that a system daemon?); install nginx and express and npm and configure a basic endpoint.
Looking forward to seeing how the product helps me :slight_smile:
THanks for your reply
david