Midnight Oil

I sent out my first beta test invitations today. I chose the Hawkeye Roleplayers Association of the University of Iowa as my first target. It is a small group, but they are trustworthy, hardcore RPG players. My hope is that I will get honest, thought-out feedback as opposed to random flames.

Knowing that I’m about to unleash my creation on the world is both exciting and terrifying. What if they hate it? What if it crashes? What if they say, “Eh, nothing special”? I’ve invested so much time and effort into this that the prospect of failure is a nightmare. It’s inevitable that some will hate it, but will some like it? Could one or two possibly see the potential that I see? Am I really on to something, or was this all a horrible mistake?

I’ll probably be checking my e-mail all night just to see if anyone wants to join up. I might not sleep for days…

I was getting this error today in my Mongrel server logs. It was strange, because I didn’t think we were doing anything with Javascript.

It took me about an hour to track down, but I eventually found it. In our main layout, we had:

<%= javascript_include_tag 'defaults' %>

and it should have been

<%= javascript_include_tag :defaults %>

I guess RoR picks up on the symbol vs string and does something special.

I hope this helps somebody.

I followed the instructions on SlashDotSlash to modify the acts_as_taggable plugin by DHH to allow for per user tagging.

Unfortunately, there were a few hiccups that had to be dealt with. I’ll try to lay them out here.

Note: If you just want to jump right in, look for the patch at the bottom of the post.

1. User expected, got User

I don’t know what this error is about. It is some sort of type-mismatch that I don’t understand. However, I do know how to fix it (I think).

Edit the Tag.rb file and replace the on method with the following:

As you can see, I simply replaced the :user with :user_id. This explicitly sets the ID field rather than relying on Rails to infer it. This solved the problem for me, although it did not shine any light on what was happening. Comments?

2. Duplicate tagging on polymorphic models

I was having a problem where tags were multiplying on certain polymorphic models. For example, I would add the tag “tag1″ to an object. Then, I would edit the object and add “tag2″ When I saved, the final list would be “tag1 tag2 tag1″ Editing and re-saving would result in “tag1 tag2 tag1 tag1 tag2 tag1″ Obviously, the tags were multiplying.

It didn’t take too long to figure out that they were not being destroyed as they should before the new tags were added. The tag_with method is supposed to destroy all previous tags and then add the new ones. To fix this, replace the Tagging.destroy_all call in tag_with to the following:

The problem was that DHH’s original acts_as_taggable plugin handled polymorphic models by setting their taggable_type to the base class (immediate child of ActiveRecord::Base). This is because Single Table Inheritance guarantees that all these polymorphic objects will be in the same table and have different IDs with respect to that table. Somewhere during the rewrite on SlashDotSlash, this must have been missed. So, the taggable_type was being set to the base class, but the destroy call was looking for objects of the actual instance class, and therefore missing all the taggings.

3. find_tagged_with

Not strictly a bug, but a feature addition. The find_tagged_with method on SlashDotSlash was altered to require a user. This is good in cases where you want to retrieve tags on a user basis, but sometimes you just want all objects with a tag, regardless of the user. So, I made a simple addition and inserted find_tagged_with_by_user and left the original find_tagged_with alone.

Here are the methods:

SVN Patch

Here is a patch that goes from DHH’s original acts_as_taggable to my updated version. I wish I could make one that goes from the SlashDotSlash version, but I neglected to tag that version separately from other stuff, so I can’t really get back to a pristine version.

Note: This patch does everything except update your database tables. Details for that can be found in the SlashDotSlash article.

NO WARRANTY ON THIS PATCH! I am not responsible for anything that happens as a result of you applying this patch to your codebase!

My thanks go out to DHH for creating acts_as_taggable as well as RoR (duh!). Also, thanks to Ben at SlashDotSlash for posting his additions that added the per-user tagging that I desperately wanted.

After writing my last post about drowing in passwords, I started to wonder if my plan of partitioning passwords was just plain bad. There were some issues that were still bugging me:

• Keeping track of which password goes where
• Tracking the passwords in general (ie. how many do I actually have?)

After thinking for a while, I decided to try a password manager. I have tried one before, but for some reason it just didn’t work out. I cannot remember why, but these things usually boil down to ease and usability. If the program is slow or complicated, and takes significantly more work than just typing a password into a field, then I usually give up. Still, I have a lot more passwords to juggle these days.

I found a password manager called KeePass that looks pretty promising. In addition, there is a port, KeyPassX that runs on Linux and hopefully Mac OSX (although I am almost never on a Mac).

So, with a password manager, I just need to remember one master password. It is never transmitted over the network, and never displayed in plain-text (unless I write it down). This master password unlocks all my other credentials. I can store the password database on a USB drive, along with the KeePass binaries. Then, it’s just plug-and-play on any computer I want to use.

This means I need to add my USB drive to my “always there” kit. Currently that kit includes my wallet, cell phone, and keys. If I can figure out how to get my current USB drive on my keychain then that would be perfect, since I would just need to remember my keys, which I almost never forget.

New plan: password manager + keychain USB + different passwords for everything + changing frequently = maximum security with minimum hassle

Update: I’ve totally deprecated this plan in favor of using a passord manager.

I am becoming overwhelmed by the number of passwords I am having to juggle. As a single user, you probably have a couple passwords to remember. Onilne bank, home computer, work computer, e-mail, and maybe a few others. If you’re like me, you probably use one or two easy to remember passwords across all these arenas. Sure, you’re not supposed to, but anything more complicated just gets too hard. Besides what are the real odds that anyone is going to go to the effort of cracking your password?

Now, I am spinning up a website that I hope thousands of people will be coming to on a daily basis. That makes me a nice target for all the jerkos and script kiddies out there, which means I need to be more security conscious. On the other hand, I have several more credentials to remember. In fact, here’s a quick list of the ones I can name off-hand:

• subversion
• server root
• server normal login
• MySQL root
• MySQL Obsidian Portal user
• MySQL blog user
• MySQL forums user
• Obsidian Portal admin user
• Obsidian Portal normal user (Micah)
• Blog admin user
• Blog normal user (Micah)
• Forum admin user
• Forum normal user (Micah)

I’m sure there are some others that I’m forgetting here, too.

Obviously, certain credentials are more sensitive than others. If someone were able to crack the server root password, they could effectively shut the site down and cause a lot of problems. Likewise, cracking into the MySQL databases would allow for corruption of the data in nefarious ways. By contrast, if they cracked my Obsidian Portal normal user, they could log in and make comments or delete my campaigns. Irritating, but not show-stopping.

Tangential to a password’s sensitivity is its “risk profile.” By this, I mean that certain passwords are at a higher risk of being intercepted. Lowest risk would be passwords that never go out over the network^*. For instance, when this blog connects to the database, it uses a password that stays on the localhost, since the database is hosted locally. At higher risk are passwords that travel over the network, but are encrypted. SSH logins are a good example of this. Finally, the highest risk (hopefully?) are credentials that are sent in plain text over the Internet. Blog login, Obsidian Portal login, and forum login are all like this.

So how do I cope with this mess? Currently, I don’t…at least not very well. However, I have a plan. I will partition the set of credentials based on their at-risk status:

1. high - plain text over the network
2. med - encrypted over the network
3. low - localhost only

Then, I will use a single password for each category, and I will change them regularly, say once a month. I might even get rid of the low-risk profile altogether, for reasons noted at the bottom of this post.

Another option would be to partition the passwords based on sensitivity, but there is one big problem with this: you may not remember the rated sensitivity of a set of credentials in the future. So, is my subversion login high or medium sensitivity? This is a really bad situation, because if I cannot remember, I will simply start iterating through my passwords until I find the right one. Assuming someone is listening in, I have just given away all the keys to the kingdom.

So, here’s a question to the readers: How do you manage all your different identities? Automated tools? A good memory? Tattoos? I’d love to hear a better way than what I’m doing, as it truly does not sound all that secure to me. Still, it’s better than just using my dog’s name for everything…

^* Note that some of these “low risk” passwords are not as low risk as they may seem. This is because they must get to the server at some point. So, if you insecurely FTP a file containing one of these passwords, then it has gone out over the network in plain text, which makes it high-risk.

It’s a Friday night, it’s late, and I’m at home writing a blog post. It’s either this or writing more Ruby on Rails code. It probably sounds like I’m complaining, but I am actually quite happy with my life.

For the past few months, I, along with my good friend Ryan, have been creating a Web 2.0 site for Dungeons & Dragons. It is my attempt at carving out my own little niche of the world wide web. It is also a chance for me to take a shot at being an Internet entrepreneur, and that’s what this blog is all about.

Throughout this entire journey, I will try to organize my thoughts and experiences here for posterity. Whether my site is a success or failure, I am determined to learn something and be better prepared the next time opportunity comes around. After all, I only need one success to make up for any number of failures. So, check back, follow our progress, and hopefully learn from our mistakes. I just hope we learn from them too.