Saturday, April 28, 2007

Of presentations and security...

So... I had the chance to give a presentation to the East Bay Ruby on Rails Meetup Group (that's the Oakland part of the San Francisco Bay) about what it's like to be a nuby. Bottom line: the first step is an easy one, but after that it's a doozy (see the presentation here).

During the great discussion that followed, one of the group pointed out that production logging is at the :info level and that's not good -- information entered into the site is stored in clear text and therefore not as secure as it should be (people still have to hack the site, but obviously that's not good enough).

So I set about closing this loophole and also getting the sessions out of file storage and into the database where they are protected via password.

This should have been simple and easy, but it turned out to be really tricky: an example of things not being exactly what they seem to be. Here's the deal.

I had previously updated my environment.rb file to customize the logger, having found this code snippet at

config.logger ="#{RAILS_ROOT}/log/#{ENV['RAILS_ENV']}.log",2, 131072)

For some reason I couldn't get it to work as I reported in an earlier post. I had finally gotten it to work (I think it may have had to do with restarting my server, but it's unclear) and life was good: I had smaller logs and didn't have to wait so long for it to load when I was doing some testing.

However, what I found was that -- once this new logger was running -- I couldn't change the logging level (normally done with config.log_level in environment.rb or environments/production.rb). I wanted a logging level of :error (instead of :info) so that the operation of the site wasn't so readily stored. I tried a number of things, including the following code in environment.rb:

if ENV['RAILS_ENV'] == 'production'
config.log_level = :error
config.log_level = :debug

but that didn't work... things kept getting logged at the :info level in production -- definitely not good.

I also tried setting it with config.logger.log_level = :error but that didn't seem to work either.

I finally -- after much futzing around -- decided simply to remove the new Logger snippet and see if that would do the trick: and it did. Now I can set the logging level in production (in the environments/production.rb file) with a simple config.log_level = :error.

Someday I'll go back and try to understand what happened. For now, the system is operating the way I want it to and I've moved the config.logger snippet to my environments/development.rb file so that I have that capability in development where I really need it.

Fortunately, the sessions question was as easy as 1-2-3:

1. Run the command:
rake db:sessions:create
2. Run the migration:
rake db:migrate
3. Change the production.rb file:
config.action_controller.session_store = :active_record_store

and we're in business!

This is really an analogy for my experience with Rails: some of it is subtly obscure and challenging (like the Logger situation), while some of it is wonderfully intuitive and easy (like the Sessions situation).

Let's hear it for more of the latter!

Thursday, April 12, 2007

Applicaton is live!

Well... I finally got the application out there, up, and running. It obviously still has much work to be done, but the basic secure functionality is there.

4MyPasswords -- a secure well-lighted place to store you passwords and other confidential information (e.g., Frequent Flyer numbers; credit card numbers; ...)

Feedback welcome!

Sunday, April 8, 2007

A nice plugin for secure sites...

I realize that I didn't comment about the ssl_requirement plugin by DHH (David Heinemeier Hansson, the Rails guru) . It's really a very nice approach to requiring that certain actions be accessed only through SSL/https and letting the other actions through. Once I found it, it was quick and easy to install and worked flawlessly.

However, I couldn't use it: the fundamental controller for my application uses AjaxScaffold (AS), which provides all the CRUD/UI stuff that I needed and allowed the customizations that I wanted (albeit with some learning curve; see a previous post). AS uses a veritable galaxy of actions to perform its magic and there was no way (I tried) to identify the right actions individually. What I really needed was a way to identify a controller instead of an action that required SSL. I briefly considered and then as quickly rejected the idea of attempting to enhance the plugin. It's a small plugin and seems to be pretty straight-forward in operation, but I'm just not at that level and I wanted to focus on my basic application. Maybe another time...

I did have one other question regarding the plugin. Reviewing the code, I saw that it works by trapping and then redirecting the actions that you want secured. I wonder if that might not be too much overhead for a site with lots of traffic? I just don't know at this point.

