Next.js: API route examples are bad/incorrect

[remy]

Examples bug report

Example name

• api-routes-graphql
• api-routes-rest
• api-* (affects all)

Describe the bug

All the examples use getInitialProps to request from localhost:3000 - which, when you've deployed to now (as per the readme) it blows up and throws a 500 (I just ran a test deploy and it does indeed break).

This issue isn't specific to Next.js but it is specific to the examples which suggest releasing.

To Reproduce

1. Deploy https://github.com/zeit/next.js/tree/canary/examples/api-routes-graphql/ to now
2. Visit url - 500

Expected behavior

A solution should be offered to handle fetching "self", or the suggestion of deploying to Zeit's now should be removed.

Additional context

Possible workaround that I'm currently using, but feels brittle:

const origin = req => {
  if (!req) {
    return '';
  }

  if (req.headers['x-now-deployment-url']) {
    return `https://${req.headers['x-now-deployment-url']}`;
  }

  return `http://${req.headers.host}`
}

Index.getInitialProps = async ({ req }) => {

  const url = origin(req) + '/api/graphql';
  fetch(url, { … });
  // snip

[Janpot]

To me it feels a bit unsafe to have your backend make requests to urls defined in headers. Wouldn't it be possible to spoof the host header?

[amytych]

Just bumped into this as well!

Possible workaround that I'm currently using, but feels brittle:

It seems that using the header is the way to go indeed. https://zeit.co/docs/v2/advanced/platform/changes-in-now-2-0/#environment-variables

To me it feels a bit unsafe to have your backend make requests to urls defined in headers. Wouldn't it be possible to spoof the host header?

It should be safe https://github.com/zeit/now-builders/issues/55#issuecomment-446422255

It will be added at the routing layer, so no chance of someone spoofing the value as we would just overwrite it when that happens.

[Janpot]

@amytych

It should be safe

It may be safe in ZEIT now specifically, but API routes are not restricted to this environment alone. People may copy this example and run it on their own infrastructure. Besides that, it would give the general impression that it's ok to treat the host header as "safe" input.

[amytych]

It may be safe in ZEIT now specifically, but API routes are not restricted to this environment alone. People may copy this example and run it on their own infrastructure. Besides that, it would give the general impression that it's ok to treat the host header as "safe" input.

Good point indeed 👍 I was caught up with the issue being about Now 2.0 deployments, I guess in other environments the case will always be different and out of scope of this issue?

[shidel-dev]

I'm also running into this. The provided examples do not work when developing locally, due to SSR pages not being able to make requests to the api endpoints. I get 404 errors.

[rwschmitz]

Hi,

I think I'm having a similar issue.

• I connect to my mongoDB that's hosted in the cloud via mongoDB Atlas.
• Any data fetching I do on localhost in /api/my-route-here works locally. I get the data back, and it's all good.
• I then deploy to Vercel, and no matter the combination of things I've tried, I routinely get 502 bad gateway with the exact same code.

I've done next build and next start locally to see if something is going on during the build process but this still works.

I thought maybe the "API resolved without returning data may result in stalled requests" was causing the issue, so I re-wrote my middleware but even after resolving that issue, I'm still getting 502 bad gateway when deploying.

[rwschmitz]

Hi,

I didn't whitelist any other domains except my own personal IP address. This is why everything worked locally, but not when I pushed it up to Vercel's servers and my custom domain.

In case anyone stumbles upon this comment and is trying to figure out why they're able to hit their DB (mongoDB atlas in the cloud) locally ... but not when you deploy ... make sure you whitelist other IPs than just your own.

[lfades]

Closing as api-routes-* examples have been updated to no longer use absolute URLs to do data fetching :relieved: