Passwords and More Security for a Rails Ecommerce Application
In this third part to a four-part series on building the security into a Ruby-on-Rails ecommerce application, we'll focus on the changes we need to make to the program so that users can change their passwords. This article is excerpted from chapter eight of the book Practical Rails Projects, written by Eldon Alameda (Apress; ISBN: 1590597818).
Passwords and More Security for a Rails Ecommerce Application - Modifying the Controller (Page 4 of 4 )
The last things to do for our password reset functionality are to tie it all together inAccountControllerand to create views for it. First, to make our new observer work, we need to call it in the controller with theobserver macro. Add the following code to theAccountControllerclass inapp/controllers/account_controller.rb:
class AccountController < ActionController::Base observer :user_observer ...
Next, we need two actions to support the password reset functionality: one to request the reset code to e-mail, and one to do the actual resetting. We’ll call themforgot_passwordandreset_password. Let’s implement these actions at the end ofAccountController:
def forgot_password return unless request.post? if @user = User.find_by_email(params[:email]) @user.forgot_password @user.save flash[:notice] = "An email with instructions for resetting your password has been sent to your email address." redirect_back_or_default(:controller => "/account") else flash.now[:notice] = "Could not find a user with the given email address." end end
def reset_password @page_title = "Reset Password" @user = User.find_by_pw_reset_code(params[:id]) rescue nil unless @user render(:text => "Not found", :status => 404) return end return unless request.post? if @user.update_attributes(params[:user]) @user.reset_password flash[:notice] = "Password successfully reset." redirect_back_or_default(:controller => "/account") end end
forgot_passwordwill show a form where the users can add their e-mail address. When the form is submitted to the same action, it will fetch the user with the given e-mail address from the database. Then the action calls theforgot_passwordmethod for the@userobject to generate the reset code. Finally, it saves the object, thus triggering theafter_savecall inUserObserverand causing the e-mail message with the reset URL to be sent. If everything goes smoothly, the action redirects the user back to where he started the new password request. Otherwise, we’ll redisplay the form with an error message.
reset_passwordis the action where George lands when following the link in the e-mail message. It gets the user object by the reset code part of the URL. If the user isn’t found, a simple 404 Not Found page is shown. Otherwise, the action shows a form where George can give and confirm a new password. We use postback here as well, meaning that the form is posted to the samereset_passwordaction. When the action is run from aPOSTrequest, we update the password, set the reset code tonilcalling thereset_passwordmethod for@user, and finally redirect the browser back to wherever George happened to be before trying to log in.
Please check back next week for the conclusion to this article.
DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware.