Aenima blog - Home

Base Auth - a complete tutorial to securing your Rails application

2008-12-08T12:00:00Z

This one's going to be a big one, be prepared for reading it in parts.

Base Auth's readme is of course available on its GitHub page, so make sure you have it open for reference.

Authorization By Controller

Guest User

First things first: make sure you have current_user method available in your controllers. If you're using Restful Authentication or Binarylogic's Authlogic for authentication - and you definitely should - you already have it and we can move to the next point.

Now, Base Auth generally uses instance methods of current_user, even for checking for guest user, and since implementing a "guest user" model is generally a good idea (default name like "Anonymous Coward" etc.), let's make it work:

app/models/user/guest.rb (yes, it's in user subdirectory - we're namespacing after all):

class User::Guest < User
  def validate
    errors.add(nil, 'Guest user cannot be saved.')
  end
end

app/models/user.rb:

class User < ActiveRecord::Base
  def is_guest?
    self.class == User::Guest
  end
end

Now, because we need to have a current_user always available, even if not logged in, let's add one more possibility of getting current_user. Here's the version for restful_authentication users - you can put it in ApplicationController class or AuthenticatedSystem module:

@current_user ||= (login_from_session || login_from_basic_auth || login_from_cookie || User::Guest.new) unless @current_user == false

Now we can begin our adventure with Base Auth by protecting one of our controllers from guest users:

class NotForGuestsController < ApplicationController
  deny :user => :is_guest?
end

Of course it's theoretically equal to before_filter :login_required, but instead of redirecting to login form, it throws an Authorization::PermissionDenied exception, with which you can do whatever you like. For example:

class ApplicationController < ActionController::Base
 
  rescue_from ActiveResource::ResourceNotFound, :with => :resource_not_found
  rescue_from ActiveRecord::RecordNotFound, :with => :resource_not_found
  rescue_from Authorization::PermissionDenied, :with => :permission_denied
  
  def permission_denied
    render :text => "You don't have permissions to access this page.", :status => 403, :layout => true
  end
  
  def resource_not_found
    render :text => "This page doesn't exist", :status => 404, :layout => true
  end
end

I must admit, guest user handling is not where Base Auth shines. It does when it comes to securing user-owned content though.

User-owned content

This can be accomplished in two ways. One of them is to explicitly call allow! (or deny! if our app has a twisted and negative verification) in given action for a given resource:

class TasksController < ApplicationController
  deny :user => :is_guest?
  def edit
    @task = Task.find(params[:id])
    allow! :user => :owns?
  end
end

We're RESTful, right? Our app's too, so it means our controllers are a very thin layer between client and our models, so we usually name our controllers after the models they expose.

Base Auth is going to automagically guess the name of instance variable to check against current user, by singularizing controller's name and prepending it with "@". This way in TasksController it's going to look for @task variable, but we can of course tell base_auth to authorize using different variable:

class TasksController < ApplicationController
  def edit
    @something = Task.find(params[:id])
    allow! :user => :owns?, :object => @something
  end
end

This one takes a lot of coding and we'll usually have to repeat it through (almost) all the actions, so it's better to use base_auth as before_filter and grab the resource in another before_filter. You probably did it already (DRY!), and base_auth can make good use of it:

class AccountsController < ApplicationController
  before_filter :get_resource
  allow :show, :edit, :update, :destroy, :user => :owns?
  deny :user => :is_guest?
  
  protected
  
  def get_resource
    @account = Account.find(params[:id]) if params[:id]
  end
end

There's still one thing to implement: User#owns?(object) method:

class User < ActiveRecord::Base
  def owns?(target)
    #return true if self.is_admin?
  
    if target.respond_to?( :owned_by? )
      target.owned_by?( self )
    elsif target.respond_to?( :owner_id )
      self.id == target.owner_id
    else
      false
    end
  end
  
  def owner_id
    self.id
  end
end

