Archive for October, 2008

Merb OpenID Consumer Application Based on Merb-Auth

By Corey Donohoe | October 31st, 2008 at 5:10PM

We’ve been playing around with “OpenID”:http://openid.net/ this week so I figured it was worth spending some time to test “the latest Merb 1.0 release candidate”:http://merbist.com/2008/10/29/yet-another-rc-release-merb-10-rc3/.

Say hello to the “merb-openid-example”:http://github.com/atmos/merb-openid-example/tree/master app. It is a simple OpenID consumer application based on “merb-auth”:http://github.com/wycats/merb/tree/master/merb-auth. One of merb-auth’s “built in strategies is OpenID”:http://github.com/wycats/merb/tree/master/merb-auth/merb-auth-more/lib/merb-auth-more/strategies/basic/openid.rb#L10, getting things going is simply a matter of enabling the appropriate authentication strategies.

This application is intended to run against merb 0.9.12(1.0rc4). Here’s a quick checklist of what was involved in getting merb-auth working with the OpenID strategy.

  • sudo gem install merb
  • setup the merb-auth strategy
  • add the openid and signup named routes
  • modify the user model to handle OpenID attributes
  • add the ensure_authenticated before filter

To setup Merb I normally uninstall every trace of Merb that’s on my system. The 0.9.x branches tend to conflict if you have multiple Merb versions installed. I tend to do the following (note it uninstalls ALL Merb gems):

gem list merb | awk '{print $1}' | xargs sudo gem uninstall -aI

Then I just install the Merb meta package:

sudo gem install merb

Setting up the merb-auth strategy requires you to familiarize yourself with the merb/merb-auth/strategies.rb file. In a newly generated Merb application this file should setup a salted password base authentication scheme, we want to change it so it looks like the following:

