stonean

Had a request to honor the filter_parameter_logging when Lockdown raises a SecurityError on an invalid request. Lockdown now filters the parameters to hide sensitive data.

Thank you for bringing it to my attention.

I think it’s safe to assume that Lockdown will not be compatible with Rails 3.0 and since I have yet to find an authorization system with the same centralized rules philosophy, I need to make a drastic change.

Unless someone finds a critical bug, I will not be maintaining Lockdown. There will be a new (as yet to be named) project.

Why the big change? The first version of Lockdown was written for a pre 1.0 Rails application. Over time, it has been through a lot of refactoring, two major ones. Even having done that, there is still code that was written when I was first learning Ruby and was heavily influenced by my years as a Java programmer. I think it can be a lot cleaner/simpler.

The new project will be rack based to adapt easily to future changes and make it easier for Sinatra integration. I have been doing a lot of work with Sinatra lately and only see this increasing.

I’m not sure about the model level restrictions. I am not, nor was I ever, happy with the model level restriction functionality in Lockdown. Using it wasn’t intuitive and it’s implementation lacks intelligence . I’m not calling anyone out here, I wrote it and I think it sucks.

The idea of a centralized rule file will still exist in the new project. Therefore, converting your existing Lockdown based app to the new authorization system will only require a conversion of init.rb. I will be simplifying the dsl similar to this suggestion.

Unlike Lockdown, testing and documentation will be of equal importance to the code itself.

If you want to keep up to date with the progress, please follow me on twitter. I don’t tweet a lot of non tech noise.

To those who use Lockdown, thank you! The next project will be better.

Just released Lockdown version 1.6.1! This version addressed an issue with the rspec_helper introduced in 1.6.0. Essentially, since 1.6.0 introduced lazy loading, the init file wasn’t being parsed. So, when you include Lockdown::RspecHelper in you spec_helper, it calls Lockdown.maybe_parse_init to initialize the system for you.

I also fixed the mock_user method in the rspec_helper to stub out user_groups as an empty array. Was getting message ‘Mock :user received unexpected message :user_groups with (no args)’. Not any more.

Big usability release! Lockdown 1.6.0 is all about you, the developer. Tired of restarts? Tired of logging out to reset the session? Well, no more!

When Rails.configuration.cache_classes is false (development mode), Lockdown will reload the init.rb file on every request. In addition, the access_rights will be reset on each request. This means if you change public access rights in init.rb you don’t have to logout to have Lockdown apply the change. Slower, yes, but easier to work with when you are in heavy development.

This is a pretty big change, please run through your tests before promoting to production.

As always, constructive feedback is always welcome.

If you use Lockdown, a vote on RubyTrends would be appreciated. Knowing you took the time to cast your vote means a lot to me.

thanks,
andy

Hot off the gemcutter: Lockdown version 1.5.0

First off, you didn’t miss anything, version 1.4.0 wasn’t actually released. Just before pushing the gem to gemcutter I decided to make an improvement to the set_user_group logic. I felt the need to make it a bit smarter and let you know if you were assigning a public or protected user group to a custom user group.

So here’s what’s in this release:

1) Delayed the parsing of init.rb to the first request. I had a report of Glassfish timing out on startup and other issues when running running db:migrate with some plugins.

2) Improved set_user_group method logic to detect reuse of public or protected permission.

I know there are a couple of other issues on the lighthouse account and I will get to them when I can.

thanks,
andy

I’ve just released Lockdown version 1.3.2.

Lockdown is now being served up from gemcutter.org.

In this update:

• Lockdown will now report if permission belonging to public or protected groups is being assigned to custom user group.
• New rspec helper: login_with_permissions(*permission_symbols)
• The use of “puts” within Lockdown has been removed for all you Textmate users out there. :)
  • To have Lockdown use Rails.logger, just set Lockdown.logger = Rails.logger in config/environment.rb.

I’ll be tackling some of the other items on lighthouse next week. This week had some surprises that didn’t allow any extra time for Lockdown.

Update: RuHL has grown up a lot since this post. Please visit github for the README. I will be moving the docs here shortly.

Outdated:
I’m pleased to announce my new project Ruhl (Ruby Hypertext Language). Ruhl makes HTML dynamic with the addition of a ‘ruby’ attribute. It supports rendering with layouts and partials.

Simply put, Ruhl parses the HTML (with Nokogiri) and looks for the ruby attribute. It then executes the methods within the context of the calling environment. A simple call looks like:

  <h1 ruby="page_header">My default header</h1>

A call to process a Ruhl template looks like:

Ruhl::Engine.new( File.read(path_to_file) ).render(self)

The contents of the h1 are replaced by the results of the page_header method.

The idea is to avoid transforming the HTML into another language and make the designer’s job easier. If they need to go back and modify their work they don’t need the assistance of a developer.

Think Presenter pattern for the dynamic code aspect.

Checkout the github project for examples. There is Sinatra support, just require ‘ruhl/sinatra’ and you can use something like:

  get '/' do
    ruhl(:'layouts/application')
  end

This project is VERY young (just thought of the idea 4 days ago), so let me know what you think it needs to grow and improve.

I’ll be putting this to real world use in the next few weeks and will document various use cases/patterns as I discover them.

How to patch production code:

  # Grab the current production code
  git checkout -b name <tag|sha>

  # Update your code with the commit that will fix your problem.
  git cherry-pick <sha>

  # Show difference.  This is a review step.
  git diff <tag>..

  # Run your tests...

  # Create a new annotated tag
  git tag -a <tag name>

  # Push the new tag up so you can deploy it
  git push --tags

As it happened with my first Rails project years ago, I have a little Sinatra project that is going to require authorization. Therefore, I’ve created a new project on github called rack-lock.

Rack::Lock will be the future of Lockdown. For those using Lockdown, you need not worry. When the time comes for you to upgrade you’ll just need to use Rack::Lock instead of requiring Lockdown.

If you have some requests, just add a comment below.

This is a minor update to address a few lighthouse issues:

Ticket #23 Added login_with_permissions method to rspec_helper

Ticket #25 Fixed rspec helper methods: login_with_groups. Was setting access_rights correctly but wasn’t actually “logging in” a user (e.g. no current_user).

Ticket #26 incompatibility with exception notifier gem. (renamed access_denied to ld_access_denied)

Also added more tests and consolidated the error classes (they were spread across various modules).

For more info on Lockdown, check out the wiki