I have this question out on browser-logger’s home blog, but asking
here provides a wider net, and helps us discuss Rails’s inner
Here’s browser-logger’s blog entry:
Here’s its only relevant source file:
http://rubyforge.org/viewvc/lib/browser_logger.rb?revision=1&root=browser-logger&view=markup ( http://tinyurl.com/yvqymn )
browser-logger is a single, dirt-simple file that works by hooking two
places. It hooks the logger ([RAILS_DEFAULT_LOGGER,
ActiveRecord::Base.logger].each), whenever it starts logging, and it
hooks your ActionController::CgiResponse ( def out ).
When you hit a page, you can hit with an extra parameter:
and the hooks will collect the log while evaluating that page, then
append its contents, as beautiful interactive DHTML, to the end of the
page that it logged. As usual for a Rails plugin, this is both
brilliant and potentially fishy.
I want to use this on a live site with lots of hits. How do I secure
it? After manually debugging for several grueling hours (or at least
it felt like it!), I arive at this utterly pathetic hack:
def process(request,response, method = :perform_action, *arguments)
if request.session[:user] and
User.find(request.session[:user]).login == ‘phlip’
$browser_buf ||=  if request.params.key?(‘logs!’) or
unhooked_process(request,response, method, *arguments)
What’s wrong with that if it works? Let me count the ways. Firstly,
disregard the hard-coded administrator’s name. We all know how to
productize a white-list. Next, we are reaching out to a model object
(User), all the way up in the Base of our Controllers. That’s probably
legal (if the Models were initialized first), but it’s hardly
Next, if the user doesn’t exist, we go crashie-poo. I suppose more if
statements can fix that. And so on…
What’s the real fix for this situation?
(And when we are done, we will get it working for Ajax and Juggernaut
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!