This week, we’ve received several reports of people having problems with the email verification process. When they try to click the link in their verification email, they get the following error from ID Dashboard:
Error at Object.<anonymous> (/opt/id/node_modules/LDAP/LDAP.js:16:23) at Module._compile (module.js:449:26) at Object.Module._extensions..js (module.js:467:10) at Module.load (module.js:356:32) at Function.Module._load (module.js:312:12) at Module.require (module.js:362:17) at require (module.js:378:17) at Object.<anonymous> (/opt/id/app/ldap.js:16:18) at Module._compile (module.js:449:26) at Object.Module._extensions..js (module.js:467:10)
They can’t log in or reset their password after this, and the verification doesn’t work of course due to the above error.
A workaround that we’ve been using is:
Delete the “Locked” account in Formage
Recreate it via the normal ID Dashboard page, using the exact same names, email address, and a temporary password, and get an error message that the email address and username exists.
Check that the account now re-appears in Formage, but no longer “Locked”
Log in to Dashboard with the temporary password to verify
Instruct the user to use the password reset feature to reset their password and continue as normal.
This is stopping several people from successfully getting accounts, so we should try to figure out what’s wrong ASAP.
I can look into this but @plypy and @elliott know more and probably can solve it quicker than me – I’d have to look through the code…part of GSoC this year is fixing backend stuff – so this falls under GSoC – it will definitely be fixed but a short-term fix should be implemented ASAP…
Hi, @michael. It seems the problems are getting more and more annoying. If you don’t mind, I want to get the SSH access to our production server, so I can dive deeper into this problem and maybe solve it. Or the only thing I can do now is to guess randomly based on the very limited error log…
And also, I am very sorry to those who are disturbed, I’ll try to figure out why… Some part of the Dashboard seems to get rusty
Scrutinizing again to the backtrace, this error should be related with ldapadd procedure. It’s either the problem of OpenLDAP or somehow the code have sent more than one ldapadd request.
And based on your workaround and my guess to the current state of Dashboard in production, which should have no delete sync logic from Mongo to LDAP and could dynamic sync user from LDAP to Mongo. See, in your workaround,
User is deleted from Mongo, but remained still in LDAP
Sync is triggered from LDAP to Mongo
Sync in 2. doesn’t create locked flag
I’m examining the code as well. But really, the commit hash of current production server would be much helpful!!!
Thanks @elliott; I was tied up this weekend. @plypy in case you need access to production or have specific questions, probably best way to reliably get answers is through email to helpdesk@ or new case at https://help.openmrs.org/