Lighthouse has a new layout. Prefer the old one? Return to the old layout, and switch back any time from the link at the top of each page.

This project is archived and is in readonly mode.

config.filter_parameters doesn't affect debug(params)

#5652

Seems to me that <%= debug(params) %> should be modified by config.filter_parameters

It's not unprecedented -- I used a language (Lasso) for many years which this similar ability of config.filter_parameters, and whenever the equivalent of params was displayed, that list was filtered to prevent display of identified values, though it still displayed the names of course.

Reported by greg (at araelium) · September 18th, 2010 @ 07:06 AM

State: wontfix
Milestone: none
Assigned to: nobody
Importance: Low

Activity

  1. Rohit Arondekar
    Rohit Arondekar
    • Importance changed from to Low

    I don't think so imho. Debug is for debugging and you don't want to filter any parameters at that time. You shouldn't be developing with the production database any way so you shouldn't be looking at any important params. It's main job is to filter sensitive params from the logs.

    Anybody else have an opinion on this?

    September 18th, 2010 @ 07:33 AM

  2. greg (at araelium)
    greg (at araelium)

    Mmm, I can see where that logic might arise, and I'll attempt a counter thought with "if it's sensitive, it's sensitive" and the framework shouldn't be making any assumptions as to when it is or isn't suitable to be displayed. config.filter_parameters allows me to decide that I don't want certain things to show accidently outside my app code, so the framework should make that as universally applicable as possible. I can use other methods to override that if I need to from removing it, to using environments (I think), to something as barbaric as re-assigning to another var name to output if I really need to see it.

    Anyway, I guess that's my 4¢. Just something to consider.

    September 18th, 2010 @ 09:25 AM

  3. David Trasbo
    David Trasbo

    I totally agree with Rohit.

    There will always be a way to somehow disclose filtered params in development. A silly example:

    class SessionsController < ApplicationController
      def create
        raise params[:password] # oh no, security breach!
      end
    end
    

    You chose to display what's in params while in the development environment - that's your responsibility. Besides, as Rohit said, of course you're not working with sensitive data in development.

    IMHO, this should just be marked wontfix.

    September 20th, 2010 @ 12:46 PM

  4. Rohit Arondekar
    Rohit Arondekar
    • State changed from new to wontfix

    September 20th, 2010 @ 01:06 PM