Of course you can implement it differently, or make use of user_id field instead owner_id. Or make owner_id an alias to user_id in owned resource... or do anything you like. User#owns?(target) has to work and that's the only constraint.

Not even that - you can use different method name passed to base auth's allow (like :user => :can_edit? and implement User#can_edit?(target)) to implement some more complex authorization logic.

Authorization By Model

This one has a pretty humble implementation at the moment, but lets you authorize by model and keep amounts of authorization code in your controllers as small as possible. That's basically the way it works:

class TasksController < ApplicationController
  deny :user => :is_guest?
  def edit
    @task = Task.find(params[:id]).authorize!(current_user)
  end
end

All you have to implement is Model#authorize(user) method in given model's class. For instance:

class Task < ActiveRecord::Base
  def authorize(user)
    user.user_id == self.owner_id
  end
end

And even that only if your Model#authorize method is going to differ from base_auth's default implementation:

module ModelAuthorization
  module InstanceMethods
    #re-implement this in your model if you check authorization in a different way
    def authorize(user)
      user.id == self.user_id
    end
  end
end

More complex authorization logic in authorize-by-model, like authorize_for!(:edit, current_user) about to become implemented in base_auth after some testing.

Ending

Base Auth is not perfect as in "drop in and use automagically without step 3 - perfect". We didn't want to overload it with convenience methods and defaults, as authorization is a pretty serious topic and working differently across different applications. That's why there has to be some code in the application, because everything that was common to our applications is already in base_auth. The rest has to be decided by application developer. We just wanted authorization to follow the KISS principle.

We're open to suggestions though, so feel free to comment and contact us with questions and ideas.

Base Auth grown up to 0.2

2008-12-05T10:10:00Z

A long, long time ago (a year in Rails world is almost a geological period) Robzon has published and announced Base Auth, his first serious Rails plugin. "Base" actually stands for "Best Authorization System Ever" and while it's of course tongue-in-cheek, simplicity and power of this plugin are sometimes simply stunning. We've been using it in most of our projects here and not only because Robzon is one of the founders and bosses ;)

I didn't like some of the approach that Base Auth forced on programmer, namely putting everything in filter and throwing the whole burden of authorization on controller's back. I want to keep my controllers thin and put as much as possible into the model, goddamit! For a few weeks now I've been trying to convince Robzon to add model-based authorization to Base Auth, preferably using as much common code with already implemented controller-based authorization as possible. After some perseverance I finally heard "YOU can implement it, especially since we moved base_auth to Github" and after getting such green light there wasn't much more to do than just sit and implement what I wanted to see there.

So there it is: Base Auth 0.2, available on GitHub, has now a pretty simple yet powerful and extensible support for model-based authorization. Just install, check and define Model#authorize (if default implementation doesn't suit you) and use model-based authorization this way:

Class ItemsController < ApplicationController
  def edit
    @item = Item.find(params[:id]).authorize!(current_user)
  end
end

Of course it's just the tip of an iceberg, as there's the whole world of controller-based and views-usable authorization methods available in Base Auth, of course compatible and interchangeable with the model-based one. Read the README and wait for a full tutorial here.

One last thing: you should gracefully rescue from exception thrown when authorization fails:

Class ApplicationController
  rescue_from Authorization::PermissionDenied, :with => :permission_denied
  
  def permission_denied
    render :text => "You don't have the permissions for this", :status => 403, :layout => true
  end
end

Same of course applies if you use allow! and deny! with controller-based authorization. Anyway, a bigger Base Auth tutorial is about to follow. Stay tuned!

NARN - a Rails newsletter plugin that doesn't suck

2008-12-04T10:40:00Z

Sticking up with the Engines theme and "stuff that many of our clients want in their applications", there's one small plugin we did some time ago in cooperation with developers from outside the company. We all needed a pluggable newsletter engine that would be easy to install, maintain and upgrade.

