Stuck on /admin/signin

Bug report

Describe the bug

Stuck on /admin/signin

To Reproduce

This may be a non-issue, I found running npm start is when this is produced, but it behaves normalled with Keystone is run with npm run dev

1. At signin UI, submit valid username and password
2. Observe a 200 success response, but no error message in the console or on-screen.
3. Page is refreshed, unable to access any other path than: http://localhost:3000/admin/signin
4. Enter a bad credential and get notice that the username or password are incorrect (indicates that the service is working)

Expected behaviour

If the correct credentials are entered, I expect to be directed to the Admin UI dashboard.

System information

There are different responses offered by Firefox and Chrome:

• OS: macOS
• Browser: Chrome and Firefox

Additional context

I went away for a week and hadn’t updated anything. Now I have updated from 8.0.0 to 8.1.4. Same outcome.

node v12.11.0 npm 6.11.3

• @keystonejs/app-graphql@5.1.6
• @keystonejs/adapter-mongoose@8.0.2
• @keystonejs/file-adapters@6.0.2
• @keystonejs/fields@9.0.5
• @keystonejs/keystone@8.1.4
• @keystonejs/app-admin-ui@5.12.0

[molomby]

Yeah this sounds a lot like the secure cookie problem. It’s “by design” in the sense that it’s trying to be secure by default but gives no warnings and doesn’t really surface whats going on. This catches a lot of devs out.

It plays out like this:

• The start command is intended to be used in a production environment. As such, in the demo projects, it sets the NODE_ENV environment var to production.
• When NODE_ENV === 'production' Keystone enables secure cookies by default. This is the by design/secure by default bit.
• Since secure cookies are enabled, express won’t return them to the browser unless the request is over HTTPS (which generally isn’t the case in dev).
• There’s nothing in Keystone to detect/warn that this is happening so devs just get this quite confusing behaviour – signin requests with valid creds come in but no cookie is set so the user bounces back to the sign in screen.

Right now the simplest workaround is probably to add a new environment var to your app to specifically control the secureCookies Keystone config. Something like…

const keystone = new Keystone({
  name: 'Save Walter White',
  adapter: new KnexAdapter(adapterConfig),
  secureCookies: process.env.INSECURE_COOKIES ? false : undefined,
});

Then, if you want to start the site in “production” mode, you can run…

INSECURE_COOKIES=true yarn start

Note the var is in the negative here (INSECURE_COOKIES not SECURE_COOKIES) because env vars like this come though as Strings. This makes passing a negative value difficult, eg. SECURE_COOKIES=false comes though as the String 'false' which is true. Thanks JavaScript.

IMPORTANT NOTE – The above code works on the current @keystonejs/keystone@8.1.4 release of Keystone but will not work on the current master branch or future version due to breaking changes to the cookie config option. For future releases, the code would be…

const keystone = new Keystone({
  name: 'Save Walter White',
  adapter: new KnexAdapter(adapterConfig),
  // Note slight change here:
  cookie: { secure: process.env.INSECURE_COOKIES ? false : undefined },
});

As @Vultraz mentioned, a related issue rears its head in production if you have a reverse proxy. It’s not difficult to fix (a few lines of config) but has be very difficult to troubleshoot for a lot of people. We’re still working on smoothing off some of these sharp edges.

[Vultraz]

This sounds like the issue with secure cookies: https://www.keystonejs.com/keystonejs/keystone/#secure

Relevant writeup: https://gist.github.com/molomby/6fa22c165e0025f0f83d55195f3c6e37