2

If a user signs up & login with a 1-time login link (Since the site is configured to moderate users), and if they don't set their password and navigate away, they can no longer come back and set a password as Drupal will now require their "current" password (which obviously does not exist).

Is there any way around this? Not have Drupal ask for a "Current password" when none is set, perhaps?

1

Not requiring the current password seems like a huge security problem. Anyone who turns their back to the computer for a moment can have their password changed without their knowledge.

A user that finds oneself in this situation will need to request a new one time login link.

I would also suggest the box where a new password is entered should be better highlighed if this is a common problem.

  • 1
    Actually, the problem is simplified here--What happens is that I have the GMaps + Location module add Geodata to the user account, and when the Location module makes an AJAX call, it submits the form (is this expected behaviour with Drupal AJAX, or a bug with the Location module?). This ends up submitting the current page with an empty password and when the user submits the changes using the Submit button, Drupal will say that their current password is not valid, etc. This is why I would like to have Drupal not ask for "Current Password" when none exists currently. – Peter Jan 28 '12 at 19:15
  • @TahitiPetey, I'd call that a bug in one of those modules, and not Drupal. You might search the issue queues for them and maybe file an issue if you can't find a similar one. – paul-m Jan 28 '12 at 19:44
  • @paul-m, I think I sort of understand what's happening. When the Country is changed, the Province field needs to change, so the AJAX callback rebuilds the form. I'm not too familiar with how Drupal's AJAX mechanism work, but I guess in order to change a different field from the one that's being interacted with, Drupal needs to rebuild the form? Is this right? Still don't quite get why it needs to submit the form... Hmm – Peter Jan 28 '12 at 19:59
1

I side stepped this issue by tracking the last change time of the user's password in a new db table, and then checking to see if a time stamp exists for their last change. If not, then ignore the Current Password field validation (don't even bother checking), and thus the user can change their password without running into that issue.

Probably not the most 'secure' way to go about it, strictly speaking. But this is technically the same behaviour Drupal exhibits by default if a user uses a 1-time login link. If they decide to walk out right then and there to grab a coffee with their computer wide open in a public space, then hey, no amount of server-side security is going to protect them from their own stupidity.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.