How to reset your password + how to enable the 'forgot password' function

[ryan]

By default, the "Forgot Password" module is not turned on in v2.1. My thought was that lack of such a function is technically more secure (on any site or CMS). Why? Because having such a function active means your password is only as secure as your email (*though see note at end of this message). So I thought we'd start things out as secure as possible and let people adjust it according to their own need. But I'm rethinking that decision, and may change it to be 'on' by default.

If you don't already have that "Forgot Password" module installed, it is relatively easy to reset your password with the API. Lets say that you lost the password for your account named 'admin' and you wanted to reset it. Paste this code into any one of your templates (like /site/templates/home.php in the default profile, for example):

<?php
$admin = $users->get('admin');
$admin->setOutputFormatting(false);
$admin->pass = 'yo12345'; // put in your new password
$admin->save();

…or if it's easier for you to copy/paste everything on one line, here's the same thing as above on one line:

<?php $users->get("admin")->setOutputFormatting(false)->set('pass', 'yo12345')->save();

Replace "yo12345" with the new password you want and save the template. Then view a page using that template (like the homepage, in our example). The password for that account has now been reset, and now you are ready to login.

Don't forgot to now remove that snippet of code from the template! Otherwise your password will get reset every time the page is viewed.

Once logged in, here's how to install the Forgot Password capability:

1. Click to the "Modules" tab.

2. Scroll down to the "Process" modules.

3. Click "Install" for the "Forgot Password" module.

That's all there is to it. You will now see a "Forgot Password" link on your login page.

---

*ProcessWire's "Forgot Password" function is actually a little more secure than what you see in most other CMSs. Not only do you have to have the confidential link in the email, but the link expires in a matter of minutes, and PW will only accept password changes from the browser session that initiated the request. So an attacker would have to initiate the password change request and have access to your email at the same time, making it a lot harder for a man-in-the-middle snooping on your email.

[Robert Zelník]

Is this working with ProcessWire 2.2? I see in field_pass table that the hash is changed after loading the template, but I can not login with this changed password.

[ryan]

This is working in 2.2. I just had to do it yesterday.

I was going to say "what password are you using", but that's probably not a good idea. Instead, why don't you try with another password. There is a known issue in the queue with passwords that are exclusively non-ascii. If you find it's still not working, give me an example of a fictional password that I can use to reproduce the issue.

[Robert Zelník]

In this case I use very easy passwords like "you123". Maybe there's something wrong with my local PW installation or with my Apache settings. I copied the local installation on a remote server, then I reset the password on a remote via email. I checked it and successfully logged in. Then I copied the whole database from the remote back to the localhost and the password which worked well on the remote didn't work on the localhost. No problem, I will work with a remote site.

[WillyC]

don't know for sure if this it is,but copy.this line in site/config.php at bottom from 1 site to other site. need same between 2 sites:

$config->userAuthSalt = 'computer language.here';

[Robert Zelník]

Yes, userAuthSalt is the point. Thanks, WillyC.

[Soma]

I got smae problem with moved pw website to local server. I reset passwort and have same userAuthSalt, but I can't login. If I use the pw I've created it doesn't show any error, just stays on login page and I'm not logged in.

[ryan]

Soma this sounds like a different issue than userAuthSalt, because you could expect to see an error message if the authentication was failing. If you aren't seeing any errors, then it sounds to me like there's a flow control issue with the Process module. Can you paste in the exact URL that appears in your address bar when you are on the login page? Is the URL that appears after you submit the form exactly the same? Also note that the URL should always end with a slash here. The only other thing I can think of: have you possibly turned on template caching with the admin template? (I doubt it, but just checking).

[Soma]

Ryan, url is /processwire/ and when submited still same url. It does only show login error when I enter a false password. Really strange, it works great on real server, just not on my local one. I use XAMP, and got many PW installs working normal. I transfer files import db and the site is working normal, just can't login.

[Soma]

Just tried again, and this time I turned on debug . Ok why didn't I do that before... idiot.

Warning: Unknown: open(/Applications/XAMPP/xamppfiles/htdocs/.../site/assets/sessions/sess_529b6c6c041378cc9f28b165bf8bd0d3, O_RDWR) failed: Permission denied (13) in Unknown on line 0

Warning: Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/Applications/XAMPP/xamppfiles/htdocs/.../site/assets/sessions) in Unknown on line 0

So it seems I've to set the permissions again. It's working!! Whow.

What would you suggest setting the permission in this case on macos? Doesn't it change when I upload these folder to ftp?

[ryan]

Glad that you got it working. Those session files don't need to travel with the site, so I would suggest just deleting everything in /site/assets/sessions/ and /site/assets/cache/Page/ when migrating from one server to another. Though if you use the ProfileExporter to migrate, you don't need to do this.

[Ralf]

...

<?php
$admin = $users->get('admin');
$admin->setOutputFormatting(false);
$admin->pass = 'yo123'; // put in your new password
$admin->save();

…or if it's easier for you to copy/paste everything on one line, here's the same thing as above on one line:

<?php $users->get("admin")->setOutputFormatting(false)->set('pass', 'yo123')->save();

Replace "yo123" with the new password you want and save the template. Then view a page using that template (like the homepage, in our example). The password for that account has now been reset, and now you are ready to login.

...

@ ryan

could you please edit your first posting of this tread??

Because i´ve got this mistake an try the code from you a lot of time but noting happens.

Then i change the password to "uiop6789" and it works ...

The answer i found in the profile -> set password site:

Password must be at least 6 characters and have at least 1 letter and 1 digit.

But the code above has only 5 characters

Big thanks Ralf

[ryan]

Good find, I have updated it to be 7 characters. (we didn't use to have a character limit when this was originally written)

[Ralf]

Yea i thougt that but now 8) - THANKS

[mindplay.dk]

Good find, I have updated it to be 7 characters. (we didn't use to have a character limit when this was originally written)

Having the character limit (or any other password rules) at the API level seems wrong? It's validation for user input, and this isn't user input.

(is this a general thing about PW Page objects that one should be aware of? it validates the model itself rather than the user input?)

[ryan]

Having the character limit (or any other password rules) at the API level seems wrong? It's validation for user input, and this isn't user input.

In this case I would agree, so this particular validation (password) is at the input level (inputfield) rather than fieldtype.

So even though "yo123" would be perfectly fine at the API level, Ralf was right in pointing out it's not consistent with our recommendations for passwords.

(is this a general thing about PW Page objects that one should be aware of? it validates the model itself rather than the user input?)

It's up to the inputfield or fieldtype module author to decide on the details, but a good rule of thumb is that input validation is typically the job of an inputfield, while page data validation (API) is typically the job of the fieldtype. Fieldtype validation is more about integrity of system data, while Inputfield validation is about enforcing rules within the data that is input.

[owzim]

Putting the reset into the home.php template did not work for me. How is this page even loaded when I am logged out? 

I appended it to the admin.php, then it worked.

[diogo]

You don't have to be logged in to access the homepage of the website. You just have to put that piece of code in the home.php and visit the homepage as any visitor would. That alone will make the code work.

[owzim]

You don't have to be logged in to access the homepage of the website. You just have to put that piece of code in the home.php and visit the homepage as any visitor would. That alone will make the code work.

Of course, I was a bit frustrated about and it was late =)

I then kind of had the notion that I have to be logged in to acces any content. Silly me.

[diogo]

not sleeping does that to people

[diogo]

[apeisa]

This is totally guessing, but since craft has "commercial" baked in (you buy plugins directly from the app), I assume it might have admin user accounts on their server (or something like that).

[diogo]

I must say it's a very good looking app. I installed it on fortrabbit to test. (Craft this is the former Blocks CMS, for those who are wondering)

[OrganizedFellow]

Just to test things out, I did this and it works flawlessly FAWESOME security implementation Ryan!

$users->get("organizedfellow")->setOutputFormatting(false)->set('pass', 'qwerty123')->save(); 

PW2.3

[OrganizedFellow]

Saved my butt - AGAIN, thanks Ryan!

(i'm glad I bookmarked this)