Saturday, April 7, 2007

Customizing Rails and rabbit holes

Some things are easy in Rails... others are definitely not!

I mentioned in an earlier post that I'm using AjaxScaffold for the UI... I like the looks, there is lots of functionality, a fairly active forum, and the author (Richard White) has been very helpful. It's a great plugin.

With all that said, it's still been a challenge to get everything working that I wanted. The problem as I see it is "documentation": too much of it and not enough of it. This makes improving your expertise in Rails quite a challenge and will, IMO, keep nubies nubies for longer than I would like. Here's what I mean.

On the surface, AjaxScaffold (AS) has a great deal of very good documentation. There is, for starters, the website mentioned above. Then there's Richard White's home site, where there are a number of excellent articles describing AS. There's also Scott Rutherford's blog at Scott clearly knows AS well and also does an excellent job of writing about AS. Finally, there's the Google Groups AS forum, with many fine developers working on, describing, and customizing AS.

On the surface, you would think that customizing AS would be a piece of cake: just search the places mentioned above, get the relevant posts, and you're off to the races. Well, it doesn't work that way... at least for nubies. And that's a shame because it just makes getting productive in Rails that much more difficult.

Here's why the current approach doesn't work well.

1. There is no single place where someone can go to learn about AS -- either for an overview or for all the details. Things are scattered all over the place. That's not to say that there aren't some great tutorials; but usually those tutorials deal with only the most basic of information. This is like many of the gee-whiz Rails videos that I've seen: you learn how to do the simplest of tasks (which are admittedly much easier than without Rails), but you don't learn how to get to the next level. The first step is easy but watch out for the next step... it's a doozy.

2. Good information coexists with not-so-good information. As a nuby, you can't always tell the difference, and you can go down rabbit holes a bit too easily. Like Alice, it takes a long time to find your way back.

3. Good information is incomplete. This is the "Curse of Knowledge" in action (see the book "Made to Stick" by Heath & Heath... awesome!). I found good suggestions in a couple of different places, with code samples no less, but the surrounding "..." (meaning fill in the blanks here) turned out to be the key information that I was missing.

4. Information is out of date. Rails is changing and changing fast. So are the supporting tools, such as AS. On the one hand, that's really great. It's always nice to see new features being added. On the other hand, it's hard to keep up with all those changes. At some point, you may have to decide to give up on new features for some stability in your own development environment. For example, AS first appeared as a generator and then it migrated to a plugin. That's great, but how do you separate comments about the generator from comments about the plugin: it's not always clear which is which. Another rabbit hole to get lost in.

5. New stuff gets added that you aren't using. Now there's a new upgrade called ActiveScaffold. It has a lot of great new features and I'm sure that it's even better than the old AjaxScaffold. It has a few features that I would like to have, but -- as a nuby -- I'm a little too slow at learning this stuff to just jump on the new bandwagon. So now there are comments about ActiveScaffold that can send me down more rabbit holes. Fortunately, Richard gave this a new name and a new website, but it could (and was originally) referred to as version 4 of AS. Were that the case, I'd be in even more trouble.

So what's the problem here? It's that there's no one place to go to where you can learn "all" about AS... and I'm getting the impression that this is not just an AS problem. I'd really like to see one place where there is solid, up-to-date documentation about the package and all the options, along with examples.

I keep wishing for something like Perl's CPAN, the central repository where all (or at least most) contributed Perl modules reside, and where complete documentation is supposed to (and usually does) live.

So how am I doing with the customizations I want? I am making progress... I spent several hours digging through the code (amazing stuff, that AjaxScaffold) and I finally have the create/edit form displaying the drop-down box as desired.

I still don't have it saving the information properly, but I'm sure that's "just a little more" code-digging, rabbit-holing time to resolve and then I'll have this piece of the application up and running.

