-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cookies not set in the client v5 #2364
Comments
When saying "login process", are you referring to the Admin UI or your own frontend client? The Admin UI should set a For your own frontend, you'll need to look store the It's built this way to support the usecases of cookie-less environments (ie; querying from node) which will want direct access to the token that it can store in another method besides a cookie. |
Hey, I'm sorry for the poor explanation. What is happening is that I simply cannot login. When I check the dev tools (chrome) for the keystone.sid cookie it's not there, so I'm assuming it's related to that. This is happening in the AdminUI. Meanwhile, I've read other issues (#2042 ) and got the app to work by setting the secure cookies to false. Again I'm sorry for rushing a bug report. I should have read these issues first! |
How exactly is the token returned from |
I have the same problem in heroku that I can't log in. |
I haven't reproduced this personally but it sounds like the same issue people have with secure cookies when Keystone apps are deployed behind proxies (#1887). Basically, when Specifying TL;DR, you can to export a a You end up with something like... module.exports = {
keystone,
apps: [
new GraphQLApp(),
new AdminUIApp({ authStrategy, enableDefaultRoute: true }),
],
configureExpress: app => {
app.set('trust proxy', true);
},
}; In this scenario you can leave |
@molomby Brilliant! Your writeup should be linked in the docs. |
@molomby Thanks! Worked like a charm. It might be nice if this was part of the create-keystone app. It could ask you if you are using |
It looks like there hasn't been any activity here in over 6 months. Sorry about that! We've flagged this issue for special attention. It wil be manually reviewed by maintainers, not automatically closed. If you have any additional information please leave us a comment. It really helps! Thank you for you contribution. :) |
Just to note this is also true for AWS setups that include a Load Balancer proxying requests from HTTPS targeting HTTP EC2 instances. |
I'm having the same issue right now. The documentation needs to be updated (or created). I have separated AdminUI from the actual front end app. so I have set it as frontend.heroku.com and backend.heroku.com. const keystone = new Keystone({
adapter: new Adapter(adapterConfig),
secureCookies: true,
sessionStore: new MongoStore({ url: process.env.DATABASE }),
cookieSecret: process.env.COOKIESECRET,
// cookie: {
// secure: false,
// maxAge: 1000 * 60 * 60 * 24 * 30, // 30 days
// sameSite: false,
// },
}); module.exports = {
keystone,
apps: [
new GraphQLApp({
authStrategy: backendAuthStrategy,
}),
new AdminUIApp({
name: PROJECT_NAME,
authStrategy: backendAuthStrategy,
hooks: require.resolve("./admin/"),
}),
],
configureExpress: (app) => {
app.set("trust proxy", 1);
// app.use(cors({
// credentials: "include",
// origin:process.env.BACKEND_URL
// }))
},
}; This is the backend and the front end is pretty much the same as the meetup example. but on Heroku production cookie doesn't get created or doesn't stick to the session, so when I refresh I lose the AuthenticatedUser completely. Does anybody have an idea what might be the reason for this? Thanks in advance |
Keystone 5 has officially moved into active maintenance mode as we push towards the next major new version Keystone Next, you can find out more information about this transition here. In an effort to sustain the project going forward, we're cleaning up and closing old issues such as this one. If you feel this issue is still relevant for Keystone Next, please let us know. |
Bug report
Describe the bug
When using password auth strategy keystone is not setting the keystone.sid cookie in the client preventing the auth process to function properly (app deployed to Heroku).
I have another app (also deployed to Heroku) built with keystone v4 and it works fine.
To Reproduce
Expected behavior
It was expected that a cookie was set in the client app to enable the login process.
The text was updated successfully, but these errors were encountered: