Closed ScottMaxson closed 4 years ago
Gosh, I just went through this with GF Assess. The handler for the /login-link path, _loginLinkHandler()
, has a call to req.login()
, which should be logging in the user before it does the redirect to /profile.
I think you're seeing the problem I described back on November 20 in the Slack technical-discussion channel:
The problem is that the session store is getting created/updated asynchronously (nxus-storage WaterlineSessions is writing to the database), and the page handling proceeds without waiting for the update to complete.
It showed up in the password reset logic in GF Assess. Clicking on the link in the password reset email ended up at the login page, instead of the user profile edit page (intermittently, of course – it worked some of the time). It turned out there was a redirect() that got executed before the session data was saved (due to the bug above), so the session logic for the redirected page found no session context and redirected to the login page.
There may be a more general fix, but I just forced a
session.save()
...
In my case, I don't think there was a race condition; this issue went away for me when I sorted out some confounding issues with custom middleware in the app (ip3-assess) that exhibited this behavior.
Closing this issue, then.
The e-mailed forgotten password URL that uses '/login-link' path is routed by
users-login-routes
to '/profile', but the handler inusers-profile
redirects to the login page when user isn't logged in. This prevents resetting your password.