BTW, if you're interested in the solution to my AS quest, I'm documenting it as I go in the forum, under the title: Getting a drop-down to work in the create/edit form.

Tuesday, April 3, 2007

Webapp security using Secure Socket Layer (SSL)...

One of the things I want to do with my webapp is secure certain portions of it using https -- the secure mode of http communication. That requires an SSL Certificate... essentially a digital key and associated (encrypted) certificate that allows the web server and browser to encrypt and decrypt transmissions between the two [Don't ask me much more about the detailed security aspects... I am not a security expert].

However, since my Rails ISP doesn't provide built-in support for SSL, I had to go get my own SSL Certificate. I also had to get my own domain name (see previous posts) because this kind of Certificate is "attached to" (associated with) a specific domain -- I can only use this certificate with stuff on this particular domain.

I immediately ran into acronym hell -- things like "CSR", "RSA Key" -- and a process that was less than intuitive.

First, you have to get a "Certificate Signing Request" (CSR; also called a "Certification Request"), which you then send to a "Certificate Authority" (CA; think Verisign. Thawte, and others). These folks are the keepers of the keys... the public key infrastructure keys, that is, which is nothing more than the folks who are trusted to issue cryptography keys which make secure communications possible (read "eCommerce, eBay, etc...). In essence, they electronically vouch for who you say you are.

Once you have your CSR (which by the way requires that you know some of the webserver details (Apache vs IIS, which flavor of SSL is implemented in the server), then you pick your CA and submit an application. This application includes your CSR, reams of contact information, the domain name you wish to secure, and your email address (several flavors; more later on that).

I searched out the various options and finally settled on Thawte's SSL 123 certificate: it's tailored to securing a single domain name and was quite inexpensive: $39.95 for one year. GoDaddy's Turbo SSL was cheaper ($19.95), but I thought Thawte [pun intended] had a better name. Also, Thawte gives you an online "Trusted site seal" which makes it clear that you have secured your site... something that I thought worthwhile.

Once I got to this point, I figured it was all downhill from here... and it did go downhill, just not in the manner that I expected. I did finally get my certificate and had it installed on my server, but not before I ran into a few snags. Although Thawte gives you the option of having them generate your CSR, I chose to have my ISP generate it for me. At this point, I can't remember exactly why, but I'd most likely have Thawte do it for me now. Here's the chronology:

1. Request RailsPlayground (RP) generate the CSR for me. They did so, I submitted my application to Thawte and it was bounced:
"Invalid state"
RP had put the City name into the State field and we had both missed it.

2. Request RP generate the CSR for me. They did so, I submitted my application to Thawte and it was bounced:
"State code cannot be abbreviated"
RP had put in CA and it had to be spelled out in full.

3. Request RP generate the CSR for me. They did so, I submitted my application to Thawte and it was bounced:
"Invalid email address"
It took me a few more tries until I figured out that it had to be the email address which was referenced in the domain registration system(!). Once that was corrected, my request went thru, I was issued the certificate, and it is now installed on my site.

Were I to do this all over again, I would take the simpler route and do as much as I could directly thru the Certificate Authority's website... that would have saved me some of my headaches. But you still have to dig into it and learn something about the terminology before you can make this happen. Better yet, find an ISP that already has this baked in and save yourself some grief.

I'm happy to say that now I can use https on my website.

The question is how to implement it on my website... regardless of whether a visitor types in "https://" or not, I want to secure certain actions and certain controllers, and automatically route them to use https... but that's a question for more research and another post.

Monday, April 2, 2007

More on Ruby documentation.... or should I say 'less'

Trouble finding all the documentation I need. Sure, there's the Rails Framework site, which is really good for the basics, but there seem to be lots of other stuff in lots of other places, and -- so far -- I haven't found an index to the basic things.

What I need is documentation on logger: the method given on for rotating your logs doesn't work on my version of Rails (1.2.3).

Finally found the logger documentation at the Rails stdlib site. And there's introductory material on the Rails wiki.