As an engineer, I want next-build to make use of VA's proxy to access internal API domains, so that I can work on my local machine with data from a shared instance.
As an engineer, I want next-build to properly use certs for internal servers, so that https works without issue.
Acceptance Criteria
[ ] next-build retrieves information from the shared Content Tugboat instance by default
[ ] When the environment requires it, next-build runs these requests through a proxy
[ ] When making requests to Tugboat instances, an appropriate cert is used such that requests are made without error.
The client class accepts fetcher as an argument. This can be anything that performs that function - node-fetch, axios, etc. Minimally, we should be able to wrap node-fetch in a function that adds a socks-capable HTTP agent to its requests:
// Currently called Unstable_DrupalClient
import { Unstable_DrupalClient } from 'next-drupal';
import nodeFetch from 'node-fetch';
import { SocksProxyAgent } from 'socks-proxy-agent';
// We construct a fetcher which basically just wraps 'normal' calls to fetch and adds an agent that is proxy-aware.
const fetch = async function fetch(url, options) {
const agent = new SocksProxyAgent('socks://127.0.0.1:2001');
console.log(agent);
options = {
//agent: agent,
...options
};
console.log(url);
return nodeFetch(url, options);
}
// Instantiate the next-drupal client with our custom fetcher.
const client = new Unstable_DrupalClient(process.env.NEXT_PUBLIC_DRUPAL_BASE_URL, {
fetcher: fetch,
});
Description
As an engineer, I want next-build to make use of VA's proxy to access internal API domains, so that I can work on my local machine with data from a shared instance.
As an engineer, I want next-build to properly use certs for internal servers, so that https works without issue.
Acceptance Criteria
Implementation
next-drupal has a branch in progress which collects all its API interaction methods into a single package,
client
. This work is currently available in a branch, and slated to be released as part of v1.3. https://github.com/chapter-three/next-drupal/blob/fix/fetch/packages/next-drupal/src/client.tsThe
client
class acceptsfetcher
as an argument. This can be anything that performs that function - node-fetch, axios, etc. Minimally, we should be able to wrap node-fetch in a function that adds a socks-capable HTTP agent to its requests:next-build should choose to use the proxy based on the endpoint domain and other environment cues. See similar logic currently in content-build: https://github.com/department-of-veterans-affairs/content-build/blob/master/src/site/stages/build/drupal/api.js#L61
A self-signed cert should be used when running through a proxy. See the cert and logic in content-build: https://github.com/department-of-veterans-affairs/content-build/blob/master/certs/README.md
CMS Team
Please check the team(s) that will do this work.
Sitewide program
Platform CMS Team
Sitewide crew
(leave Sitewide unchecked and check the specific team instead)⭐️ Content ops
⭐️ CMS experience
⭐️ Public websites
⭐️ Facilities
⭐️ User support