Axehomeyg^2.0

DRY is a great concept. As one of philosophies upon which Rails is established, Do-Not-Repeat-Yourself is a mantra that is starting to become ever-pervasive in my coding as well as my daily work ethic. So, with that in mind, I’ve decided to NOT respond to the latest email inquiry about how to Encrypt your outgoing email messages from your Rails applications, and just write up a quick tutorial.

I use my GnuPG plugin mainly for e-commerce applications, where secure credit-card storage opens many API integration possibilities with the myriad of Merchant-processor options that are available. It works just as well for any data that necessitates two-way encryption. Lets say you whip up a quick formmail action in rails that emails you live credit card information or top-secret addresses, you’ll wanna provide the rails application with your public key (to properly encrypt the message). Here’s a super-brief overview on how you can do it.

Step 1: Install the plugin

ruby script/plugin install svn://ahgsoftware.com/gnupg/trunk

Step 2: Generate a mailer

ruby script/generate mailer test_mailer hello_world

Now we’ve got a TestMailer object with a default hello_world action. Before you move on, remember to add a recipient to the ‘recipient’ field in the model class (otherwise, our test will go nowhere!)

Step 3: Fire up the console

Lets run through the process of loading the gnupg plugin and encrypting a mailout from the console (you can apply this code in your controller at your own discretion).

1
2
3
4
5
6
7
8
9
10
11
12
13

## Load GnuPG and the public key of your choice
gnupg = GnuPG.new :recipient=>"Key Recipient whomever it may be"
gnupg.load_public_key File.read("/path/to/pubkey.asc")

## If its loaded, create the mail, encrypt, send
if gnupg.public_key_loaded?
        email = TestMailer::create_hello_world
        email.body = gnupg.encrypt(email.body)
        TestMailer::deliver(email)
end

## You probably don't need this, but, for a test, might as well
gnupg.drop_public_key

That should be about it. I’ve used several other methods (including capturing the output buffer and encrypting multi-part mail messages) in a few production sites, and I can’t settle on which method I prefer or where even to place the GnuPG instantiation. Thats what we love about Rails though, a million ways to do anything, and most of them just flow from the code like natural language. I love being a Rubyist. Better than a being a PHPist (masochist?).

Aight kiddies, in response to a few concerned emails, I’ve changed the auto-login in the PunBB Plugin for Rails to directly log the user in via cookies/db instead of AJAX.

Just to refresh you on how this plugin is used..

Install your Rails app

Install PunBB in the public dir (or even a subdir)

Generate the login code with the punbb path

./script/generate punbb_authentication account /forums

Email support@ahgsoftware.com when/if it blows up

JUST KIDDING, you’ll be fine

That command generates the skeleton files needed for login/logout. You MUST specify a relative path to PunBB installation (e.g. /forums). All other variables are pulled from the config.php file via a neat regex (including the db table prefix, cookie name, etc). You krafty little koder peers of mine, might wanna check out that little regex scanner, you can use it to pull variables out of all kinds of config files (Wordpress, Joomla, etc).

I really do agree with 99% of the principles that Rails and Dave’s pet project stand for, but, I am firmly in the camp that HATES writing login code. I’d say 2 out of 15 total large-scale Rails projects that I’ve designed have necessitated a highly targeted and advanced User engine. The rest have just needed a quick user db with a simple administration panel. Wordpress or PunBB work fantastically for this. Most of my wordpress + Rails integration code is buggy and not ready for primetime (and neither is my PunBB plugin, use at your own risk!), but, I do plan to release it soon. For now, happy posting!

After my last post about getting IPB SDK working for the latest IPB Release, I realized that, regardless of my dislike of forums as forums for online communication (PUN intended, shapap, double-entendre in yo face, mother!@#$%^), I have tons of code and projects that revolved around PHP Forums, and Rails backend applications.

In keeping with my New Years Resolution of sharing those tidbits that make my life easier, here is a PunBB SDK/Wrapper! It creates ALL of the models needed for the punbb’s database objects, as well as a VERY simple controller/views for auto-login capabilities. The projects that I’ve used this on are very niche-oriented and don’t lend themselves to extracting much generic code. I can say, that a simple PunBB installation plus this generator can you have you running a fairly pimptastic site in no time! If you like forums, that is ;)

To use it, install your rails app, install your punbb installation, then grab the plugin

./script/plugin install svn://ahgsoftware.com/punbb_sdk/trunk

When developing a Rails application that requires at least ‘autologin’ integration with a PHP forum application, I usually have to decide between several routes.

The direct DB/cookie method: You replicate the entire logic path of the forum system (PunBB/Vanilla EASY, IPB not so much).

By Proxy: You use Net::HTTP, or libcurl, to submit the login form, intercept the cookie, and set the user’s browser cookies. This sucks, because some software makes the submitted variables jump through hoops of its own creation (coughJoomla/cough)

AJAX: I am beginning to love this method, you just have your login form submit directly to your own software AND to the forum application via some nifty ajax. This PunBB SDK uses that particular technique

As far as forums go, PunBB is at the top of my list, because its developer friendly, and I just like the overall attitude that Rickard has over there! Consider donating to their cause if you end up using this plugin (the cause of bringing a SIMPLE forum to the world).

Our main file to edit..
ipbsdk/ipbsdk_class.inc.php

Step 1: New Bootstrap Method

Right before the inclusion of the main IPS file..

require_once ROOT_PATH   . "sources/ipsclass.php";

require_once ROOT_PATH   . "init.php";

Step 2: Instantiation

Previously, the basic instantiation of the ipbsdk libs could be done multiple times, e.g.

1
2
3
4
5
6
7
8
9
10
11

require_once "ipbsdk/ipbsdk_class.inc.php";
global $SDK;
$SDK =& new IPBSDK();
$SDK->create_forum(....);

.... some code....

require_once "ipbsdk/ipbsdk_class.inc.php";
global $SDK;
$SDK =& new IPBSDK();
$SDK->write_pm(....);

Fatal error: Call to a member function on a non-object in /home/tm/domains/public_html/forum/sources/handlers/han_parse_bbcode.php on line 380 

Step 3 (Optional): Corrupt Group Data

We had some corrupt group/user data that would throw up IPS DB Driver errors as well. If you’re having issues, do a grep for ‘IN(’ in the class file. if you see a statement like..

 g_id IN(".$info['mgroup_others'].")";

 g_id IN(".(strlen($info['mgroup_others']) ? $info['mgroup_others'] : "''").")"

I’m not a big fan of forum software in general. Its always big, bloated, ugly, and appeals to stats-whores of the worst kind (oh look, I have a shiny new counter for xxxx feature). Digging through forums for a fix like this drives me nuts! Hopefully, being in a blog makes this more easily accessible for those of us that enjoy blogs! Converge, oh IPB users, converge I say ;)