I'm trying to setup a proxy to Contentful Delivery SDK to intercept the response and add relevant data. For development purposes, the proxy is still running locally. This is the configuration I'm using right now:
const client = createClient({
space: SPACE_ID,
accessToken: ACCESS_TOKEN,
host: CDN_URL,
environment: ENVIRONMENT,
basePath: 'api',
retryOnError: false,
proxy: {
host: 'localhost',
port: 8080,
auth: {
username: 'username',
password: 'password',
},
},
});
For some reason, this client keeps ignoring the proxy settings, making the request directly to Contentful CDN. I tried removing the host field from the configuration, but it didn't change the outcome. I also tried using the httpsAgent configuration with HttpsProxyAgent instead of the proxy one, but also didn't work.
Versions:
"contentful": "^7.11.3"
"react": "^16.13.1"
Firstly, the proxy configuration cannot be used client-side. It's unclear if that is your use case here.
There is a known bug here. Either try installing a newer version of Axios, which is the lib that the contentful SDK uses. Or use a proxyAgent:
const HttpProxyAgent = require("http-proxy-agent");
const httpAgent = new HttpProxyAgent({host: "proxyhost", port: "proxyport", auth: "username:password"})
Now just pass the agent into the create client method:
const client = createClient({
....
httpAgent: httpAgent,
....
});
Related
Have really been struggling with CORs lately, and finally got a combination that works. However based on all of the documentation I have read, it should NOT work.
From the "Configuring CORS" documentation on Apollo GraphQL:
Pass the credentials option e.g. credentials: 'same-origin' if your
backend server is the same domain, as shown below, or else
credentials: 'include' if your backend is a different domain.
Since my front end is on EC2 and Backend is on Lambda, they are on different origins no?
My stack:
Frontend: Apollo Client / NextJS (hosted on EC2) ex: http://mysite.io
Gateway: AWS API Gateway ex: https://XXXXXXXXX.execute-api.us-east-1.amazonaws.com/dev/graphql
Backend: Apollo Server GraphQL (hosted on Lambda)
Note: the below code works.
Frontend:
const link = createHttpLink({
uri: process.env.API_URL,
credentials: 'same-origin',
headers: {
'x-api-key': process.env.API_KEY
}
});
Gateway Settings:
Backend:
exports.handler = server.createHandler({
expressGetMiddlewareOptions: {
cors: {
origin: true,
credentials: true
}
},
});
But if I change my credential value to 'include' on the apollo client (front end)...
We run into the following preflight error:
Response to preflight request doesn't pass access control check: The
value of the 'Access-Control-Allow-Origin' header in the response must
not be the wildcard '*' when the request's credentials mode is
'include'.
I have built a Svelte application using SvelteKit that uses Cognito for authentication. I used the following site: Cognito authentication for your SvelteKit app guide me in setting this up. The app and connection to Cognito works well when running in local development via npm run dev, however, when running in production on an EC2 server via npm run build and pm2 start /build/index.js it sets the redirect_uri portion of the Cognito URI to http://localhost:3000. I can't figure out how to get it to set the redirect to my actual domain.
Here are some relevant code snippets on how it is currently set up on EC2:
/etc/nginx/sites-available/domain.conf
server {
server_name example.com;
location / {
root /var/www/html/build;
proxy_pass http://localhost:3000;
}
listen [::]:443 ssl ipv6only=on;
listen 443 ssl;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
include /etc/letsencrypt/options-ssl-nginx.conf;
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
}
svelte.config.js
import node from '#sveltejs/adapter-node';
/** #type {import('#sveltejs/kit').Config} */
const config = {
kit: {
target: '#svelte',
adapter: node({
out: 'build',
precompress: false,
env: {
host: 'example.com',
port: '443'
}
})
}
};
export default config;
/src/lib/auth.js
import { SvelteKitAuth, Providers } from 'sk-auth';
const DOMAIN = 'myapi.auth.us-east-1.amazoncognito.com';
const config = {
accessTokenUrl: `https://${DOMAIN}/oauth2/token`,
profileUrl: `https://${DOMAIN}/oauth2/userInfo`,
authorizationUrl: `https://${DOMAIN}/oauth2/authorize`,
redirect: 'https://example.com',
clientId: myAWSclientID,
clientSecret: myAWSclientSecret,
scope: ['openid', 'email'],
id: 'cognito',
contentType: 'application/x-www-form-urlencoded'
};
const oauthProvider = new Providers.OAuth2Provider(config);
export const appAuth = new SvelteKitAuth({
providers: [oauthProvider]
});
Expected URL when going to Cognito
https://myapi.auth.us-east-1.amazoncognito.com/login?state=cmVkaXJlY3Q9Lw%3D%3D&nonce=699&response_type=code&client_id=myAWSclientID&scope=openid+email&redirect_uri=https%3A%2F%2Fexample.com%2Fapi%2Fauth%2Fcallback%2Fcognito%2F
Actual URL when going to Cognito
https://myapi.auth.us-east-1.amazoncognito.com/login?state=cmVkaXJlY3Q9Lw%3D%3D&nonce=699&response_type=code&client_id=myAWSclientID&scope=openid+email&redirect_uri=http%3A%2F%2Flocalhost%3A3000%2Fapi%2Fauth%2Fcallback%2Fcognito%2F
As you can see, it is attempting to set the redirect_uri to http://localhost:3000 instead of the expected https://example.com. I'm pretty sure that there is some setting somewhere to allow it to set the correct redirect_uri when going to Cognito - any ideas or suggestions would be appreciated!
From what I can tell looking at the sk-auth module source code, redirect_uri doesn't appear to be a valid config option. Try setting the host config option in the global SkAuth constructor instead:
const config = {
accessTokenUrl: `https://${DOMAIN}/oauth2/token`,
profileUrl: `https://${DOMAIN}/oauth2/userInfo`,
authorizationUrl: `https://${DOMAIN}/oauth2/authorize`,
// redirect_uri: 'https://example.com',
clientId: myAWSclientID,
clientSecret: myAWSclientSecret,
scope: ['openid', 'email'],
id: 'cognito',
contentType: 'application/x-www-form-urlencoded'
};
.
.
export const appAuth = new SvelteKitAuth({
providers: [oauthProvider],
host: 'https://example.com',
});
After further browsing the source, you can also set the redirect option provided by the AuthCallbacks interface on the provider configuration:
const config = {
accessTokenUrl: `https://${DOMAIN}/oauth2/token`,
profileUrl: `https://${DOMAIN}/oauth2/userInfo`,
authorizationUrl: `https://${DOMAIN}/oauth2/authorize`,
// redirect_uri: 'https://example.com',
redirect: 'https://example.com',
clientId: myAWSclientID,
clientSecret: myAWSclientSecret,
scope: ['openid', 'email'],
id: 'cognito',
contentType: 'application/x-www-form-urlencoded'
};
which, incidentally, is what the author uses in the tutorial you referred to.
Apollo Server 2.0 ships with built-in server as described here. That means no Express integration is required when setting it up, so the implementation looks something like this:
const { ApolloServer, gql } = require('apollo-server');
// Construct a schema, using GraphQL schema language
const typeDefs = gql`
type Query {
announcement: String
}
`;
// Provide resolver functions for your schema fields
const resolvers = {
Query: {
announcement: () =>
`Say hello to the new Apollo Server! A production ready GraphQL server with an incredible getting started experience.`
}
};
const server = new ApolloServer({ typeDefs, resolvers });
server.listen().then(({ url }) => {
console.log(`🚀 Server ready at ${url}`);
});
I'm implementing subscriptions to my app. How do I make the app use secured WebSocket protocol with subscriptions? Is it possible at all using the built-in server?
By default the server does not use WSS:
server.listen({ port: PORT }).then(({ url, subscriptionsUrl }) => console.log(url, subscriptionsUrl));
spits out http://localhost:4000/ and ws://localhost:4000/graphql.
In development I got my app to work fine but when I deployed to production I started getting these errors in console:
Mixed Content: The page at 'https://example.com/' was loaded over HTTPS,
but attempted to connect to the insecure WebSocket endpoint
'ws://example.com/graphql'. This request has been blocked; this
endpoint must be available over WSS.
and
Uncaught DOMException: Failed to construct 'WebSocket': An insecure
WebSocket connection may not be initiated from a page loaded over HTTPS.
Solved. Apparently configuring the WebSocket URL to start with wss:// instead of ws:// was enough.
i am having a https create-react-app application(https://xyz.site.com), i am proxing a server which is a different domain, when i am loading the application the api is giving the web html data as a response, there is no hit happened in the server,
i have tried using HTTPS=true in .env file, still i am not able to get the server response
setupProxy.js
module.exports = (app) => {
app.use(
'/api',
createProxyMiddleware({
target: process.env.REACT_APP_API_URL, // https://xxx-alb-23333.us-west-2.elb.amazonaws.com
changeOrigin: true,
}),
);
};
I have frontend client running on custom Next.js server that is fetching data with apollo client.
My backend is graphql-yoga with prisma utilizing express-session.
I have problem with picking correct CORS settings for my client and backend so cookie would be properly set in the browser, especially on heroku.
Currently I am sending graphql request from client with apollo-client having option
credentials: "include" but also have tried "same-origin" with no better result.
I can see cookie client in response from my backend in Set-Cookie header, and in devTools/application/cookies. But this cookie is transparent to browser and is lost on refresh.
With this said I also tried to implement some afterware to apollo client as apolloLink that would intercept cookie from response.headers but it is empty.
So far now I'm thinking about pursuing those two paths of resolving the issue.
(I'm only implementing CORS because browser prevents fetching data without it.)
CLIENT
ApolloClient config for client-side:
const httpLink = new HttpLink({
credentials: "include",
uri: BACKEND_ENDPOINT,
});
Client CORS usage and config:
app
.prepare()
.then(() => {
const server = express()
.use(cors(corsOptions))
.options("*", cors(corsOptions))
.set("trust proxy", 1);
...here goes rest of implementation
const corsOptions = {
origin: [process.env.BACKEND_ENDPOINT, process.env.HEROKU_CORS_URL],
credentials: true,
allowedHeaders: ["Content-Type", "Authorization", "X-Requested-With", "X-Forwarded-Proto", "Cookie", "Set-Cookie", '*'],
methods: "GET,POST",
optionsSuccessStatus: 200
};
My atempt to get headers from response in apolloClient(but headers are empty and data is not fetched afterwards):
const middlewareLink = new ApolloLink((operation, forward) => {
return forward(operation).map(response => {
const context = operation.getContext();
const {response: {headers}} = context;
if (headers) {
const cookie = response.headers.get("set-cookie");
if (cookie) {
//set cookie here
}
}
return response;
});
});
BACKEND
CORS implementaion (remeber that is gql-yoga so I need first to expose express from it)
server.express
.use(cors(corsOptions))
.options("*", cors())
.set("trust proxy", 1);
...here goes rest of implementation
const corsOptions = {
origin: [process.env.CLIENT_URL_DEV, process.env.CLIENT_URL_PROD, process.env.HEROKU_CORS_URL],
credentials: true,
allowedHeaders: ["Content-Type", "Authorization", "X-Requested-With", "X-Forwarded-Proto", "Cookie", "Set-Cookie"],
exposedHeaders: ["Content-Type", "Authorization", "X-Requested-With", "X-Forwarded-Proto", "Cookie", "Set-Cookie"],
methods: "GET,HEAD,PUT,PATCH,POST,OPTIONS",
optionsSuccessStatus: 200
};
Session settings, store is connect-redis
server.express
.use(
session({
store: store,
genid: () => uuidv4(v4options),
name: process.env.SESSION_NAME,
secret: process.env.SESSION_SECRET,
resave: true,
rolling: true,
saveUninitialized: false,
sameSite: false,
proxy: STAGE,
unset: "destroy",
cookie: {
httpOnly: true,
path: "/",
secure: STAGE,
maxAge: STAGE ? TTL_PROD : TTL_DEV
}
})
)
I am expecting session cookie to be set on the client after authentication.
Actual result:
Cookie is visible only in Set-Cookie response header but is transparent to browser and not persistent nor set (lost on refresh or page change). Funny enough I can still make authenticated requests for data.
This may not be a CORS issue, it looks like a third-party cookie problem.
Behaviour could be different across browsers so I recommend testing several ones. Firefox (as of version 77) seems to be less restrictive. In Chrome (as of version 83) there is an indicator on the far right of the URL bar when a third party cookie has been blocked. You can confirm whether third party cookies is the cause of the problem by creating an exception for the current website.
Assuming your current setup is as follows:
frontend.com
backend.herokuapp.com
Using a custom domain for your backend that is a subdomain of your frontend would solve your problem:
frontend.com
api.frontend.com
The following setup wouldn't work because herokuapp.com is included in the Mozilla Foundation’s Public Suffix List:
frontend.herokuapp.com
backend.herokuapp.com
More details on Heroku.