This question is related to: Access current_user in model.
Specifically, I want to enable access to current_user in one Model.rb. #moif left a comment stating that the solution is not thread-safe, and I have read that there are additional caveats to using this process.
My question is this - if I were to add:
def self.current_user
Thread.local[:current_user]
end
def self.current_user=(usr)
Thread.local[:current_user] = usr
end
to one Model.rb (used only lightly and infrequently), what are the real-world implications for my app and is there anything additional I have to do to ensure its health?
Set up: Rails 1.9, Rails 3.0, Heroku, Authlogic.
I'm not sure I agree about the path you are taking. I agree with the other post that passing the current_user to the model is not appropriate but I wouldn't be using Thread.local for that. Here's why:
Developers love to get technical with solutions and there's not much more "closer to the system" you can get than a Thread.local. Having used Thread.locals before they are very tricky and if you don't get it right then you spend countless hours trying to figure out the problem let alone the solution. It also is difficult to find testers who can understand the complexities of Thread.local and be able to test the code thoroughly. In fact I would wonder how many developers put together solid rspec tests (or equivalent) for something like this. The "cost" of this solution may not be worth it.
I think I would take a look at what you are trying to do and see if there is an easier solution. For example, I can think of two off-hand (maybe would work or not in your case):
a) connect your history table to your user table with a foreign key. "belongs_to, has_many"; or
b) pass the username with attr_accessor on history and set that when creating the object.
Related
I'm working on fairly standard Ruby on Rails app where users have many studies. When a user signs up, I would like them to have a sample study as an example, similar to how Trello gives you a sample board on sign up.
My current approach is to deep_clone Study.first on registration and assign ownership to the current user. This means new users can edit their clone of the sample study and no-one else can see their changes. This works fairly well however it has now become quite complicated to clone studies as my associations are a lot more complex.
To simplify, I would like to change my approach for the sample study. Instead of cloning, I now want to give everyone access to the first study in the database, but read-only. Studies have a few views, e.g. users can change questions, participants, settings, add tags, etc. They should be able to see existing questions, participants, settings, and tags, but not add, remove, or edit them for this sample study.
I believe I need to:
Figure out how to make Study.first show up for everyone in all the right views without it actually being owned by current_user
Make this study read-only for everyone except me
What's a good approach for doing this in Rails?
For a classical server side application there are few ways around that you would need to use some sort of persistence to store the users changes between requests.
You could possibly setup some sort of inheritance so that studies can inherit from another study and use delegation to avoid duplication.
class Study
belongs_to :master, class: 'Study', optional: true
def get_some_field
master ? master.get_some_field : super
end
end
If the user is manipulating questions, participants, settings, and tags they should merely be working on join tables which are pretty cheap since they only involve storing two integers per row.
Another solution could be storing diffs or just the actual changes the user performs. It might be possible to use paper_trail or at least study it as a starting point.
For an ajax heavy application or SPA you might want to use local storage to fake the whole server interaction.
When a user creates a demo study they would fetch /studies/1.json and then when the play around they are just manipulating the object stored on the client.
In Ember you could for example swap out the adapter to ember-localstorage-adapter.
I am currently creating an app where users can create and apply for jobs. However as I am fairly new to rails I am facing a fairly significant security feature in that if any user knows the correct path, for example:
localhost:3000/users/user_id/apps
Then they can see any application made by any user for any job!
I am fairly sure that I need to use a before_filter to check that the current_user.id matches either the user_id found in my jobs table for each job or matches the user_id found in my applications table.
I am really not sure how to structure this though or where to apply the filter - for example is it better to create the filter in the application controller and then apply a skip_before_filter instance where needed.
Any help people can offer on contructing this code and where to place it would be much appreciated! Thanks :)
Before you start looking at authorization solutions such as cancan, a simple approach is to avoid doing
App.find params[:id]
Since an app is associated to a user and you've got current_user setup you can do
app = current_user.apps.find params[:id]
Which will only find apps associated with the user, no matter what the parameters to find.
Where cancan really comes into its own is when you need a more complicated who can do what system. For example a user might be able to edit any job they've created but view (and not edit) another set of jobs.
For example
can :manage, Project, :user.id => user.id
can :read, Project, :department => user.department
This would allow users full access to any of their projects and read access to projects in their department
Another thing about cancan is that rather than having before_filters or macros scattered around your controllers you declare the rules in one place, so it's usually easier to see what's going on. There's loads more info on the cancan wiki an a railscast too.
You are right a before_filter might be an sollution but its not the state of the art solution. Theres a railscast for that,...
http://railscasts.com/episodes/192-authorization-with-cancan/
When your using cancan but not devise you need to create the current_user helper that should return the User object of the currently logged in user...
My Problem
We are developing a locally-hosted web application for small businesses. We also have a demo site that lets potential customers look around to evaluate the product. Right now, all customers using the demo site have access to the same data, which is less than ideal because they might be making modifications behind each others backs, which would make the app feel "unstable" if they noticed. I would like to give each customer their own data subset to improve their experience. Adding a user_id column to all my models is easy enough, but now I need to make sure all the queries use this new association.
The Hard Way of Solving My Problem
I could go through by hand and change a call like #people = Person.all to #people = current_user.people, but lame! Development is continuing on the master branch, and I don't want to have to babysit every query when I merge over to the demo branch.
What I'd Like to do Instead
I would like to do create an around_filter in my application_controller that will grab my queries and add in this extra layer of scoping like so:
around_filter :scope_on_current_user
def scope_on_current_user(&block)
MagicalClass.scope_on_user(current_user, &bock)
end
This is an idea I got from octopus, which is a database sharding gem. I've looked around in their source code, and it looks pretty hairy. They pretty much go elbow-deep into ActiveRecord, hijacking the DB connection, etc. I'm hoping that is overkill for what I want. Any advice on how MagicalClass might work? :)
Rails 3.1.0
ActiveRecord 3.1.0
There are patches to allow default scopes to take procs see here for details, and it may work now without any of the patches/gems.
That combined with Thread.current may be enough to get you going.
That said... might it make more sense to take a multi-tenant approach with separate DBs altogether?
In my opinion one good way to reduce support time is to predict any problems our users try to report us.
We already do it using exception notification in Rails. We also have a nice control panel so we can access useful information even before the user types his first question mark.
We want to go one step further and to be able and see any validation errors our users have in our control panel.
As users don´t read dialogs, I´m willing that our software have some sort of check engine. Is there any gem or plugin that tracks all validation errors in rails? If not anyone got some tips on writing one?
I don't know about any plugin. To save info about server-side validations, you can very easily put this in your application.rb:
class ActiveRecord::Base
def valid_with_reporting?(context = nil)
model_is_valid = valid_without_reporting? context
MyErrorReport.create(errors) unless model_is_valid
model_is_valid
end
alias_method_chain :valid?, :reporting
end
Where MyErrorReport is your model that stores the given Hash into the database.
The problem with the above solution is that you probably want it to test your usability and user interface design, don't you? And a good user interface usually has a lot of validations client-side only and it would not be so straightforward to test those.
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?
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
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.
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.
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.
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.
http://www.zorched.net/2007/05/29/making-session-data-available-to-models-in-ruby-on-rails