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

Full header information not sent to companion on Firefox for XHR/URL upload #5095

Open
2 tasks done
Kelketek opened this issue Apr 16, 2024 · 4 comments
Open
2 tasks done
Labels

Comments

@Kelketek
Copy link

Initial checklist

  • I understand this is a bug report and questions should be posted in the Community Forum
  • I searched issues and couldn’t find anything (or linked relevant results below)

Link to runnable example

No response

Steps to reproduce

  • Set up XHR Uploader with URL upload and dashboard
  • Set up companion to use the same domain as the upload page (like, have nginx forward /companion/ to companion and the rest to the web app)
  • Drag and drop from one window in your browser to another browser window with drag-and-drop target uppy
  • Notice that this works in Chrome, and that the full set of headers is sent to the upstream endpoint
  • Try it in Firefox, find a limited set of headers are sent

Expected behavior

Firefox should be sent the full header information, including cookies, just as is done with Chrome

Actual behavior

Firefox gets a very limited set of headers, authentication fails

@Murderlon
Copy link
Member

Murderlon commented Apr 17, 2024

That's odd, not sure how as we just use the XMLHttpRequest API to add headers, so it might be a browser bug?

I have created a new util (#5073) to refactor xhr-upload (#5074) in preparation for aligning the api with tus (#5094). Maybe these change will already help 🤔

@Kelketek
Copy link
Author

@Murderlon Maybe, but I think there's more to it than that. One especially weird thing I saw when chasing down this bug was that the Chrome-sourced requests were proxied through Cloudflare like normal requests from the client are. However the Firefox ones bypassed it, and contacted localhost, following the hosts file. When I removed the hosts entry, they both ended up proxying through Cloudflare, but the Firefox one didn't contain the headers.

It suggests that the request to the backend on Chrome comes from the client whereas the request on Firefox comes from Companion. If they both came from companion I'd expect that they'd both have respected the hosts file. If they'd both come from the client I'd have expected the headers to be fully included. I'm not sure why they behave differently.

@Murderlon
Copy link
Member

Just so I understand, are you testing local uploads to your backend or remote uploads with Companion? You mention Companion but also "drag and drop from one window in your browser", which wouldn't use Companion.

Do you see this problem without your nginx setup?

@Kelketek
Copy link
Author

@Murderlon Remote uploads with companion. I meant to say 'from one tab to another'-- if I drag an image from one website to Uppy, it sends along the URL and Companion helps fetch it and upload it. This works in Chrome but not Firefox.

I haven't tried it without NginX. I'm not sure I'd get more clarity without NginX, since I'd have to set up a very different configuration that couldn't leverage using the same host/port combo, which I imagine would introduce more problems and significantly different config.

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

No branches or pull requests

2 participants