-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Conversation
29f8bf7
to
f1d23c3
Compare
There was a problem hiding this 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
I’m afraid I reviewed yesterday but forgot to hit the button so all my remarks where pending for the night :o
Cool that it’s resolved!
Sent from mobile, pardon the brevity.
… On 30 May 2019, at 10:25, Ifedapo .A. Olarewaju ***@***.***> wrote:
@ifedapoolarewaju commented on this pull request.
In ***@***.***/companion-client/src/RequestClient.js:
> @@ -75,9 +80,48 @@ module.exports = class RequestClient {
return res.json()
}
+ preflight (path) {
+ return new Promise((resolve, reject) => {
+ if (this.preflightDone) {
+ return resolve(this.allowedHeaders.slice())
+ }
+
+ fetch(this._getUrl(path), {
+ method: 'OPTIONS'
+ })
+ .then((response) => {
+ if (response.headers.has('access-control-allow-headers')) {
+ const allowedHeaders = response.headers.get('access-control-allow-headers')
+ .split(',').map((headerName) => headerName.trim().toLowerCase())
+ this.allowedHeaders = this.allowedHeaders.concat(allowedHeaders)
I had changed this yesterday, already. Maybe you needed to do a pull/refresh?
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub, or mute the thread.
|
6443367
to
93e0e5f
Compare
There was a problem hiding this 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
Still getting with 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 |
@arturi fixed, last time hopefully |
} | ||
|
||
fetch(this._getUrl(path), { | ||
method: 'OPTIONS' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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? 🤔
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 👍
There was a problem hiding this comment.
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
also encode versions sent through query params
573c5ee
to
cabff1b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
works for me! 👍
All good! The e2e test failure seems to be about package-lock only, probably be good on master? |
we'll see. Merging now. |
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
|
@ifedapoolarewaju |
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. |
Hmm, then it gets tricky, because Might I ask how your setup is? So you have a customer server that behaves similarly to companion, but isn't companion? |
Exactly. 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. |
No description provided.