Keystone: Stuck on /admin/signin

Created on 6 May 2020 · 5Comments · Source: keystonejs/keystone

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

At signin UI, submit valid username and password
Observe a 200 success response, but no error message in the console or on-screen.
Page is refreshed, unable to access any other path than: http://localhost:3000/admin/signin
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/[email protected]
@keystonejs/[email protected]
@keystonejs/[email protected]
@keystonejs/[email protected]
@keystonejs/[email protected]
@keystonejs/[email protected]

Source

llakewood

Most helpful comment

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/[email protected] 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.

molomby on 7 May 2020

👍3

All 5 comments

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

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

Vultraz on 6 May 2020

🎉1 👍1

I think you have not configured root index.js file well. This could be misconfigured issue.

apps: [
    new GraphQLApp(),
    new AdminUIApp({
        adminPath: AppConfig.adminPath,
        authStrategy,
        isAccessAllowed: auth => (Boolean(true)),
    }),
    new NextApp({ dir: 'app' }),
]

Try to use isAccessAllowed: auth => (Boolean(true)), in your AdminUIApp, or define access-control method for isAccessAllowed by yourself.

chtonal on 6 May 2020

isAccessAllowed already defaults to () => true if not provided.

Vultraz on 7 May 2020

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

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

molomby on 7 May 2020

👍3

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

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

I had the same problem when trying to run it behind nginx for production. And this successfully solved it for me.