That's when NARN was created. It's a pretty small, but very useful Rails Engines plugin. It's on GitHub of course, so feel free to grab, test, modify and send suggestions and patches. You know you'll need a newsletter in some of your apps one day ;)

Aep Beast - a modern Beast forum fork

2008-12-04T09:09:00Z

There's been a lot of talk about Rails applications not being modular-able, forcing developers to copy-paste code instead of plugging it in in a true DRY spirit. Despite these claims, some developers believed they can make RoR apps modular and created Engines, one of the best and most innovative Rails plugins ever.

Most web applications come today with some ways to socially interact with other users. I believe they call it Web 2.0, although I saw this term used to label to many, many different things, including AJAX and standards compliant HTML and CSS. Anyway, there are a few means of such social interaction, including commenting (any or most of users' content), wikis and - my personal favourite - forums.

To the point. First there was Beast, an attempt to do functional RoR forum in 500 lines of code. Then came Rails 2.0 and together with it William B. Harding wrote Savage Beast, a RoR 2.0 compliant Beast fork. It's great (thanks, William!), but the code wasn't perfect: it didn't work properly with Rails 2.1, used outdated will_paginate (everyone's using Mislav Will_Paginate currently, right?). We needed a working Rails forum solution, preferably pluggable (so we could reuse the code given to our clients and let them upgrade forum engine painlessly), so we've forked Savage Beast, corrected a few imperfections, called it Aep Beast and put it on GitHub.

The best thing about GitHub in specific and Open Source in general is that anyone can grab the code, use it, fork it / modify it and make Aep Beast even better, cleaner, leaner and easier to use. So, everyone - feel free. GitHub awaits :)

If you have any suggestions, put it in the comments. Or, especially if you have a patch, mail me.

PS. What's the origin of "Aep" before the "Beast"? Well, it was supposed to be a part of "Aenima Platform", sort of RoR application scaffold and set of plugins we were going to reuse in many of the applications. But this idea got scraped when awesome Rails Generator came by. Now "Aep" means "from, coming from, derived from", from the Elder Speech - a language created by Andrzej Sapkowski in his books about the Witcher. We're (most of us) fantasy geeks anyway here. And if you haven't read his books about the Witcher, it's right about time.

Serving html(.erb) files from a controller - the easiest method.

2008-06-07T08:50:00Z

Suppose you'd like to have some "static" (as in html.erb, without content in the DB) pages on your Rails site. And to have some nice path, like mydomain.com/articles/somearticle, pointing to a file somearticle.html.erb somewhere in your app directory.

Well, this is the simplest and probably nicest of the options (and it's very "Ruby Way"). But I have to test it a bit more to clear some security questions - use at your own risk.

class ArticlesController < ApplicationController
  def method_missing(name)
    path = "#{RAILS_ROOT}/public/articles/#{name}.html.erb"
    render :file => path, :layout => true
  end
end

The best thing about it? 100% Globalize compatible, i.e. Globalize will automatically try to prepend extension with two-letter language code as usual with view files.

EuRuKo 2008 - day two (sunday)

2008-06-07T08:42:00Z

Sunday started pretty funny actually (wasn't so funny back then) - we forgot about daylight saving one-hour switch and after finally getting up we've realized that we don't have over 90 minutes until my talk, but only half an hour. We rushed into the Charles University with me leading, as getting late on one's first conference talk ever is definitely a bad idea. I managed to get on time, mostly thanks to my predecessor stretching his talk a bit and coffee break. After some fighting with xrandr (thanks Karel!) I was ready to go. Well, at least technically.

11.30: Tomasz Stachewicz - "Sharing the load". It's not a good idea to write about my own talk. Let's just say it went well I think, put some light onto OpenWFEru (which I wanted to do the most) and showed that BackgrounDrb isn't the only way to go.

After doing some lunch break (and first beer that day) we were back at Euruko, to listen to some more talks.

14.30: Tim Becker - "Lessons Learned Writing Native Extensions". A good one. Not a lot of jokes, but very decent from technical standpoint and definitely worth the time. Could start from some higher level (as in "higher than explaining C types"), but for some this revision of basics was very refreshing and it's always better to start explaining from too low than from too high level. Tim Becker is on my Ruby radar - I think he's going to write some good stuff.

15.00: Matt Ford - "Aspect Oriented Programming in Ruby". I always wanted to learn a bit about AOP in Ruby and this walk was just what I needed. Enough said :)

After some more lightning talks we had to rush to train station. I've just managed to tell Karel and Peter that it was a perfect conference (exactly - perfect: I wouldn't like to improve anything) and we'd like to organize Euruko 2009 or 2010 in Poland, in Krakow to be precise.

