Keystone don't shows Sign In problem in production environment (Sign In works only for https)

[pahaz]

Bug report

Describe the bug

If I use yarn dev:

Then I use yarn build && yarn start with the same credentials:

To Reproduce

You can reproduce it with demo projects #2761 or with yarn create keystone-app my-app.

System information

• OS: macOS
• Browser: chrome

Additional context

Is the keystonejs ready for production? Do you have any production project based on the Keystonejs?

[jesstelford]

Hey @pahaz can you have a read through this and see if it helps solve your problem? Depending on your hosting provider, it might be enough to set the trust proxy value.

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

[pahaz]

@jesstelford I just try to run it locally without any proxy.

[pahaz]

Steps to reproduce:

git clone https://github.com/keystonejs/keystone
cp -r keystone/demo-projects/blog my-blog-app
cd my-blog-app
yarn
yarn build
yarn start

[3lijah]

My understanding from #2729 is that keystonejs can only be used if you have access direct access to the server software and its configuration.

[pahaz]

Ou. I understand my problem.

I added SSL cert for localhost by command openssl req -nodes -new -x509 -keyout server.key -out server.cert, and fix the keystone source:

keystone/packages/keystone/bin/utils.js

Lines 78 to 85 in 78193f9

	const { server } = await new Promise((resolve, reject) => {
	const server = app.listen(port, error => {
	if (error) {
	return reject(error);
	}
	return resolve({ server });
	});
	});

by this hack (just for test purposes 😁, don't do such staff in production):

  const { server } = await new Promise((resolve, reject) => {
    var https = require('https')
    var fs = require('fs')

    const server = https.createServer({
      key: fs.readFileSync('/Users/pahaz/Code/node-docker-compose-dev/keystone-blog/server.key'),
      cert: fs.readFileSync('/Users/pahaz/Code/node-docker-compose-dev/keystone-blog/server.cert')
    }, app)
        .listen(port, error => {
          if (error) {
            return reject(error);
          }
          return resolve({ server });
        })
  });

And after that, the Sign In form started working fine in https://localhost:3000/ .

In my opinion, it's quite counterintuitive. Keystone should write some warnings about such cases!

• I need some less source hackable way to fix the Keystone server instance (if it's a part of public details of realization)
• I need some warnings for such counterintuitive behavior

Thanks, @3lijah and @jesstelford !

[pahaz]

I think server customization like in next.js (https://nextjs.org/docs/advanced-features/custom-server) will be a good choice for such things.

[jesstelford]

Hmm, curious! I've never had sign-in problems when running locally on http.

We do have custom server options, and they were in fact inspired by Next.js! https://www.keystonejs.com/guides/custom-server

[MadeByMike]

Is there any further action required in this issue? @pahaz @jesstelford? We've spent a lot of time trying to discover all the issues documented in #2729

I think from here the best way forward is to start planning alternative authentication methods for the admin UI.

Closing this now and would welcome any new issues focused on features that improve sign-in\authentication.