Support HTTP(s) agent - use remix-run/web-std-io package for fetch API

[cliffordfajardo]

I've been using Remix Auth outside of work just fine, however I ran into a challenge when using it at work when deploying to production.

Scenario

At work, our servers can't make requests to the external internet unless they go through a proxy (ex: company.proxy.com).
That is to say, when I try to authenticate with my oauth service provider, it fails because the request didn't come from company.proxy.com.

Other paths considered

• I tried @mswjs/interceptors package, but it doesn't support reading or sending formData at this time (reference)
• Another option not using remix-auth at all and implementing authentication in the express server code, if you're on the express template. The downside is you lose out on the nice remix-auth API's that you can use in your loader's.

Proposition

Adopt usage of remix-run/web-std-io which is the Remix's team's server implementation of the fetch API (basically it's equivalent to node-fetch & undici (in node v18+ runtimes).

What would adoption of Request from remix-run/web-std-io look like?

Use fetch, Request, Response from @remix-run/web-fetch directly for server-side files only in remix-auth.

import fetch, {fetch, Request} from '@remix-run/web-fetch';

Folks using remix-auth could then pass down agent and the other options from RequestExtraOptions

const proxyAgent = new HttpsProxyAgent('http://46.250.171.31:8080');

const options: = {
   agent: proxyAgent
}

let microsoftStrategy = new MicrosoftStrategy(
  {
    clientId: "YOUR_CLIENT_ID",
    clientSecret: "YOUR_CLIENT_SECRET",
    redirectUri: "https://example.com/auth/microsoft/callback",
    tenantId: "YOUR_TENANT_ID", // optional - necessary for organization without multitenant (see below)
    scope: "openid profile email", // optional
    prompt: "login", // optional
  },
    async ({ accessToken, extraParams, profile }) => {
    return User.findOrCreate({ email: profile.emails[0].value });
  },
  {requestExtraOptions here} // ❓❓❓

The main difference between the fetch API that exists in the browser and the one Remix uses is that it supports additional options which only matter or can exist in server runtimes (Ex: passing an HTTP(s) agent only makes sense on server)

• remix-run/web-std-io's Request class
• lib.dom.d.ts browser's fetch typings

Open Questions

If this were to happen, the next thing to think about is where to best expose the options object that the user could pass down that.
I'm not sure where the best place would be since, i'm not familiar with entire scope of remix-auth
The end goal would allow a user to pass down RequestExtraOptions from a strategy package and have it ultimately go down to remix-auth

• remix-auth recieves RequestExtraOptions from remix-oauth2
• ↑ remix-oauth2 receives RequestExtraOptions options and passes them to remix-auth
• ↑ pass RequestExtraOptions into remix-auth-{microsoft, supabase .. etc}

Previous Work

The node-fetch & node 18 fetch API mirrors the browser's fetch API except it also allows you to pass options which are relevant and only useful on the server. You can pass things like HTTP(s) agents like so:

const  http = require('http');
const proxyAgent = new HttpsProxyAgent('http://46.250.171.31:8080');

@typedef {Object} RequestInit  & RequestExtraOptions (from remix-run/web-std-io)
const requestOptions: = {
   agent: proxyAgent
}

// Now are requests will be proxied through another server
fetch(url, { agent })
new Request(url, {agent})

Related

• Expose agent property of node-fetch remix-run/remix#3530
• node 18 fetch API based on Undici (supports agent)
• @remix-run/web-std-io
  • fetch API
  • Request class API

[cliffordfajardo]

Discord Conversation:

Sergio

the package use the global fetch, whatever is there, this ensure it will work doesn't matter the environment
I'm not sure if web-std-io is used on every JS runtime

Clifford

ahh - this suggestion probably won't work then because web-std-io references the http and https modules and not all runtimes use those modules

Sergio

I suppose it's for Node.js only but Remix Auth needs to support Cloudflare and Deno (and Bun when it become officially supported by Remix)

Clifford

maybe a future consideration would be to introduce tiny runtime specific packages
I noticed cloudflare does the same thing as node-fetch & remix-run/web-std-io where they have the standard RequestInit type and then extend it with extra stuff . For example:

# un
# remix-run/web-std-io (https://github.com/remix-run/web-std-io/blob/main/packages/fetch/src/request.js)
RequestInit & RequestExtraOptions <-- nodejs specific

# cloudflare (https://developers.cloudflare.com/workers/examples/modify-request-property/)
RequestInit & RequestInitCfProperties <-- cloudflare specific

Sergio

remix-auth itself doesn't do any fetch actually -- strategies do the fetch
so a strategy could decide to support CF or Node specific extra options
most strategies, and specially strategies that does a fetch, extend OAuth2Strategy though , but I'm not sure what extra things from the request could be needed by the strategy because RequestInitCfProperties is something the loader/action request can receive
but from that request object the strategy only reads the body and url

Sergio

maybe, a solution could be to extend the MicrosoftStrategy you're using and overwrite the methods doing a fetch
that is userProfile and fetchAccessToken
since fetchAccessToken is private, you would have to overwrite authenticate, you can copy the code here https://github.com/sergiodxa/remix-auth-oauth2/blob/8fe9aba27735979ea3c3aeb14a27f659a56fd63c/src/index.ts#L135-L220 and replace this line https://github.com/sergiodxa/remix-auth-oauth2/blob/8fe9aba27735979ea3c3aeb14a27f659a56fd63c/src/index.ts#L197 with your own method