EuRuKo 2008 - day one (saturday)

2008-06-07T08:41:00Z

First week of june seems like a perfect time to write about EuRuKo, a conference held at the end of march. Well, sarcasm aside – starting a company/group technical blog (and by starting I mean “populating with content”) isn’t the easiest thing we’ve been doing.

Disclaimer: this one is written by me (Tomash) and presents only my personal perspective. I’m trying to talk other guys into writing their own impressions.

Enough babbling, time to start with the report.

Saturday.

It was a good morning. Well, a decent at least, considering some partying after reaching Prague on friday. After breakfast, registration and letting our girlfriends visit Prague on their own we were ready for our first Ruby conference. As we all know from EuRuKo Program, it all started with Matz.

10.00: Yukihiro “Matz” Matsumoto – “Keynote”. This one was great, definitely one of the best talks during this Euruko. Not (only) because it was Matz who gave it, but mostly because it perfectly balanced some technical details and jokes. Matz turned out to be a pretty good English speaker (definitely better that what I’d expect from Japanese), at least comparing to Koichi that was about to follow…

11.00: Koichi Sasada – “Ruby meets VM”. Now, Koichi is a great man and he deserves a lot of respect for task as daunting as writing VM for Ruby. His talk was great from a technical point of view. At least from what I understood. And there we are, at the weakest point of his talk—some slides were in japanese and Koichi is simply… well, let’s say that he’s definitely better at Ruby than speaking english ;)

Because we actually knew JRuby, we’ve decided to have a walk through Prague Old City (it’s beautiful) and try some more of famous Czech beer. Being Polish we’re actually a bit picky about beer from other countries, but the beer we drank in Prague was – regardless of brand – just great and, I dare say that, even better than beer in Poland.

After getting back and having some great lunch at the conference we were prepared for next set of talks.

14.30: David A. Black – “Per-Object Behavior in Ruby”. Definitely the most enlightening talk amongst the ones I’ve listened to. Writing more about it would be a waste of time, just grab the video and watch it. Made me a better Ruby programmer.

15.15: Nic Williams – “Meta-Meta-Programming with Ruby”. I was disappointed. If I had to give it “the most” title, it would be “the most disappointing talk”. Dr Nic is a well-known man in Ruby and Rails community, and – to say the least without writing pages about great things he’s done – he definitely deserves his fame and thus I was looking forward to listening to a talk by someone of such format. But, as I wrote earlier, I was disappointed. Dr Nic put too much weight on making his talk easy, witty and full of jokes and, well, hasn’t put a lot of technical knowledge into his talk. Sure, it was a bit philosophical, but definitely not worth 45 minutes of Ruby conference.

After spending some time on Lightning Talks (few were great, few weren’t) we’ve decided to get some more of Prague’s views and beer (I also had to give my talk a few finishing touches and some polish), and thus left Euruko until sunday.

RailsConf 2008 is over, so...

2008-06-07T08:33:00Z

... so let's publish my impressions from march'08 EuRuKo. Finally, that is.

You can write FORTRAN in any language

2008-04-14T09:32:00Z

This is a translation of Radarek's excellent article.

