Good idea to access session in observer or not?

Question

I want to log user's actions in my Ruby on Rails application.

So far, I have a model observer that inserts logs to the database after updates and creates. In order to store which user performed the action that was logged, I require access to the session but that is problematic.

Firstly, it breaks the MVC model. Secondly, techniques range from the hackish to the outlandish, perhaps maybe even tying the implementation to the Mongrel server.

What is the right approach to take?

Answer 1

You're right about it breaking MVC. I would suggest using callbacks in your controllers, mostly because there are situations (like a model which save is called but fails validation) where you wouldn't want an observer logging anything.

Answer 2

I find this to be a very interesting question. I'm going to think out loud here a moment...

Ultimately, what we are faced with is a decision to violate a design-pattern acceptable practice in order to achieve a specific set of functionality. So, we must ask ourselves

1) What are the possible solutions that would not violate MVC pattern

2) What are the possible solutions that would violate the MVC pattern

3) Which option is best? I consider design patterns and standard practices very important, but at the same time if holding to them makes your code more complex, then the right solution may very well be to violate the practice. Some people might disagree with me on that.

Lets consider #1 first.

Off the top of my head, I would think of the following possible solutions

A) If you are really interested in who is performing these actions, should this data be stored in the model any way? It would make this information available to your Observer. And it also means that any other front-end caller of your ActiveRecord class gets the same functionality.

B) If you are not really interested in understanding who created a entry, but more interested in logging the web actions themselves, then you might consider "observing" the controller actions. It's been some time since I've poked around Rails source, so I'm not sure who their ActiveRecord::Observer "observes" the model, but you might be able to adapt it to a controller observer. In this sense, you aren't observing the model anymore, and it makes sense to make session and other controller type data information to that observer. C) The simplest solution, with the least "structure", is to simply drop your logging code at the end of your action methods that you're watching.

Consider option #2 now, breaking MVC practices.

A) As you propose, you could find the means to getting your model Observer to have access to the Session data. You've coupled your model to your business logic.

B) Can't think of any others here :)

My personal inclination, without knowing anymore details about your project, is either 1A, if I want to attach people to records, or 1C if there are only a few places where I'm interested in doing this. If you are really wanting a robust logging solution for all your controllers and actions, you might consider 1B.

Having your model observer find session data is a bit "stinky", and would likely break if you tried to use your model in any other project/situation/context.

Answer 3

Hrm, this is a sticky situation. You pretty much HAVE to violate MVC to get it working nicely.

I'd do something like this:

class MyObserverClass < ActiveRecord::Observer
  cattr_accessor :current_user # GLOBAL VARIABLE. RELIES ON RAILS BEING SINGLE THREADED

  # other logging code goes here
end

class ApplicationController
  before_filter :set_current_user_for_observer

  def set_current_user_for_observer
    MyObserverClass.current_user = session[:user]
  end
end

It is a bit hacky, but it's no more hacky than many other core rails things I've seen.

All you'd need to do to make it threadsafe (this only matters if you run on jruby anyway) is to change the cattr_accessor to be a proper method, and have it store it's data in thread-local storage

Answer 4

In the past, when doing something like this, I have tended towards extending the User model class to include the idea of the 'current user'

Looking at the previous answers, I see suggestions to store the actual active record user in the session. This has several disadvantages.

• It stores a possibly large object in the session database
• It means that the copy of the user is 'cached' for all time (or until logout is forced). This means that any changes in status of this user will not be recognised until the user logs out and logs back in. This means for instance, that attempting to disable the user will await him logging off and back on. This is probably not the behaviour you want.

So that at the beginning of a request (in a filter) you take the user_id from the session and read the user, setting User.current_user.

Something like this...

class User
  cattr_accessor :current_user
end

class Application
  before_filter :retrieve_user

  def retrieve_user
    if session[:user_id].nil?
      User.current_user = nil
    else
      User.current_user = User.find(session[:user_id])
    end
  end
end

From then on it should be trivial.

Answer 5

I found a clean way to do what is suggested by the answer I picked.

http://pjkh.com/articles/2009/02/02/creating-an-audit-log-in-rails

This solution uses an AuditLog model as well as a TrackChanges module to add tracking functionality to any model. It still requires you to add a line to the controller when you update or create though.