Keystone password 'authStrategy' login in AdminUI returns 404 in AWS with multi-containers when 'stickiness' disabled

[ra-external]

When one has more than one container in AWS and 'stickiness' is disabled, if authorization is enabled in KeystoneJS, when one goes to the AdminUI and tries to sign in one receives a 404 error.

Specifically, if one has set up the authStrategy like this

const createAuth = () => {
	authStrategy = keystone.createAuthStrategy({
		type: PasswordAuthStrategy,
		list: 'User',
		config: {
			identityField: 'username', // default: 'email'
			secretField: 'password' // default: 'password'
		}
	});
};

const authStrategy = createAuth();
module.exports = {
	keystone,
	apps: [
		new GraphQLApp(),
		new AdminUIApp({
			adminPath: '/admin',
			hooks: require.resolve('./admin/'),
			authStrategy,
			enableDefaultRoute: true
		}),
		new StaticApp({
			path: '/',
			src: 'public',
			fallback: 'index.html'
		})
	]
};

you cannot login, but instead you will see in the browser dev tools a 404 error for (in our case)

https://app.dev.yaa-dev.com/admin/js/main.d5742940bb72b1bce0e1.bundle.js

It was only when by random chance we stopped one of the two containers that was running in AWS that we solved the problem. We were able to run multiple containers if and only if we set the AWS 'stickiness' to true, which means that if a user first hits container A, all subsequent hits will be on that same container. Without 'stickiness', the user could first hit container A, then container B, etc. This seems to break the login.

Is there some kind of session info that's being maintained server-side, so that the AdminUI user always has to return to the same server instance?

(I am not a DevOp, nor do I know AWS -- but our AWS DevOp doesn't know Keystone, so I'm helping figure out what the issue may be).

Thanks for any help!

[jesstelford]

By default sessions are stored in memory (to make the local dev DX easier). In production mode, we emit a warning about this, but it's admittedly not very obvious.

You'll have gotten a valid session from one EC2 instance, then your load balancer would have attempted to serve the JS from another instance which doesn't know about that session so denies access with a 404.

To fix it, you'll want to set the sessionStore config option: https://www.keystonejs.com/guides/production/#session-store