You can write FORTRAN in any language

A language that doesn’t affect the way you think about programming is not worth knowing

You can write C code in Ruby:

Car = Struct.new(:model, :color, :opt)

CAR_MODEL_BWM       = 0
CAR_MODEL_AUDI      = 1

CAR_OPT_GAS         = 0x01
CAR_OPT_AIR_COND    = 0x02
CAR_OPT_ROOF_RACK   = 0x04

CAR_COLOR_BLACK     = 0
CAR_COLOR_RED       = 1
CAR_COLOR_GREEN     = 3
CAR_COLOR_BLUE      = 4
CAR_COLOR_WHITE     = 5

CAR_MODEL_NAMES = [
  "BMW",
  "AUDI"
]

CAR_COLOR_NAMES = [
  "black",
  "red",
  "green",
  "blue",
  "white"
]

def car_create(model, color, opt = 0)
  car = Car.new
  car.model = model
  car.color = color
  car.opt   = opt
  return car
end

def car_print(car)
  printf("[Car] model: %s, color: %s\n", CAR_MODEL_NAMES[car.model], CAR_COLOR_NAMES[car.color])
  printf("Options: \n")
  if car_has_gas(car)
    printf(" - gas\n")
  end
  if car_has_air_cond(car)
    printf(" - air condition\n")
  end
  if car_has_roof_rack(car)
    printf(" - roof rack\n")
  end
end

def car_max_speed(car)
  case car.model
  when CAR_MODEL_AUDI
    return 200
  when CAR_MODEL_BWM
    return 220
  else
    return -1
  end
end

def car_has_gas(car)
  return (car.opt & CAR_OPT_GAS) != 0
end

def car_has_air_cond(car)
  return (car.opt & CAR_OPT_AIR_COND) != 0
end

def car_has_roof_rack(car)
  return (car.opt & CAR_OPT_ROOF_RACK) != 0
end

car = car_create(CAR_MODEL_BWM, CAR_COLOR_BLACK, CAR_OPT_AIR_COND)
car_print(car

You can write Java code in Ruby:

class User
  def initialize(name, age)
    self.setName(name);
    self.setAge(age);
  end
  
  def setName(name)
    @name = name;
  end
  
  def getName()
    return @name;
  end
  
  def setAge(age)
    @age = age;
  end
  
  def getAge()
    return @age;
  end
end

class Iterator
  def initialize(array)
    @index = 0;
    @array = array
  end
  
  def hasNext()
    return @index < @array.length();
  end
  
  def getNext()
    @index += 1;
    return @array[@index - 1];
  end
end

array = [User.new("john", 20), User.new("ala", 30), User.new("dave", 15)];
it = Iterator.new(array);
while (it.hasNext())
  user = it.getNext();
  puts("Name: " + user.getName() + ", Age: " + user.getAge().to_s());
end

You can write Perl code in Ruby:

while gets
  chomp
  next if /^#/ or /^!/
  break if /quit/
  
  if /(\d+)/
    print $1
  end
end

The purpose of this note: if you want to program in Ruby, learn the language properly, not just the syntax with standard library. Learn it long enough (or effective enough) until you learn it's style, mindset, idioms and nuances. Then write your Ruby programs using these idioms, standards, way of naming and structing and so on. Don't stop until you learn almost all about it - and when you do, you'll find a lot more to be learned about. You probably already know what OOP is, so put emphasis on non-obvious basics, like method-calling, mixins, includes, extends, metaclasses and so on. Experience life without static typing, experience the power of Ruby's metaprogramming possibilities (and dangers).

Otherwise there'll be a chance you're not writing Ruby, but some other language using simply Ruby syntax. If so - why pretend to write Ruby?

Back from Euruko 2008

2008-03-31T09:05:00Z

We just got back from Prague after attending to European Ruby Conference. Promise to write a review after we get everything running smoothly again (including this blog).