Password reset doesn't seem to work


I am having trouble with the “forgot password” reset function. Although the email with reset password link is sent and the message appears that the password has been successfully changed, the new password never works to sign in. I am able to change passwords from the global administrator account, but obviously want users to be able to change their own passwords as needed. I have made a small modification to the LoginController.php so that login forms redirect to the site instead of the admin panel. I’ve hardcoded the site slug (“archive”) in a few places to replace:

return $this->redirect()->toRoute(‘admin’);


return $this->redirect()->toRoute(‘site’, array(
‘site-slug’ => ‘archive’

Those are the only changes I’ve made in the LoginController (and if there’s a better way to do this please let me know). Is it possible these changes are affecting the forgot/reset password process, or is there any known issue or resolution?

Additionally, is there any way to resend the user activation/password reset email to multiple users from the admin panel (signed in as global administrator) without deleting and recreating users?

Thank you very much for your time.

Sorry - I’m using Omeka S 2.1.0. I have some modules activated: Collecting; Comment; CSS Editor; CSV Import; Custom Ontology; Custom Vocab; Derivative Images; Easy Install; File Sideload; Guest; Log; Metadata Browse; and Restricted Sites.

I suspect Guest may not play well with Restricted Sites right now. While Guest is installed and activated, I’m not using it at the moment.

So, the email actually sends, and users can reach the reset form, but the password doesn’t actually work?

I don’t think anybody has reported such a problem, and it’s not something I can reproduce. Certainly changes to the LoginController could cause problems, though the specific redirect change you mention probably shouldn’t. Do users see the “Successfully created your password. Please log in.” message once they’ve submitted the reset form?

My advice, if you’re concerned that modules may be causing a problem, would be to disable the modules in question to see if that affects your issue.

John, I’ve fiddled with this a bit more and it was definitely my changes to the LoginController causing the problems. Can you tell me what is a better way to have the login form redirect to the site instead of the admin panel? Or, have the create password form redirect on submission to the sitelogin/[site-slug] login form provided by the RestrictedSites module? I made these changes initially so that when users created their passwords, they wouldn’t be redirected to the admin panel. It worked then, as far as I can tell, but maybe it broke at the last upgrade.

If you could share what the exact changes you made were, maybe we can see what the problem was.

I’m not 100% sure of the use case for your redirection here: are you trying to block these users from the admin, or just direct them to the restricted site. I don’t have much (any) experience with the RestrictedSites module.

Ah thank you so much. I am trying to completely block the users from ever encountering the admin site. I’m using RestrictedSites so they can log in directly on the site. (They leave comments from their user accounts and then the admin user implements changes.) I believe the issue I’m running in to stems from RestrictedSites not addressing the reset password function. So if a user clicks “Forgot password” and gets the password reset email, the link in that email goes to the password reset form, which redirects to the standard login form, which drops them into the admin dashboard. What I’d like is for them to be redirected to the site-specific login form (from RestrictedSites) after resetting their password. This lives at /sitelogin/site-slug and I don’t know how to formulate that route from the login form on the admin side of things.

However, it would accomplish the same thing for them to be redirected to the site since RestrictedSites will render the login form if they’re not signed in and land on the welcome page. That’s what I tried to do by redirecting to the site, and I had to hard code the site slug because I don’t know how to select it otherwise. I changed the redirect in the loginAction function so it redirects to the site, with slug “archive”, instead of the admin panel, like this:

public function loginAction()
	// Modified to redirect to site instead of admin panel.
    if ($this->auth->hasIdentity()) {
        return $this->redirect()->toRoute(‘site’, array(
    ‘site-slug’ => ‘archive’

    $form = $this->getForm(LoginForm::class);

    if ($this->getRequest()->isPost()) {
        $data = $this->getRequest()->getPost();
        if ($form->isValid()) {
            $sessionManager = Container::getDefaultManager();
            $validatedData = $form->getData();
            $adapter = $this->auth->getAdapter();
            $result = $this->auth->authenticate();
            if ($result->isValid()) {
               // Next line was commented out.
			    $this->messenger()->addSuccess('Successfully logged in'); // @translate
                $eventManager = $this->getEventManager();
                $eventManager->trigger('user.login', $this->auth->getIdentity());
                $session = $sessionManager->getStorage();
                if ($redirectUrl = $session->offsetGet('redirect_url')) {
                    return $this->redirect()->toUrl($redirectUrl);
                // Modified to redirect to site instead of admin panel.
				return $this->redirect()->toRoute(‘site’, array(
                ‘site-slug’ => ‘archive’
            } else {
                $this->messenger()->addError('Email or password is invalid'); // @translate
        } else {

    $view = new ViewModel;
    $view->setVariable('form', $form);
    return $view;

This all seemed to be working fine until I realized it’s breaking the password reset function. I’m not sure if the problem arose due to the last upgrade but it seems that way.

Hello @Leah

I was having a look to check if RestrictedSites was not messing with you here, but I was able to correctly change passwords even with the loginAction modification you showed us, with Omeka-S v2.1.1.

Did you modify other actions in this LoginController? The passwordCreateAction could be the one to have a look.

BTW I was interested in your use case, but lacked some time to do anything since then. I’m somehow stuck at home for a couple of weeks, so I’ll have a new look at this in the coming days.

Have a nice day


You’re absolutely right, I had left in an experimental change in the passwordCreateAction made while fumbling around. Now it works. Thank you! If you want to talk more about the use case for a possible addition to RestrictedSites I’m certainly happy to explain as much as I can.

This topic was automatically closed 250 days after the last reply. New replies are no longer allowed.