This is the first of a series of posts with small tips and tricks of ExtJS that will also address its integration with Ruby on Rails.

In this release we are going to create a ComboBox that loads its items from a remote location (potentially a rails REST endpoint).

I wanted to create this series when I started using ExtJS so it could be used as a step-by-step howto of ExtJS and rails, but as sometimes happens, I got carried away with the coding side of things leaving the post writing abandoned :(. That is the main reason why some core concepts of ExtJS development are not included here. The project site, documentation and samples can help with that. Here we are dealing with the real stuff, so lets get it on.

First the code: extjs-comboxml.tar.bz2. I have a local apache for debuging purposes and I uncompressed the ExtJS package in /var/www/ext-2.2/, then I created a test folder inside it. This code should work fine if you uncompress its contents in the test folder. If you have a different environment, adjust the locations of the script tags in the header of combo.html.

This is how it should look like:

So with ExtJS there are two ways of loading combo items from a remote location, it is a bit confusing because these two are called local and remote modes. The difference is that in local mode, the combo is relying on someone else to grab the information and in remote mode the combo itself will make the Ajax call.

No matter what mode we choose, we will need a data store for our items. Here is the code used in the example:

var categories = new Ext.data.Store({
        url: 'categories.xml',
        autoLoad: true, // required for the combo that does not use Ajax
        reader: new Ext.data.XmlReader(
                { record: 'category', id: 'id'},
                [ { name: 'name', type: 'string' } ]
              ),
        listeners: {
          load: function(records, options) {
            console.log( 'loaded ' + records.totalLength + ' records');
          },
          loadexception: function(proxy, options, response, error) {
            console.log('error loading records from server:');
            console.log("\tfile: "+error.fileName);
            console.log("\tline: "+error.lineNumber);
          }
        }
      });

The listeners in the code above are just for debuging purposes and can be removed safely. The only interesting bit is the autoLoad option, but we will come back to that later. For now it is enough to say that the Store above will read an XML document with this structure:

<?xml version="1.0" encoding="UTF-8"?>
<categories type="array">
<category>
<id type="integer">1</id>
<name>default category</name>
</category>
<category>
<id type="integer">2</id>
<name>security risk</name>
</category>
</categories>


The autoLoad config options determines if the data store will try to load the values from the provided url upon creation or if it will be necessary to call the load(). This is useful when we are working in local mode, let’s see the code for the first combo:

var comboLocal = new Ext.form.ComboBox({
  fieldLabel: 'Select a category',
  store: categories,
  mode: 'local',
  displayField: 'name',
  selectOnFocus: true,
  emptyText: 'No Ajax in the combo...'
});

Above we specified local this means that options for this combo will be loaded from the categories store. The data store is expected to be populated already, this can be done either by specifying the autoLoad option as described above or by calling the load().

If you rather have you combo performing the Ajax request, then the code you need to use is:

var comboRemote = new Ext.form.ComboBox({
  fieldLabel: 'Select a category',
  store: categories,
  displayField: 'name',
  triggerAction: 'all',
  selectOnFocus: true,
  emptyText: 'Options loaded using Ajax...'
});

There is no need to include mode: 'remote' because is the default behaviour, here the trick is to include the triggerAction: 'all', otherwise the Ajax request will never be executed.

So that was it, short and simple, stay tuned for the next one

Key note – David Heinemeier Hansson

David is the creator of the Rails framework and obviously a bit of a celebrity. Interestingly enough I get the idea that he is not the highest contributor to the Rails code base – I appears to be Jeremy Kemper which is his colleague at 37signals (the company behind Ruby on Rails).

David delivered the keynote on Wednesday morning. The key note was on legacy code. Initially I thought – “What a boring subject” and then later I caught myself thinking – “Now you are talking a load of nonsense” and two thirds into it I was happy to admit – “Hey, you really have been thinking about this a lot”.

Maybe it is a sentiment that only or mostly developers can associate with but very often you look back onto code and refer to it very cynically as “Legacy” code. He’s argument was that “legacy” code is a result of progress in environment and personal growth (Sounds like a psychiatry session – I know – It did get better). He carried on by making suggestions as to how legacy code should be dealt with and then showed a few examples in Rails. Some thoughts suggestion:

• The worst mistake that a company can make is to decide to simply rewrite legacy code on impulse.
• Legacy code should be put through iterations to improve it – They have a rule in their company that you should always leave code in a better state than what you found it in.
• Be careful of judging code as legacy due to a change in personal taste.
• Keep in mind that the code you write today will become legacy – face the facts.

Rails developers make a big deal out of DRY (Do Not Repeat Yourself). It implies that functionality should not unnecessarily be repeated in your code. The rule of thumb is that if you have found yourself copy and pasting for the 3rd time then its time to DRY-up your code. His point was that very DRY code makes it sometimes difficult to extend the code and this can make the improvement of legacy code difficult. A bit of repetition in your code is thus not a bad thing.

A thought that came to my mind was – “How should the IT security consultant look at (or judge) legacy code. Firstly, code tested 2 years ago and stamped as secure might not be secure anymore (new techniques, new vulnerabilities). What, or rather, is there a recommendation on re-testing or frequency on re-testing? Secondly, what is the recommendation on finding holes in legacy code? As mentioned rewriting code is not always (very seldom) the viable solution. How should a client maintain a legacy code base from a security point of view?

When to tell your kids about presentation caching – Matthew Deiters

You have all heard about the 20/80 rule. You wear 20% of your clothes 80% of the time. 20% of the world’s population own 80% of the wealth. And so it turns out that 20% of an application resources are being requested 80% of the time and 80% of the http request time are being spent on the wire - thus the argument for caching and a few other tricks to speed things up.

From my notes and memory the following are the major points:

• Rails supports ETags. The application responds with an ETag in the HTTP header when a request has been made for specific resource. The browser caches the ETag and the contents. When requesting the same resource in future it sends the ETag back the server. This allows the server to check if anything on the resource has changed since the last request associated with the ETag. If it is still the same it responds with “not modified” (that take is quicker to process and send) and the browser just displays the old version.
• Rails also supports static asset time stamping. This allows browser caching to be done based on a timestamp in the static asset request string.
• Rails has setting “perform_caching true” that combines .js files into a single file and makes the download time quicker.
• You can also configure your web server to gzip certain assets.
• Because most web browsers only allows for 2 connections to run simultaneously to a single server there are advantages in distributing you static assets across multiple servers.

All of the above have their little tricks and limitations that are worth investigating on implementation.

Intellectual Scalability - Solving a Large Problem With Multiple Cooperating Rails Apps - Frederick Cheung (Texperts), Paul Butcher (Texperts)

This was one of two presentations on serving multiple applications through a single front-end. In this case the developers designed a JavaScript heavy UI framework that presents the multiple allocations through a single front-end interface. Each application is presented in the front-end through what they call a widget. The power of the framework is in the code and a full (even partial) understanding requires a demonstration. I am making contact with the guy to see if they are willing to share the code. He did mention that they will release it publicly if there is interest.

Slides at http://assets.en.oreilly.com/1/event/13/Intellectual Scalability - Solving a Large Problem With Multiple Cooperating Rails Apps Presentation.ppt

Offline Rails Applications with Google Gears and Adobe AIR - Till Vollmer (MindMeister/Codemart GmbH)

(My notes are becoming increasingly less and I am not going to write a lot about this)
This was more a Google Gears talk than a Rails talk. I have never bothered to actually have a look at Google Gears but this guy had a good talk on how they implemented it from an architectural point of view.

You basically design your web application to be able to operate when you are offline. You have a local SQLite database that you use when going offline and this is synchronised back to the server when you go back online. There is obviously at lot to manage:

• Detect on-line/off-line status
• Clashes when local db and server are not compatible on synchronisation.

My biggest thought during this talk was the amount of havoc that you can cause when the contents of the SQLite db is not validated before the automated synchronisation to the server db takes place. I think it is worth looking at.

Security on Rails - Jonathan Weiss (Peritor GmbH)

This is a German chap that is (amongst others) an IT security consultant. It had nothing too new about the web application security stuff – XSS, SQL injection and XSRF. He discussed in each case how this should be prevented in Rails. It was reassuring to note that our Rails development is up to his standards.

The interesting part of his talk was on how to finger print a Rails application. I will leave you with his slides to have a look at that: http://assets.en.oreilly.com/1/event/13/Security%20on%20Rails%20Presentation.pdf

Few other important things:

• Rails 2 and greater by default uses the cookie to store the session state (you can change this). This cookie is just Base64 encoded and should thus not be used to store sensitive data. A hash of the data and a secret key (you can configure this) is also stored in the cookie and this is used to check the authenticity of a cookie when send back to the server.
• Some plugins to look at: saveERB, XSS shield and tidy_library.
• Often times (and this is the case in some trusted plugins) the user session is not reset on logout – check for this.
• Rails 2.1 and smaller - Despite the parameterise ability of the ActiveRecord class the limit and offset parameters in the find method where not typecased. This leaves the door open for SQL injections. This was fixed but the MySQL adapter still appears vulnerable.
• Mass assignment (user = User.create(params) can allow for great havoc if the malicious user send extra parameters in the post request that relates for example to the user level. Use attr_protected and attr_accessible
• DOS attacks can be launched against file upload functionalities by sending very big files. Use the web server to handle file uploads or use the web server direct the request to another application to deal with file uploads.

I spoke to the guy afterwards to get an idea on what his opinion is on Rails’ maturity in terms of security. I mentioned a certain ‘trust’ in PHP due to the time it has had to mature. His reply was that Rails has been developed from a much better security perspective than Rails and is more mature to his standards.

Functional Testing Lessons Learned - Jay Fields (DRW Trading)

Jay mainly looked at the following three points:

• The place and role of writing tests
• Comparing different test suites
• Different types of tests

He stressed the importance of testing and the purpose thereof. It is especially applicable in environments where code improvements, refactoring and growth is a constant occurrence. Testing plays a central role in making sure that the result of these actions does not break the code and that breaks in the code can be indentified as soon as possible. From a certain perspective testing is a way to document the functionality and purpose of code.

I picked up on the following statements two statements that I felt creates a great perspective:

• Testing code is just as important as application code.
• Tests should be created that provides a positive return on investment

An important point is that testing does not replace the need for manual testing – it does not replace a QA team or a testing team. Automated tests might test the intended functionality but the perspective from a person that is not involved in the development is needed.

The Rails framework encourages two testing approaches – Unit testing and Functional testing. Unit testing has to do with testing classes in isolation by simulating the functionality of dependencies to the outside of the class. Functional testing has to do with testing functionalities that is presented by the integration of different units. Have a look at his blog entry http://blog.jayfields.com/2007/09/rails-how-we-test.html for more thoughts on this.

Other test types include integration tests, smoke tests, use case tests and automated browsers tests. I’ll leave it up to the reader to investigate these further.

Three testing suites were discussed:

• RSpec
• test/unit
• Selenium

The factors to take into account when choosing a test suite are:

• Ease and simplicity of implementation
• Flexibility to support the different types of tests
• Ability to present the test code to non-technical project members – QA team, senior management etc.

With these factors taken into account RSpec was considered the best option with test/unit in second and Selenium very unfavourable.

To bring the security aspect into this topic – I wonder if there is a case for security consultants to assist client developers in writing test cases for there applications that will also assist the developers in keeping a security perspective on there code.

Small Things, Loosely Joined and Written Fast - Justin Gehtland (Relevance, Inc.)

I think this was the best talk that I attended. Unfortunately for the reader of this article it was really one of those talks that you have had to been there. The slides was mainly a few photos to support his comical metaphors, my notes practically non-existent and an excellent demo that you’ll have to go though the code in your own time.

The main argument was – Big problems do not require big solutions bundled in one big fat application. Proper solutions consist of a number of small independent applications that can be developed, configured, tested and managed independently. These smaller solutions then be integrated together to tackle the big problem.

To use his terms – This approach will improve your productivity by improving:

• Testability
• Compose-ability
• Security
• Scalability

And, to quote him “Make small things, join them loosely, write them fast, scale them independently”

He had a wonderful demonstration on three Rails applications that are delivered through a single entry point using a central authentication point and a message queue for some of the communication between the independent parts.

Have a look at his blog entry - http://blog.thinkrelevance.com/2008/9/3/small-things-loosely-joined-written-fast

From Rails Security to Application Security - Carsten Bormann (Universität Bremen, TZI), Steffen Bartsch (TZI, Universität Bremen)

I am not going to attempt to cover this talk in too much depth. They touched on the topics of:

• Data confidentiality, integrity and authentication
• Threat matrixes
• Attack trees

There is loads of information out there on this that makes covering the topics in this write-up irrelevant.

The one thing to take note of in this talk is an authorisation plugin that Steffen developed. It offers a very clean way to manage authorisation of access for different level users to all the levels of the MVC architecture. Despite offering great flexibility and full management of authorisation it has very clean way of presenting the authorisation rules to the developer, making the auditing of the rules a very easy process.

See the presentation slides on Steffen’s blog - http://steffenbartsch.com/blog/2008/09/from-rails-security-to-application-security/

Writing resources_controller: Discovering REST Patterns in Rails - Ian White (Argument from Design)

REST is getting great attention in the Rails community, in fact I will dare to say - I think the RAILS community are leaders in the RESTful approach. If I may quote Ralf Wirdemann and Thomas Baustert from RESTful Rails Development (http://media.quilime.com/files/pdf/restful_rails_en.pdf) “REST describes an architecture paradigm for web applications that request and manipulate web resources using the standard HTTP methods GET, POST, PUT and DELETE.”. In other words - A resource (data object/model) is mapped to a URL and is managed by the standard HTTP methods.

Also and as mention earlier, Ruby programmers support DRY (Don’t Repeat Yourself) code.

Ian developed a plugin (seems like if you want to talk at Rails conference then you have to write a plugin) that provides a central Resource Controller that can manage the REST functionalities of all your other controllers. For a very thorough explanation of this see the blog - http://blog.ardes.com/resources_controller

On a recent project I was challenged with the task to create a Windows installer for Dradis, an application that I have been contributing to. After a bit of research it seemed like our answer was in using NSIS (Nullsoft Scriptable Install System) to assist us in this task.

NSIS in an open source platform for creating Windows installers. It has its own scripting language that you program all your installer logic in and then compiles to a Windows installer executable.

In this series of articles I will introduce you to:

• HM NIS IDE and it’s wizard (Part 1)
• Customising the wizard code (Part 2)
• Challenges with installing to user accounts without administrator rights (Part 3)

The goal

The goal is to create an installer for Acme application. I will customise the installer code as we go along but the main components for installation are:

• Copying our acme_app.rb file to a location on the target machine
• Check if Ruby is installed on the target machine. Install it if it is not the case
• Our application uses SQLite. We need to check if the required files are installed on the target machine and install it if it is not the case.

On the NSIS website you will find plenty of examples and tutorials to get you started. I am however going to jump in a little further ahead and tell you about HM NIS Edit. HM NIS Edit is an Editor/IDE to create your NSIS installers in. I came across it after a little web search and it proved itself to be a very handy tool to use on top of NSIS.

To create a nice installer with options, components, license etc. there is a lot of code that is generic and can fit into a framework followed by a bit of customisation. HM NSIS Edit assists you in this task by providing a wizard. It is from the wizard I’ll start my explanation.

The HM NIS Edit wizard

In the HM NSIS Edit application you have the typical wand and stars icon to start the wizard with. The first couple of screens is pretty straight forward and asks you a number of things about your app. The fun starts at the “Application Files” screen. It is here where you specify the different components (groups) for your application and the files associated.

The application components

For the purpose of my Acme application I create the following components: Ruby, SQLite and Acme app.

1. Ruby

For the Ruby component I do not see the point of wrapping the Ruby one click installer file in our Acme app installer. I decided I’ll make Ruby an install component but picking it for installation will download the Ruby one click installer and execute it. I create the Ruby group in the wizard and do not pick any files, we will add the meat of the download and install later.

2. SQLite

Now we get to the SQLite component. So we create the SQLite group in our wizard. This group consists of two parts: the dll and the Ruby gem.

sqlite3.dll

The dll is easy; it is one file that we need to copy to the system32 folder. So to the right hand side of the wizard window we click the add file icon, browse for the dll that we have ready on our machine and select the destination directory. The destination directory is the directory on the target machine where the file will be copied to. We need it in the system32 folder so we choose $SYSDIR from the drop down box.

SQLite gem

The most common way to install Ruby gem is with the command line command:

gem install GEMNAME --remote

In older GEM versions you could not however state the platform that you are installing the gem to from the command line, it is an option that is given to you just after running the “gem install GEMNAME –remote” command.

The above will not work very nice with our installer as we want the installer to deal with this and not require input from the user on gem installation. However you can use --local instead of --remote and just specify the local file from which the gem should be installed. In this case the installation does not require from you to supply the platform.

So I downloaded the sqlite3-ruby-1.2.1-mswin32.gem file from RubyForge and added it to the files to be installed as we did with the dll, however in this case just copy it to the $INSTDIR. We will add the meat to run the gem install GEMNAME --remote command later.

3. Acme app

Now we get to our acme_app.rb source file. As for the previous components we create a new component group called Acme app. After the component has been created be associate ou acme_app.rb source file with it as we did with the SQLite files. We set the $INSTDIR to be our target folder on the target machine.

Note - If your application code is more than one file you can select a directory tree to be associated with the component instead of just a single file at a time.

At this point you component list should look something similar to what you see in the figure below.

Completing the rest of the wizard is quite straight forward. Remember that if you want to execute an executable (for instance if you want to call notepad to open a file at the end of installation) you have to give the full path to the executable (for example “$SYSDIR\notepad.exe some-text-file”).

Finishing the wizard will give you a code file that you can compile in HM NIS Edit and it will supply you with the install executable.

That’s it for now

- but there is more

I have left a few things out that the wizard could not do to customise our installer. I will have to do some tweaking to the code for this purpose. This will be covered in Part 2.

Things that will be covered include:

• remove the need of a login
• the use of an activation email, the application will require it’s users to activate their accounts upong sign up.
• howto get rid of the remember me functionality (just in case you don’t need it).
• howto strengthen a bit the default security of the framework.

If you started a blank application with the first series, you can seamlessly continue with the instructions of this post from were we left it on the first part of this howto. Otherwise, you can grab the code of restauthz application, a small rails application that I have created and that can be used as a proof of concept out of the box. Let’s get this thing going.

Before we start, just a gentle reminder, be sure to include AuthenticationSystem in ApplicationController:-

include AuthenticatedSystem
# Filter the password and password_confirmation
# fields from the log files
filter_parameter_logging :password, :password_confirmation

no login, just email

The first step is to remove the login field from the User migration, this will ensure that we do not use it in the code

We also need to remove the revelant validatiors in the User model. In addition to this, some changes to the authenticate are required:-

def self.authenticate(email, password)
  u = find_in_state :first, :active, :conditions => {:email => email} # need to get the salt
  u && u.authenticated?(password) ? u : nil
end

We also need to update the call to this function in the SessionsController (line 9):-

self.current_user = User.authenticate(params[:email], params[:password])

And that’s it. It wasn’t that difficult, was it?

email activation

The only thing that we are going to tweak is the templates provided by restful_authentication.

In ./app/model/user_mailer.rb you can modify the email headers such as the subject and from address. The body of the emails is located under ./app/views/user_mailer/.

The system sends to the users two emails, one after signup (this one contains the activation link) and one once the user has activated the account.

By default the templates contain the newly created user’s password, which is something that is controversial to say the least. I decided to get rid of the password, but this depends on your needs more than anything else.

remember me

Another feature that is application dependant is the use of a remember me functionality: a check box in the login form that would cause the application to store an authentication token in the user’s cookie so the next time the user visits the site does not have to authenticate again. I decided to nail down this example to the very basics, so no remember me functionality in this instance.

This can be accomplished by making some modifications to the AuthenticatedSystem#current_user function:

def current_user
  #@current_user ||= (login_from_session || login_from_basic_auth || login_from_cookie) unless @current_user == false
  # only session based login for the time being
  @current_user ||= login_from_session unless @current_user == false
end

In the previous code, the @current_user variable is only set through the session, no HTTP Basic (careful if you have ActiveResource clients) or remember me cookie.

security tweaks

password policy
A strong password policy is enforced by means of rails’ validate_format_of. In the User model:-

class User  /^(?=.*\d)(?=.*([a-z]|[A-Z]))([\x20-\x7E]){8,40}$/,
    :message => 'chosen is not complex enough!'
  validates_format_of :email, 
    :with => /^([a-zA-Z0-9_'+*$%\^&!\.\-])+\@(([a-zA-Z0-9\-])+\.)+([a-zA-Z0-9:]{2,4})+$/, 
    :message => 'field does not look like an email.'
  [...]
end

In the code above we match both the email and the password against regular expressions to verify the syntax.

The regular expression for the password was taken from Using Regular Expression in Ruby on Rails — Regexp for Password Validation:-

Lets say we have to implement the following validations to validate a password:

• Password should contain atleast one integer.
• Password should contain atleast one alphabet(either in downcase or upcase).
• Password can have special characters from 20 to 7E ascii values.
• Password should be minimum of 8 and maximum of 40 cahracters long.

password with salt & pepper

Storing a password in plaintext may result in a system compromise (OWASP).

Conveniently enough, restful_authentication uses a hash function to protect user passwords: the SHA-1. It also uses a salt. Here are however two tricks to increase the security of the default setup:

First we are going to hash the password with salt and pepper. The salt is specific to each user and will be stored in the database along with the user’s hashed password. If an attacker can compromise the database, they would have access to both the salt and the hash and brute force attacks could be mounted by using custom scripts or rainbow tables. The trick here is to add a second component, the pepper. The pepper is another random string that will be used to add some extra entropy to the password hashing process. In our implementation the same pepper will be used for all the users and it will be stored in the code. If an attacker gains access to the database, no successful brute force attack can be mounted without knowing the pepper. If an attacker gains access to both the database and the code…

You can easily generate your pepper using something like this in code in irb:-

require 'digest/sha2'
s = ''
chars = ("a".."z").to_a + ("A".."Z").to_a + ("0".."9").to_a
1.upto(4) { |i| s << chars[rand(chars.size-1)] }
s += Time.now.to_s
1.upto(4) { |i| s << chars[rand(chars.size-1)] }
Digest::SHA256.hexdigest(s)
=> “9fa4c6519da9d2121bc42be1d63813f591bba8ece5b753e6ceefed00f15e5342″

The random character generation was taken from generate a random password.

And second, we can upgrade the system to use the more secure SHA-256 both for the hashed password and the salt. We will keep SHA-1 for the sake of variety

In order to accomplish this, some modifications are needed to the ./app/model/user.rb. First we need to include the required files:-

# sha1 for activation code. sha2 for the passwords
require 'digest/sha1'
require 'digest/sha2'

Then the password encryption function:-

# We are using both, salt and peper to hash the
# password. The new password hash uses
# SHA2.hexdigest
def self.encrypt(password, salt)
  pepper = '9fa4c6519da9d2121bc42be1d63813f591bba8ece5b753e6ceefed00f15e5342'
  Digest::SHA256.hexdigest("--#{salt}--#{password}--#{pepper}--")
end

And the salt generation function:-

# The salt is also created using SHA256
def encrypt_password
  return if password.blank?
  self.salt = Digest::SHA256.hexdigest("--#{Time.now.to_s}--#{email}--") if new_record?
  self.crypted_password = encrypt(password)
end

In order to store the new hash, we need to increase the length of the salt and crypted password fields in the database. This can be done in the migrations file:-

t.column :crypted_password, :string, :limit => 64
t.column :salt, :string, :limit => 64

summary

So that was it, the restauthz application should cover all the needs to get you started with restful_authentication. There is still room for improvement, think the I forgot my password functionality, or a facility for your users to change their passwords, but that is definitely another story

• A no non-sense authentication: just email and password. No bells, no wistles.
• The system should send an activation email after the user signs up.

Let’s explore the alternatives

The haystack…

As stated elsewhere acts_as_authenticated is a neat solution that just gets out of the way. It is nice and easy to integrate. However, it is a bit too simple. loginsugar seemed to be a suitable alternative with ActionMailer integration out of the box.

I decided to give it a try. It has a good documentation that walks you through the process of integrating it in your app, but it did not seem to be a goal too easy to accomplish

What I finally decided was to take specific bits and pieces of the loginsugar and integrate them with plain old acts_as_authenticated.

First step of the process: I created a brand new project and installed the acts_as_authenticated plugin. It was surprising to find the following line in the README file:

DEPRECATED: Use restful_authentication instead. Or, ask me for commit rights if you wish to maintain this plugin.

… So I was right back at the begining, everybody recommended acts_as_authenticated but acts_as_authenticated recommended restuful_authentication… I thought that if acts_as_authenticated is recommending something, it has to be good And I decided to give restuful_authentication a try.

… and the needle

Lets get out hands dirty, create a new project and install the plugin with:-

<br />
$ ./script/plugin  install http://svn.techno-weenie.net/projects/plugins/restful_authentication/<br />

It turns out that the plugin has the activation email functionality out of the box, the only requirement is the use of a few command line options:-

<br />
$ ./script/generate authenticated<br />
Usage: ./script/generate authenticated ModelName [ControllerName]</p>
<p>Options:<br />
        --skip-migration             Don't generate a migration file for this model<br />
        --include-activation         Generate signup 'activation code' confirmation via email<br />
        --stateful                   Use acts_as_state_machine.  Assumes --include-activation<br />
        --rspec                      Force rspec mode (checks for RAILS_ROOT/spec by default)<br />

We need to include the --include-activation for the email, which in turn requires --stateful. The idea is that you are going to associate a small state machine to each user. From signed up, to pending; after the user actives the account, the status changes to active, etc.

It is quite neat. However it has the drawback that requires another plugin: acts_as_state_machine, but more on that later.

In order to generate your user model and your session controller, you need to issue the following:-

<br />
$ ./script/generate authenticated user sessions \<br />
                --include-activation \<br />
                --stateful<br />

This generates the required files. It also creates the routes to the user and session resources in ./conf/routes.rb:-

<br />
#[...]<br />
map.resources :users<br />
map.resource :session<br />
#[...]<br />

However, as the README file suggests we need to modify the :users resource as follows:-

<br />
map.resources :users, :member => { :suspend => :put, :unsuspend => :put, :purge => :delete }<br />

An extra line in ./config/environment.rb is also required (make sure you include it inside the Rails::Initializer.run block):-

<br />
config.active_record.observers = :user_observer<br />

The next step is to install the acts_as_state_machine plugin and to run rake db:migrate to initialize the database:-

<br />
$ ./script/plugin install http://elitists.textdriven.com/svn/plugins/acts_as_state_machine/trunk<br />
[...]<br />
$ rake db:migrate<br />

Now you are set. Feel free to run rake that all the tests will pass without warnings. Only one tip from the restful_authentication railscast: to get short urls for signup, login and logout add the following to your ./config/routes.rb:

<br />
map.signup '/signup', :controller => 'users', :action => 'new'<br />
map.connect '/activate/:activation_code', :controller => 'users', :action => 'activate'<br />
map.login '/login', :controller => 'sessions', :action => 'new'<br />
map.logout '/logout', :controller => 'sessions', :action => 'destroy'<br />

Fine tune

So here we are all set with the authentication framework in place. From here on it is about customization and fine tunning. Note that the activation email feature requires an either an email server running on the same box or some ActionMailer configuration in order for it to work.

In the second part of this series we will go back to our basic need: get rid of the login field (we only need an email). This and other tweaks will be demonstrated in a tiny app that fully implements the concepts explained here. Part 2 is here! restful_authentication howto, step-by-step (part 2).

Since this is not an easy choice we can mitigate the impact of making the decision upfront by doing some interface based design.

I am going to use dradis as an example, but the code and philosophy are project independent.

First we put an interface together with all the methods that our configuration handling implementation will require. The ParserInterface should be implemented by all the different configuration parsers (xml, yaml, etc.). The idea is that the application and it’s modules will only access methods defined in this interface:-

module ParserInterface
  # Given an option name (as a symbol) this function
  # retrieves the value stored in the configuration
  # file for it.
  def get_option(key)
    raise 'unimplemented!'
  end

  # Store the given +value+ under the +key+ in the config
  # provider.
  def put_option(key, value)
    raise 'unimplemented!'
  end

  # Store the configuration settings in the backend
  # provider.
  def save
    raise 'unimplemented!'
  end
end

We have defined methods for storing, retrieving and saving the configuration. It is true that the save may not be necessary if the implementation stores information in, for example, a database, however the advantage of having this method is that we are allowing our implementation to have a cached copy of the configuration settings in memory and only write them to the backend once the save method is called.

Ruby does not have native support for interfaces, this is why the ParserInterface is a ruby module and only defines methods that raise exceptions. We will include this module in our implementations, in doing so, the implementing classes will respond to the get_option, put_option and save methods straight away, but if the application calls any of them an exception will be thrown unless a valid implementation has been provided.

For dradis we are using an XML file as the backend configuration storage. The XMLParser class. The full contents on the file can be accessed through the subversion repository in: /dradis/client/branches/orko2.0-etd/core/config.rb. I have included below the interesting bits and pieces:-

# to handle the XML part of it
require 'rexml/document'

class XMLParser
  # include the interface
  include ParserInterface

#[...]

# copy from the file into a hash in memory (initialize)
    @src = REXML::Document.new(File.new(@file))
    @options = {}
    @src.elements.each('dradis/option') do |element|
      @options[element.attributes['name'].to_sym] = element.attributes['value']
    end

# get_option and put_option are straightforward

# [...]

  def save
    # if no change has been made to the configuration, do
    # not bother overwriting the file
    return unless @modified
    @options.each do |name, value|
      elements = @src.get_elements("dradis/option[@name='#{name}']")
      if (elements.size.zero?)
        # a new element needs to be created
        @src.root.add_element( 'option', { 'name' => name, 'value' => value})
      else
        # update the existing element
        elements.first.attributes['value'] = value
      end
    end

    # use the Pretty formater to indent the file :)
    fmt = REXML::Formatters::Pretty.new(2)
    fmt.write( @src, File.new(@file, 'w') )
  end

# [...]
end # class

The only performance trick that I am using is the @modified variable that flags whether a change has been made to the configuration settings during the current session or not. If no change was made, there is no need to dump the @options hash back into the file.

$ ./script/server

Open a browser and access: http://localhost:3000/.

The database provided contains some default categories and tasks. To remove them just go to the application directory and execute the following:

$ ./script/console
>> Task.find(:all).each do |task| task.destroy end
>> Category.find(:all).each do |category| category.destroy end

This will clear the database (note that you can also accomplish the same using the rake db:migrate command, however, that is another story ). Then you need to add your own categories. Beware that the CSS file is prepared for up to 4 categories. Support for more could be easily added and is left as an exercise :D. to add you own categories:

Category.add

Please note, that no special security measures have been implemented (SQL injection or XSS prevention). The tool is recommended to be used only in safe environments.

• Slides can be found here.
• Source and examples: here.

With Net::DHCP you will be able to craft custom DHCP packages and have access to all the fields defined for the protocol.

The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCPIP network.

UDP is used as transport protocol, all packets sent by the client have a source port of 68 and a destination port of 67. Likewise, packets originated in the server will have source port 67 and destination port 68.

You can create messages, attach options and pack them as the payload of a UDP packet. In the same way, you can use a capturing library such as Ruby/pcap to get packages from the network and parse their contents into well formed and comprehensible ruby objects.

This project’s SVN repository can be checked out through anonymous access with the following command(s):-

svn checkout http://netdhcp.rubyforge.org/svn/
or
svn checkout svn://rubyforge.org/var/svn/netdhcp


I hope you find the library useful. Let me know if you are using it for something!

References

• rfc2131: Dynamic Host Configuration Protocol
• rfc2132: DHCP Options and BOOTP Vendor Extensions
• rfc2563: DHCP Option to Disable Stateless Auto-Configuration in IPv4 Clients
• rfc4578: DHCP Options for the Intel Preboot eXecution Environment (PXE)
• rfc4702: The DHCP Client Fully Qualified Domain Name (FQDN) Option

To store the information of our comic strips we will be using YAML:

The YAML library serializes and deserializes Ruby object trees to and from and external, readable, plain-text format.

In the config file (rcomic.yaml) every comic strip definition will have the following appearance:

xkcd:
  desc: A webcomic of romance, sarcasm, math, and language.
  host: www.xkcd.com
  path: /
  rexp: <img>

You need a key word that will be used to refer to the strip and a set of configuration parameters, the host name, the path inside the server and a regular expression to identify the desired image.

In order to add a new strip, you only need to append a block like the one above to your configuration file.

Three steps are performed in the script: command line parsing, HTTP connection and download of the page, image download and display. In order to know what strip are we working on, first we need to load the configuration file as show:-

#load configuration
config = YAML.load_file('rcomic.yaml')

Then some simple logic determines if the requested strip (the first argument provided) is configured in the .yaml file. If no reference to the key word is found in the YAML file, a help message is displayed. Otherwise, we carry on with the next steps:

# prepare an HTTP connection
http = Net::HTTP.new($host)
# get the page
response = http.get($path)

# scan for the image
img = response.body.scan($rexp).first.first
file = File.basename(img)

First we request the page and then we apply the regular expression to the body of the HTML returned. The img variable will contain the full URL to the image (i.e. http://imgs.xkcd.com/comics/gyroscopes.png) and the file will contain only the file name (i.e. gyroscopes.png).

With this information is dead easy to download and display the images:

# download (if not already downloaded)
unless File.exist?("/tmp/#{file}")
  `wget -O /tmp/#{file} #{img}`
end

# display
`display /tmp/#{file}`

As a side note, we will only download the file if the file is not already present in our /tmp/ folder.

Happy comics