Keystone-next Admin UI refresh loop on nginx reverse proxy #4902
Comments
|
Here #1887 is similar problem for Keystone-v5, that can be solved (for me too) via adding: But I can't find the right place in Keystone-next for do the same thing. const server = express();
+ server.set('trust proxy', true);but this isn't help. |
|
new interface does not have config option to configure express server, I have added a PR to enable |
|
Seems the problem is not with function createApplication() {
// ...
app.set('trust proxy', true);
app.init();
app.set('trust proxy', true);
return app;
}Maybe anybody knows, what else can broke the Admin UI rendering process, using reverse proxy? If I start keystone-v5 instead of keystone-next on same place - it works, but keystone-next - not. |
|
I have found that the first GraphQL query: # Write your query or mutation here
{
keystone {
adminMeta {
lists {
key
isHidden
fields {
path
createView {
fieldMode
__typename
}
__typename
}
__typename
}
__typename
}
__typename
}
authenticatedItem {
... on User {
id
name
__typename
}
__typename
}
}fails with error: {
"errors": [
{
"message": "Access denied",
"locations": [
{
"line": 3,
"column": 5
}
],
"path": [
"keystone",
"adminMeta"
],
"extensions": {
"code": "INTERNAL_SERVER_ERROR",
"exception": {
"stacktrace": [
"Error: Access denied",
" at /srv/k.dev.brick.ru/domains/api.k.dev.brick.ru/packages/keystone/packages-next/admin-ui/system/dist/admin-ui.cjs.dev.js:534:19",
" at runMicrotasks (<anonymous>)",
" at processTicksAndRejections (internal/process/task_queues.js:93:5)"
]
}
},
"uid": "cklghegau000q8hxx61gg5jca",
"name": "GraphQLError"
}
],
"data": null
}This line in code: resolve(rootVal, args, context) {
if ('isAdminUIBuildProcess' in context || isAccessAllowed === undefined) {
return adminMetaRoot;
}
return Promise.resolve(isAccessAllowed(context)).then(isAllowed => {
if (isAllowed) {
return adminMetaRoot;
} // TODO: ughhhhhh, we really need to talk about errors.
// mostly unrelated to above: error or return null here(+ make field nullable)?s
throw new Error('Access denied');
});
} |
|
I have found the source of problem! It is in isAccessAllowed: async context => {
var _context$req, _keystoneConfig$ui2;
// Allow access to the adminMeta data from the /init path to correctly render that page
// even if the user isn't logged in (which should always be the case if they're seeing /init)
const headers = (_context$req = context.req) === null || _context$req === void 0 ? void 0 : _context$req.headers;
const url = headers !== null && headers !== void 0 && headers.referer ? new URL(headers.referer) : undefined;
const accessingInitPage = (url === null || url === void 0 ? void 0 : url.pathname) === '/init' && (url === null || url === void 0 ? void 0 : url.host) === (headers === null || headers === void 0 ? void 0 : headers.host) && (await context.sudo().lists[listKey].count({})) === 0;
return accessingInitPage || ((_keystoneConfig$ui2 = keystoneConfig.ui) !== null && _keystoneConfig$ui2 !== void 0 && _keystoneConfig$ui2.isAccessAllowed ? keystoneConfig.ui.isAccessAllowed(context) : context.session !== undefined);
}Here is failing part: (url === null || url === void 0 ? void 0 : url.host) === (headers === null || headers === void 0 ? void 0 : headers.host)If easier, it is do the comparison of hostname from http headers And when I do the query directly without nginx, the values are: But via nginx proxy: So my quick hacky solution is to force set right 'host' header via line like this: Is this right way, or we must tune up this comparison rule in Keystone-next to not require such unusual config of reverse proxy? Keystone-v5 works well without this "hack". |
|
I created the PR #4928 that should fix this problem. |
|
in case someone have this issue again, in Keystone 6, here is how i solved mine. in keystone.ts, i temporary replaced |
|
Hey there! Looking into same problem with Keystone6, do we have some working example how to make it work with Nginx? |
|
I was having this similar issue in my local dev environment and found Solutions:
For my case, it was the Looking at the login The "Secure;" statement above declares that the cookie can only be accepted if it was via https request. For production environment, it works fine. But for development environment, we need to use the above mentioned solutions to opt-out of using secure session. |
Bug report
When I start Keystone-next example projects, for example "examples-next/todo", all works well when I open the Admin UI in browser directly (using listening port,
http://example.com:3000/).But when I configure reverse proxy via nginx (
https://example.com/) - I got the infinite loop of page refresh:And in output of keystone-next console - repeating error:
To Reproduce
yarn dev).Full error output:
The text was updated successfully, but these errors were encountered: