Send custom headers when Remix is sending requests to server (calls loader)

[wooque]

Is there a way to set custom headers when Remix is sending requests to server, for example when it's calling loader?
I want to add header based authentication instead of cookies.

[sergiodxa]

There's no way, Remix simulates what the browser does and the browser will not let you send an extra header when doing a document request.

If you only send auth information using a header instead of cookie then when the user opens for the first time your app and the browser sends a document request then you will not be able to know who is the user forcing you to fetch all user-specific data client-side, at that point you have full control.

---

Additionally, I think you could use a Service Worker to intercept requests (even document requests) and send the Authorization header, but that's outside Remix.

[h3har]

What about fetcher? Fetcher is simulating XHR or Fetch API isn't it? They both allow custom headers.

Also with middleware being planned as a future feature, I feel like allowing this would make even more sense.

[sergiodxa]

Still not possible, there was a proposal to allow sending a HeadersInit value when using useSubmit or fetcher.submit since they work without JS, they already allows you to set encType to application/json so I think it should make sense to allow them to add extra headers, but Form and fetcher.Form shouldn't allow it to ensure it's still progressively enhanced.

Note that, any use-case you may need a header could be solved by sending the data in the body too, since you need to GET/POST a Remix route anyway, not an external API you may not have control of.

[h3har]

I wouldn't say any use case. A single request could be passing through more than just Remix. People on here have described use cases such as when their Remix server is wrapped in a proxy, etc.

Also, I think headers behave more nicely with middleware (really just any extra "layers" in the stack, whether proxies, middleware, web servers, etc.). They're less intrusive and don't require the middleware to parse the entire body just to extract a single value or values. They're also independent of content type. Also, IIRC just the act of sending custom headers can trigger special browser security behaviors.

It's nice to have control over these things, and if fetcher.submit() and fetcher.load() is emulating fetch/XHR, then it really should in my opinion. While we could use XHR or the Fetch API directly, it might require a lot more work, since Remix's fetcher does a lot more than just wrap a fetch() call (e.g., retries, aborting, routing, etc.). There are other aspects of fetcher that are limited too, like the lack of a cancel() method, which has use cases for large transfers/uploads/etc. - sometimes people want to cancel these things!

[Hansenq]

@sergiodxa, just had a conversation with Ryan on twitter about this, where he suggested monkey-patching fetch to add the header into all requests. I haven't yet tried it out, but will do so next week and report back. Any obvious issues with this approach to add custom headers into all of the requests remix sends to the server?

[sergiodxa]

On a document request it will not work, unless you register a Service Worker, and then you can do the same in the SW without monkey patching fetch.

[Hansenq]

It sounds like I can load the document first (without the header) and do auth separately, then monkey-patch fetch with a new auth token to pass it in the headers for future loader/action requests? Will need to go try it out but it seems this could work.

Don't really want to mess with service workers unless I need to :/

[sergiodxa]

At that point, I'm not sure why use Remix instead of just React Router, if your server-side render will not have other than public data at much or a skeleton, you could build a SPA directly.

With #7638 and #7634 it may be possible to use Remix to do this in the future, right now React Router gives you most of the benefits of Remix but client-side only.

[Hansenq]

Interesting idea...right now my entire app is Remix and I want to embed a portion of that, so it made sense for me think about it from the Remix perspective. But you're right, I could just make that specific route a client-side SPA using React Router, where I can customize auth how I want to. I'd lose the nice Remix structure (and have to switch between Remix-development and client-side development). Not sure I want to make that tradeoff just yet, but definitely a good idea; thanks!