filter sensitive logs.

shit, There is no ruby category.

if user submit a registeration form, it contains password info.
look at the development.log, we will see all the arguments of the submit are in plain text.

here is the log:

Processing UsersController#create (for 127.0.0.1 at 2009-01-02 10:13:13) [POST]
Parameters: {"user"=>{"name"=>"eifion", "password_confirmation"=>"secret", "password"=>"secret"}, "commit"=>"Register", "authenticity_token"=>"9efc03bcc37191d8a6dc3676e2e7890ecdfda0b5"}
User Create (0.5ms)   INSERT INTO "users" ("name", "updated_at", "password_confirmation", "password", "created_at") VALUES('eifion', '2009-01-02 10:13:13', 'secret', 'secret', '2009-01-02 10:13:13')

This is obviously not safe, so let's take some measures.

We should add a line of code into application.rb (ApplicationController):

filter_parameter_logging "password"

Rails 1.2 introduced the filter_parameter_logging command. Putting this command in to the ApplicationController allows us to filter parameters based on their name

Later versions of Rails have this line in the application controller by default, but commented out, so we only have to uncomment it to use it. We’ll create another new user and see what’s in the logs.

Processing UsersController#create (for 127.0.0.1 at 2009-01-02 11:02:33) [POST]
  Parameters: {"user"=>{"name"=>"susan", "password_confirmation"=>"[FILTERED]", "password"=>"[FILTERED]"}, "commit"=>"Register", "action"=>"create", "authenticity_token"=>"9efc03bcc37191d8a6dc3676e2e7890ecdfda0b5", "controller"=>"users"}
  User Create (0.4ms)   INSERT INTO "users" ("name", "updated_at", "password_confirmation", "password", "created_at") VALUES('susan', '2009-01-02 11:02:33', 'verysecret', 'verysecret', '2009-01-02 11:02:33')

Great!

not only the password param is filterd, but also the password_confirmation param is filterd, this is because this command will filter any param whose name contains the argument.


But you can see that the password is still showing up in the sql command, don't worry, this will only be a problem in development mode as by default this data isn’t stored to the log in production mode. Also, if we are hashing our passwords before storing them in the database then the passwords won’t be sent to the database as clear text and won’t be seen in the log.