Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make preview mode's "sameSite" and "secure" cookie properties configurable #14019

Closed
flohil opened this issue Jun 10, 2020 · 1 comment
Closed

Comments

@flohil
Copy link

flohil commented Jun 10, 2020

Feature request

Is your feature request related to a problem? Please describe.

Preview mode was not working for me running next locally. After a couple of hours I finally figured out that preview mode will only work for next running on "http://" if NODE_ENV is set to "development". The root of the problem is that the "secure" property of the preview mode cookies will be set to true if NODE_ENV !== 'development' and therefore require an "https://" connection. The code which sets the "sameSite" and "secure" cookie properties for the preview mode cookies depending on wether NODE_ENV !== 'development' can be found in "next-server/server/api-utils":

image

Describe the solution you'd like

I think allowing us to configure the "sameSite" and "secure" cookie properties of preview mode (e.g. as options of next's initialize function, like the "dev" option to run next in dev mode) would allow for a more flexible use of preview mode, e.g. one might want to run next on "http://" in a "test" environment - but at the moment, this is not possible because NODE_ENV !== 'development' only works for "https://" in preview mode.

Also, the fact that in order for preview mode to work on "http://" requires us to set NODE_ENV to "development" should be mentioned somewhere in the preview mode docs section.

Additional context

I am using a custom "server.js" file to start next:

const express = require('express')
const next = require('next')

const port = process.env.PORT || 3000
const app = next({ dev: process.env.DEV_MODE === 'true' })
const handle = app.getRequestHandler()

;(async () => {
  await app.prepare()
  const server = express()

  server.get('*', (req, res) => handle(req, res))

  await server.listen(port)
  console.log(`> Ready on http://localhost:${port}`) // eslint-disable-line no-console
})()

And I am using next-env to load environment variables from different .env files (since I found no automatic way to load environment variables for a staging environment). This is the relevant part of my package.json file:

image

(I added the NODE_ENV=development part to the dev script as a temporary solution)

@flohil
Copy link
Author

flohil commented Jun 11, 2020

@Timer I've got a question regarding #14022:

Will implementing #14022 mean that I will no longer be able to run next start or in my case yarn start with NODE_ENV set to "development"?

The reason I am currently doing this is because next only catches TypeScript compilation errors if I open the page that contains the errors. That's why I run yarn build to catch all TypeScript compilation errors on all pages and run yarn start or next start with NODE_ENV set to "development" in order to test preview mode for SSG in a local environment on "http://localhost:3000".

A little bit of context: I am creating FAQ entries using Strapi CMS and I display the FAQs on a landing page. I'd like to render the landing page at build time using SSG. Now if a content editor edits an FAQ entry or adds a new one, I would have to rebuild the application to view the FAQ changes on the landing page. Preview mode solves this problem by switching to SSR. However, in order to test that this actually works, I'd like to be able to run preview mode on "http://" in my local development environment using yarn build and yarn start, because for yarn dev, SSG behaves like SSR and rerenders the page on every request.

Edit:
I just skipped through the code of #14033 and saw that #14022 only outputs a warning and does not result in an error. This is great! I was just being worried that I could loose the ability to run next in production mode on a local development environment for the purpose of testing SSG, but I'm sure this is an exceptional use case and that the warning will spare many people quite some trouble :-)

@vercel vercel locked and limited conversation to collaborators Apr 12, 2021

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants