Displaying posts 11 - 19 of 19
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
I’m pleased to announce the release of Lockdown version 1.3.0!
What is it? It’s an authorization system for Rails 2.×. Here’s the homepage for the docs.
There are two big parts to this release:
The RSpec helpers are designed to make testing your access permissions defined in lib/lockdown/init.rb easy.
There’s more detail about the RSpec helper here.
It’s a young addition so if there’s something I missed let me know on the lighthouse lockdown account by submitting a ticket.
To those of you that have submitted tickets and helped me make Lockdown better, THANK YOU!
I really do appreciate the feedback!
After creating a few repos in github, initializing them and running into the same problem I decided to figure out how to fix it.
Here’s the message:
You asked me to pull without telling me which branch you
want to merge with, and 'branch.master.merge' in
your configuration file does not tell me either. Please
name which branch you want to merge on the command line and
try again (e.g. 'git pull <repository> <refspec>').
See git-pull(1) for details on the refspec.
If you often merge with the same branch, you may want to
configure the following variables in your configuration file:
branch.master.remote =
branch.master.merge =
remote..url =
remote..fetch =
See git-config(1) for details.
You can get around doing config changes by adding additional parameters to the git pull command:
git pull origin master
But who wants to do that everytime? Not me. Especially since I have my aliases setup:
alias ga='git add'
alias gb='git branch'
alias gba='git branch -a'
alias gc='git commit -v'
alias gca='git commit -v -a'
alias gd='git diff'
alias gko='git checkout'
alias gl='git pull --rebase'
alias glv='git pull -v'
alias gp='git push'
alias gpv='git push -v'
alias gs='git stash'
alias gst='git status'
So the right thing to do is fix this by modifying .git/config in your repo and adding the following section:
[branch "master"]
remote = origin
merge = refs/heads/master
Now I can use my aliases as I like and know a little more about git.
It’s a process.
I’m very pleased to announce the release of Lockdown 1.1.0! A lot of people have been giving me feedback, different use cases, etc… and Lockdown has benefited greatly!
Thank you to all those who have reported issues and even offered up solutions (my favorite!).
In addition to bug squashing, Lockdown 1.1.0 includes two new options:
# Set User model:
# options[:user_model] = User
#
# Set UserGroup model:
# options[:user_group_model] = UserGroup
If you don’t use UserGroup or User models in your application, you can now customize Lockdown to reference your models.
For more information on Lockdown, check out the wiki page.
Thanks again to everyone who has helped me make Lockdown better!
Oh yeah, don’t forget to vote for it on RubyTrends. I would appreciate it! This helps lets me know how many people out there are using it.
A little while ago I wrote a blog post titled Convention of Configuration that briefly covered how to take advantage of the constructs provided by Rails. One of the ideas was to take advantage of the environment config options and showed how to add your own config functionality inside the Rails::Initializer block. This has worked very well for us at Primedia, but there is a downside. It has become a little difficult to manage all the different modules contained within this one file. We needed something more manageable.
The first that came to mind was to break out each module into its own file. Sticking with the mycompany.rb convention introduced in the first post, we created a mycompany directory that contained each one of the modules.
Example directory structure:
RAILS_ROOT
|---lib
| |---enhance.rb
| |---mycompany.rb
| | mycompany
| | |----settings.rb
| | |----google.rb
| | |----twitter.rb
| | |----facebook.rb
Our main mycompany.rb could just iterate over the files in that directory and require them, easy peasy. I’ll go into more detail, but here’s the code:
# file: mycompany.rb
$:.unshift(File.dirname(__FILE__))
require "enhance"
module Mycompany
class << self
include Enhance
# Add utility methods here that have high reuse value
# Pass off methods to the Settings enhancement to make the calls
# shorter: Mycompany.settings.adapter vs Mycompany.adapter
def method_missing(method, *args)
settings.send(method, *args)
end
end
end
# Extend functionality of Mycompany module by requiring enhancements
# included in lib/mycompany/*
Dir[File.join( File.dirname(__FILE__), 'mycompany','*.rb')].each do |f|
require f
end
As you can see in the above code, we treat the Settings module a little differently. We would typically store attributes that don’t have or need a namespace to clarify their meaning. What this really means is I don’t want to have to do Mycompany.settings.foo all the time. Using settings doesn’t provide any contextual value and is a waste of time. If you had a Twitter module, then Mycompany.twitter.username does provide contextual value and doesn’t bother me. :)
Now lets look at an example settings file:
# file: mycompany/settings.rb
module Mycompany
module Settings
@@accessors = [ :foo, :bar, :biz, :baz]
class << self
attr_accessor *@@accessors
end
# Initiliaze class instance variables
@foo = []
@biz = {}
end
Mycompany.enhance(Mycompany::Settings)
end
I’m not a fan of class variables, but this looked like the best solution to the problem at hand. Using attr_accessor doesn’t give me an easy way to inspect the module and figure out what attributes have been defined. Using the @@accessors class variable gave me that inspection ability. Nice.
To further clarify, all your modules must use @@accessors to define the accessors.
Now you must be asking, but what is this enhance method doing?
As you probably noticed in mycompany.rb, the enhance module adds class methods to the Mycompany module. Here’s the enhance code:
# file: enhance.rb
module Enhance
def enhance(extension)
accessors = extension.send :class_variable_get, :@@accessors
name = extension.name.split("::").last.downcase
eigenclass = class << self; self; end
eigenclass.class_eval do
# Create a reference to the module
define_method name do # def settings
extension # Mycompany::Settings
end # end
# Enhance the module to include the attributes from the
# extension in the inspect method
define_method "inspect_with_#{name}" do
str = "\"\n\t#{name}:\n#{accessors_inspect_string(name, accessors)}\""
eval(str) << eval("inspect_without_#{name}")
end
end
eigenclass.send :alias_method, "inspect_without_#{name}", :inspect
eigenclass.send :alias_method, :inspect, "inspect_with_#{name}"
end
private
def accessors_inspect_string(name, accessors)
accessors.collect do |a|
"\t\t#{a}: #\{#{name}.#{a}\}\n"
end
end
end
Calling Mycompany.enhance(Mycompany::Settings) will do the following:
settings:
foo: [1,2,3,4]
bar: 'a nice value'
biz: {:a => "one", :b => "two"}
baz: 'ruby rocks'
As you can imagine, adding multiple modules and getting these methods added ‘for free’ and having the Mycompany.inspect show all the attributes for each of the modules is really nice.
Now all you have to do is grab this enhance code, throw it into your project and you can get the same functionality.
If you find a better way to do code what I’ve shown here, please let me know. I would appreciate it
Rails Cornerstone is a Rails starter app that uses the following technology soup:
I created this application while following through the lockdown-with-authlogic post to fix some documentation errors. Since I was creating this app anyway, why not share it?
This project is very young and has lots of room for improvement.
Any contributions to this project are very welcome.
Thanks,
andy
I’m extremely pleased to announce the release of Lockdown version 1.0. This release introduced the long awaited model level access functionality. You can now extend the access control of your controller methods to the model level. Nice!
True to Lockdown philosophy, you can do all this in the lib/lockdown/init.rb configuration file. Lockdown does not believe in scattering rules amongst all your controllers, but rather keep everything in a central location.
There are some new docs that include examples of both basic permissions and model level permissions.
Since the 0.9.x series, Lockdown has focused solely on authorization. To that extent, there is documentation detailing using Authlogic with Lockdown.
There’s also a new Lighthouse account to track issues.
Thanks for giving Lockdown a try and if you end up liking and using it, please vote for it on RubyTrends.
thanks,
andy
In preparation for the release of Lockdown 1.0 this week, I’m making some changes to stonean.com. Stay tuned.
You can still access all the old docs at old.stonean.com