Next we need to setup two named routes that the openid auth strategy will use in order to make the openid authentication happen. I created a separate controller(“authentication.rb”:http://github.com/atmos/merb-openid-example/tree/master/app/controllers/authentication.rb) to handle these requirements. All you really need to know about the two named routes, openid and signup, is that signup should not require authentication and the openid route should.

The default user.rb that you get from merb-gen will need a few minor adjustments to work with OpenID. First you’ll have to add a few attributes if you intend to cache them locally, and after that you’ll need to disable the password validations that are automatically enabled by the salted password strategy (even if you disabled it). My user.rb looks like this.

Once all that’s done you should be able to just throw the before filter into your “application.rb”:http://github.com/atmos/merb-openid-example/tree/master/app/controllers/application.rb and you’ll be ready to start using merb-auth with the OpenID strategy.

The example application works out of the box, just run the merb command. It also has specs which show off a bug that still exists in rc4 where controllers are not honoring :only/:exclude parameters that are passed to before filters.

I’d like for this to remain a simple app that we can keep as a community example. If this gets out of date please fork it and send me a pull request on GitHub.

Share this post:
  • email
  • Digg
  • del.icio.us
  • Reddit
  • Slashdot
  • StumbleUpon
  • Technorati
  • Twitter
  • Google Bookmarks
  • Facebook
  • LinkedIn
Popularity: unranked |
Rate this post: 1 Star2 Stars3 Stars4 Stars5 Stars
Loading ... Loading ...

Awesome Bundling in Merb 1.0 Final

By Yehuda Katz | October 31st, 2008 at 5:10PM

Since we released RC1, people have had persistent issues with bundling Merb gems. It turns out that the most common reason, by far, is conflicts between gems bundled in your app with gems available in your system.

When we first set up bundling, we thought it would be convenient to be able to bundle only some of the dependencies for your application. As it turns out, that blunts the reason for bundling in the first place: hassle-free, write-once-run-anywhere applications.

Through the course of four RCs, we’ve tried a number of things, none of which were really effective. The only full solution that guarantees that your bundled app runs correctly on development boxes and production boxes is to bundle everything in your app, and completely ignore your system gem repository.

While it is easy enough to mix and match, the number of reports of failure, combined with failures by the core team itself, leads us to believe that this is a bad idea, especially given some of the current assumptions made by Rubygems (which causes it to activate the latest version of a gem, which might conflict with a different dependency).

A simple example of a failure:

merb-haml 0.9.12 relies on merb-core 0.9.12

Imagine you have merb-core 0.9.13 installed in your system

running the merb binary loads the latest merb from all your repositories.

this will load merb-core 0.9.13

a dependency on merb-haml 0.9.12 will try to activate merb-core 0.9.12, which will conflict with the already loaded 0.9.13.

This is just one example of many issues that people had. The solution is to rely entirely on bundled gems, and remove system gems from bundled binaries.

The side-effect is that you will need to bundle gems like mongrel, rake, etc. But it’s clear to me that even bundling mongrel and rake is a good idea, as different versions of mongrel or rake can have subtle differences that lead to infuriating bugs. I personally have experienced some of these bugs in my day, and being able to package up an entire working app would have been a godsend!

RC5, which should be the final release before 1.0 final is released at RubyConf, will include bundle-everything by default, as well as more support for webrat, JRuby, and Windows.

Share this post:
  • email
  • Digg
  • del.icio.us
  • Reddit
  • Slashdot
  • StumbleUpon
  • Technorati
  • Twitter
  • Google Bookmarks
  • Facebook
  • LinkedIn
Popularity: unranked |
Rate this post: 1 Star2 Stars3 Stars4 Stars5 Stars
Loading ... Loading ...

MerbCamp Keynotes and Sessions

By Leah Silber | October 30th, 2008 at 5:10PM

For those of you who couldn’t make it down to San Diego for MerbCamp, and those of you who didn’t catch it streaming live on the web, conference organizers have posted the sessions.

Be sure to take a peak at keynotes from Engine Yard’s Ezra Zygmuntowicz and Yehuda Katz to learn about the past and future of Merb, as well as the various other tech topics.

MerbCamp was a smashing success, and the future’s looking incredibly bright; now’s the right time to dig in!

Share this post:
  • email
  • Digg
  • del.icio.us
  • Reddit
  • Slashdot
  • StumbleUpon
  • Technorati
  • Twitter
  • Google Bookmarks
  • Facebook
  • LinkedIn
Popularity: unranked |
Rate this post: 1 Star2 Stars3 Stars4 Stars5 Stars
Loading ... Loading ...

Merb 1.0 RC3 Released!

By Yehuda Katz | October 29th, 2008 at 5:10PM

We released Merb 1.0 RC3 today, inching a bit closer to a 1.0 final, which we intend to release at RubyConf. RC3 is mostly bugfixes, but there are some items of note:

  • Since we intend to support webrat as a primary mode of testing in 1.0 final, we’ve restructured the testing helpers to make that possible. No testing API changes at this time.
  • In 1.0 final, get/post/put/delete will be aliases for request(). At this time, they’re still aliased to the old pre-1.0 request()-helper. To help ease the transition, we will probably provide a use_legacy_request_helper! method.
  • There was a bug in request testing that preventing sessions from persisting for more than 2 requests. We have implemented a cookie jar, so sessions now persist properly (basically, we emulate a real browser).
  • As a result, you can now pass a :jar parameter to request(), which will allow you to test multiple sessions in the same test. If you specify no :jar parameter, all request() operations will use a :default jar. The syntax is request("/foo", :jar => :my_jar). request("/foo") is the same as request("/foo", :jar => :default).
  • merb-action-args works with ParseTree 2.x and 3.x.
  • merb-auth had a few bugs around redirecting back and retrying failed logins that were resolved.
  • The final, good API for dependency is solidified. A few things that you can do now: dependency “parse_tree”, :require_as => “ParseTree” { # do stuff after the gem is loaded }. You can also pass :immediate => true to have the gem load immediately, instead of being deferred until the framework is set up (the default).
  • We should now fully support Windows.
  • Seamless JRuby support is coming via Glassfish. RC3 has some fixes to make it simpler for Glassfish to hook in.

Good night and good luck!

Share this post:
  • email
  • Digg
  • del.icio.us
  • Reddit
  • Slashdot
  • StumbleUpon
  • Technorati
  • Twitter
  • Google Bookmarks
  • Facebook
  • LinkedIn
Popularity: unranked |
Rate this post: 1 Star2 Stars3 Stars4 Stars5 Stars
Loading ... Loading ...

Rubinius CPP Work Branch Change

By Evan Phoenix | October 28th, 2008 at 5:10PM

I’m super happy to announce that we’ve gotten the C++ branch stable enough that we’re making it the default branch. This means that those of you with existing clones are going to likely do a little work to get them sane though.

Here is what was done:

  • The old master branch was renamed shotgun.
  • The cpp branch was copied to the name master.
  • The cpp branch was then deleted.

Anyone that has up to now been working on the cpp branch has a couple of options.

Delete your clone and re-clone. This is the easiest. The default checkout will be code in the cpp branch and you’re off and going.

Fix up your current repo. I did this by doing the following commands:

** git checkout master ** git reset --hard origin/master ** git branch -d cpp

This will get your local master branch repointed and properly checked out. In addition, the old cpp local branch can be deleted.

Hopefully no one experiences much pain due to this change. It’s been a long time coming and I’m really excited.

If you do run into problems, post a comment or stop on by IRC and we’ll work it out for you.

Share this post:
  • email
  • Digg
  • del.icio.us
  • Reddit
  • Slashdot
  • StumbleUpon
  • Technorati
  • Twitter
  • Google Bookmarks
  • Facebook
  • LinkedIn
Popularity: unranked |
Rate this post: 1 Star2 Stars3 Stars4 Stars5 Stars
Loading ... Loading ...