Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

companion,companion-client: send uppy-versions header to companion #1612

Merged
merged 7 commits into from
Jun 26, 2019

Conversation

ifedapoolarewaju
Copy link
Contributor

No description provided.

kvz
kvz previously requested changes May 30, 2019
Copy link
Member

@kvz kvz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lgtm! Just some minor nitpicks

packages/@uppy/companion/test/__tests__/companion.js Outdated Show resolved Hide resolved
packages/@uppy/companion-client/src/RequestClient.js Outdated Show resolved Hide resolved
packages/@uppy/companion-client/src/RequestClient.js Outdated Show resolved Hide resolved
@kvz
Copy link
Member

kvz commented May 30, 2019 via email

Copy link
Contributor

@goto-bus-stop goto-bus-stop left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

functionality LGTM, imo the promise stuff does make a big difference here but i know you felt differently last time, so you can ignore my suggestion there if you like

@arturi
Copy link
Contributor

arturi commented Jun 11, 2019

Still getting with uppy@1.0.1 (which doesn’t send version):

TypeError: Cannot read property 'version' of null
    at Object.exports.gte (/Users/artur/Projects/transloadit/uppy/packages/@uppy/companion/src/server/helpers/version.js:10:25)

Left a comment about the possible cause.

Please test with npm run web:start and http://localhost:4000 homepage, it still uses uppy@1.0.1 on the homepage in this PR.

@ifedapoolarewaju
Copy link
Contributor Author

@arturi fixed, last time hopefully

}

fetch(this._getUrl(path), {
method: 'OPTIONS'
Copy link
Contributor

@goto-bus-stop goto-bus-stop Jun 16, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm actually getting an error on this because OPTIONS is not in the CORS whitelist …
image

Request headers:
image

Response headers:
image

If this is the case we may need a new separate endpoint that we can just GET after all :(

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am unable to reproduce the issue locally with firefox. We've always allowed all methods for all endpoints

Are you using the companion standalone server when testing? Also are you able to reproduce this with other providers asides S3? Here's my network log when testing with instagram on firefox

Screenshot 2019-06-18 at 11 39 30 AM

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did renee test it against transloadit? Can you? Maybe we're messing something up over there?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ahh…I tested using the examples/aws-companion example in this repo, which does not use the standalone server, and uses the default configuration of the cors module. It doesn't do this thing: https://github.com/expressjs/cors#enabling-cors-pre-flight

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did renee test it against transloadit? Can you? Maybe we're messing something up over there?

Transloadit directly uses the standalone server so I wouldn't think we would be messing anything up there.

Ahh…I tested using the examples/aws-companion example in this repo, which does not use the standalone server

Ah alright, it makes sense now.

Users who have their own personalized express servers are left to determine what methods they allow on their servers, but maybe we should change this and let the companion pluggable app set the allowed methods for its own endpoints 🤔

Also, should this still be considered a breaking change if it breaks only for users who don't use the standalone server, and happen not to allow the OPTIONS method on their server? 🤔

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, the entire upload fails right now if the preflight request fails, maybe we can change it so the preflight request failure is caught, and we use the default allowedHeaders in that case?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Transloadit directly uses the standalone server so I wouldn't think we would be messing anything up there.

That's true but it does pass through HAProxy which does/can tamper with headers. Not the issue right now it seems, but I thought i'd add that as a friendly reminder here to save us a possible headache later.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's true but it does pass through HAProxy which does/can tamper with headers

Ah ok, I thought you once mentioned that it does almost nothing (for the case of companion) but forward requests to companion, so I was working with that.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe we can change it so the preflight request failure is caught, and we use the default allowedHeaders in that case?

will do 👍

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@goto-bus-stop I have made an update.

PS: I had to force push because I did a rebase to resolve conflicts

@ifedapoolarewaju ifedapoolarewaju force-pushed the preflight-version-header branch from 573c5ee to cabff1b Compare June 20, 2019 06:04
Copy link
Contributor

@goto-bus-stop goto-bus-stop left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

works for me! 👍

@arturi
Copy link
Contributor

arturi commented Jun 25, 2019

All good! The e2e test failure seems to be about package-lock only, probably be good on master?

@ifedapoolarewaju
Copy link
Contributor Author

The e2e test failure seems to be about package-lock only, probably be good on master?

we'll see. Merging now.

@ifedapoolarewaju ifedapoolarewaju merged commit b25f243 into master Jun 26, 2019
@delete-merged-branch delete-merged-branch bot deleted the preflight-version-header branch June 26, 2019 11:03
@davekiss
Copy link
Contributor

Just a note for others, I had to add the following headers to my preflight CORS response on a custom serverless Express instance in order to get rid of some breaking errors introduced by this PR

  res.header("Access-Control-Allow-Methods", "OPTIONS, GET, POST, PATCH, PUT");
  res.header("Access-Control-Allow-Credentials", "true");
  res.header("Access-Control-Expose-Headers", "Access-Control-Allow-Headers");

@Shoroh
Copy link

Shoroh commented Aug 18, 2019

@ifedapoolarewaju
Is there a way to disable CORS preflight at all? I don't need it, and my server doesn't support it.

@ifedapoolarewaju
Copy link
Contributor Author

@Shoroh As seen, in this PR, subsequent versions of companion will support it internally, and there'll be no need to explicitly add this to your server.

@Shoroh
Copy link

Shoroh commented Aug 30, 2019

I don't use the companion, I create my own. I use only frontend Uppy client, and I don't want it to make OPTIONS requests.

@ifedapoolarewaju
Copy link
Contributor Author

ifedapoolarewaju commented Aug 30, 2019

Hmm, then it gets tricky, because companion-client expects / assumes that it's communicating with companion.

Might I ask how your setup is? So you have a customer server that behaves similarly to companion, but isn't companion?

@Shoroh
Copy link

Shoroh commented Aug 30, 2019

you have a customer server that behaves similarly to companion, but isn't companion?

Exactly.
I use Ruby On Rails backend with "shrine" gem. The gem provides the similar to companion API for direct upload. Like, Uppy asks for the direct link, shrine returns one, everyone is happy.

Except for that thing Ruby On Rails doesn't support Options requests out of the box. And it's ok, cause I don't see any reason to support it to get the direct link.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants