ryan Posted October 2, 2011 Share Posted October 2, 2011 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. 18 1 Link to comment Share on other sites More sharing options...
Robert Zelník Posted February 2, 2012 Share Posted February 2, 2012 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. Link to comment Share on other sites More sharing options...
ryan Posted February 2, 2012 Author Share Posted February 2, 2012 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. Link to comment Share on other sites More sharing options...
Robert Zelník Posted February 2, 2012 Share Posted February 2, 2012 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. Link to comment Share on other sites More sharing options...
WillyC Posted February 2, 2012 Share Posted February 2, 2012 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'; Link to comment Share on other sites More sharing options...
Robert Zelník Posted February 3, 2012 Share Posted February 3, 2012 Yes, userAuthSalt is the point. Thanks, WillyC. Link to comment Share on other sites More sharing options...
Soma Posted February 12, 2012 Share Posted February 12, 2012 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. Link to comment Share on other sites More sharing options...
ryan Posted February 13, 2012 Author Share Posted February 13, 2012 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). Link to comment Share on other sites More sharing options...
Soma Posted February 13, 2012 Share Posted February 13, 2012 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. Link to comment Share on other sites More sharing options...
Soma Posted February 13, 2012 Share Posted February 13, 2012 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? Link to comment Share on other sites More sharing options...
ryan Posted February 13, 2012 Author Share Posted February 13, 2012 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. Link to comment Share on other sites More sharing options...
Ralf Posted August 20, 2012 Share Posted August 20, 2012 On 10/2/2011 at 3:34 PM, ryan said: ... <?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: Quote 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 Link to comment Share on other sites More sharing options...
ryan Posted August 21, 2012 Author Share Posted August 21, 2012 Good find, I have updated it to be 7 characters. (we didn't use to have a character limit when this was originally written) Link to comment Share on other sites More sharing options...
Ralf Posted August 21, 2012 Share Posted August 21, 2012 Yea i thougt that but now 8) - THANKS Link to comment Share on other sites More sharing options...
mindplay.dk Posted September 18, 2012 Share Posted September 18, 2012 On 8/21/2012 at 11:30 AM, ryan said: 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?) Link to comment Share on other sites More sharing options...
ryan Posted September 18, 2012 Author Share Posted September 18, 2012 Quote 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. Quote (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. Link to comment Share on other sites More sharing options...
owzim Posted March 13, 2013 Share Posted March 13, 2013 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. Link to comment Share on other sites More sharing options...
diogo Posted March 13, 2013 Share Posted March 13, 2013 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. Link to comment Share on other sites More sharing options...
owzim Posted March 13, 2013 Share Posted March 13, 2013 On 3/13/2013 at 2:33 AM, diogo said: 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. Link to comment Share on other sites More sharing options...
diogo Posted March 13, 2013 Share Posted March 13, 2013 not sleeping does that to people Link to comment Share on other sites More sharing options...
diogo Posted March 15, 2013 Share Posted March 15, 2013 Link to comment Share on other sites More sharing options...
apeisa Posted March 15, 2013 Share Posted March 15, 2013 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). Link to comment Share on other sites More sharing options...
diogo Posted March 15, 2013 Share Posted March 15, 2013 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) 1 Link to comment Share on other sites More sharing options...
OrganizedFellow Posted June 11, 2013 Share Posted June 11, 2013 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 1 Link to comment Share on other sites More sharing options...
OrganizedFellow Posted August 21, 2014 Share Posted August 21, 2014 Saved my butt - AGAIN, thanks Ryan! (i'm glad I bookmarked this) Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now