I saw a question on the rspec list recently asking about how you test an SSL required page within cucumber, and I realized that I’ve had that, and even more cert-related chaos, figured out at $WORK, and that I should probably talk a little bit about it.

Simple scenario is that you’ve got some controller on your site that is supposed to only be accessible via https, and you want to make sure it behaves correctly in cucumber. In your standard deployment scenario, mongrel never really sees anything about SSL; that’s all handled by Apache. Apache will set some headers for you, which rails can check to determine if you’re using SSL. Since you’re not testing with Apache at this testing level, you just need to set the relevant HTTP headers.

Given I am using HTTPS
When I visit /payments
Then I should see the payments page

Given I am not using HTTPS
When I visit /payments
Then I should see an SSL error page

If I’m using webrat (which is highly recommended here) this becomes as simple as setting a header value. In recent versions of webrat, that boils down to:

Given /I am using HTTPS/ do
  header("HTTPS", "on")
end
Given /I am not using HTTPS/ do
  # this space left intentionally blank
end

If you’re NOT using webrat, but still at the rails integration test level, the call is a bit uglier

  get :show, { :id => 1234 }, { :https => 'on' }

The get method at the integration test level actually takes a third argument, which is the HTTP headers set on that request. At the functional / controller example level, the same method might work — I don’t know, I havn’t actually tested this at that level, instead I’ve just stubbed the https? method as needed.

Now, for bonus points. At $WORK, I exist in one of those ideal closed environments where x509 authentication actually stands a chance of working. That is, everyone gets a client certificate, which they send to us with the HTTPS request. We check against an external service, see that the cert is good, and viola, we can pre-populate with all sorts of juicy user information. Pipe dream on the internet, but it works well on an intranet. (having worked with this stuff, it’s no surprise to me at all that x509 client certs havn’t even managed to catch on with banks much less the general public …)

Apache takes care of checking the certificate, making sure it’s valid and well formed, and that it’s not in any CRL, and that it’s trusted. Makes my life easier, at the Rails level, we just have to check against the external service and we’re off to the races. And, happily, apache will pass things on in the headers.

Given I use the client certificate for “Joe”
Then when I visit /administration
I should be let in

Given /I use the client certificate for "(.*)"/ do |cert_user|
  #lookup or generate stub certificate information
  header("X_CLIENT_CERT", certificate.certificate)
  header("X_CLIENT_DN", certificate.dn)
  header("HTTPS", "on")
 
  DirectoryService.instance.stub!(:lookup).with(certificate.dn).and_return certificate.remote_xml
end

I’m hand-waving around some of the stubbing that would have to go on here, as far as generating dummy information goes, but the basic idea should be sound. In this case, I’m stubbing the entire DiectoryService.lookup method for a particular DN, which I set in the headers, and returning “remote_xml” which is a stand in for the XML document that the remote system returns. This lets me cut out the remote system, which wouldn’t appreciate being hit for all sorts of trash data every time the tests run, while still exercising most of the relevant internal code.

The general idea of an integration test is to see all of the pieces of the system working together. At this point, Cucumber is exercising everything in the stack below Apache. Since certificates and x509 client certificates are largely dealt with by apache, we have to stub those ins and outs to work through the rest of the system. The system is otherwise left unstubbed, and we check those integration points during manual testing.

Bug report gets filed about the application at work. It seems that there’s an error that crops up when you print from IE. The error, of course, being the characteristically unhelpful dialog of garbage that IE likes to throw at you. After a bit of digging, it got even better. I was hoping I’d be able to respond with something technically snotty, like “Do you have your printer installed?”

But, I managed to reproduce the bug. Even better, I managed to narrow down it’s occurance. It turned out that when you were logged in, the error would occur, but only if you were logged in. Now that’s strange, since we’re using application level (cookie based) authentication — IE wouldn’t know anything about your logged in state. Everything works fine in Firefox (of course, the browser with good diagnostic tools doesn’t show the problem …)

So, in stumbling around trying to find some clue as to what the problem is, I came across this … It seems that id="tags" ends up conflicting with some builtin function in IE that’s used in printing. Sure enough, we had a field with <input name="tags" id="tags" type="text"> that was wrapped inside an if logged_in? check. Renamed the field, and printing now works like it’s supposed to.

So, what could have been really long and painful was short circuited by a lucky find in my net searches. No thanks to IE, it’s non-reserved reserved fields and opaque error messages. Have I mentioned lately how much I hate IE?

So, I’m gonna jump into the migrations and patch the existing add_index calls to specify a :name => value for all of the existing indexes, so that migrations will actually work and leave me with a database that matches the one in production ….

Figuring out why I suddenly couldn’t build my test database was not exactly the way I meant to spend the last hour ….

Update

Changeset 4768 is responsible for all this. Apparently, to allow reverse parsing of the indexes from the index name. Not alltogether a bad goal, but it still breaks down migrations … (thanks to Devin for find this one)

And, I discovered another problem last night. Seems that all of my text fields have a default value of “empy_clob()” … not the function, but that actual string. Sort of trashes one’s assumptions about unset fields. Apparently (thanks Roy) this has been worked out in ticket 7344 and already applied to Edge. Some sort of thing that only applies to Oracle, because, of course, nobody tests Rails on Oracle, it’s all MySQL. And I can’t really look into the patch attached to the ticket, because I keep getting Trac errors. Shaping up to have been a lovely adventure …

update
Finally got through to the site, and worked out a monkey patch to fix this. For those of you who might be running with oracle, and can’t upgrade to Edge (gee, wonder why not) the patch is below. This is a temporary thing, given that the ticket is closed, and will hopefully be fixed in 1.2.2 …
[ruby]
class ActiveRecord::ConnectionAdapters::OracleColumn
attr_writer :default
end if defined? ActiveRecord::ConnectionAdapters::OracleColumn

class ActiveRecord::ConnectionAdapters::OracleAdapter
def quote(value, column = nil) #:nodoc:
if value && column && [:text, :binary].include?(column.type)
%Q{empty_#{ column.sql_type.downcase rescue ‘blob’ }()}
else
super
end
end

alias columns_orig columns
def columns(*a)
columns_orig(*a).each do |col|
col.default = nil if col.default =~ /^(null|empty_[bc]lob())$/i
end
end
end if defined? ActiveRecord::ConnectionAdapters::OracleAdapter
[/ruby]

This appears to do the trick … a dump of the test schema no longer defaults all of our text columns to “empty_clob()” and tests are again passing …

Right now, it’s deployed using the standard-mongrel-rails-stack ™, using 2 mongrel servers, all on one box. Seems to be holding up very well. As a note, moving your session store off the disc and into the database (ARSeession) does wonderful things for performance. Down side: It appears that a Text field in oracle is capped out at 4096b. Which puts an upper limit on an individual session size. Not necessarily a bad thing, but it’s likely to bite us in the butt at some point.

To top off the deployment exctiement, I’m buying a house. Closing comes in on Wednesday. We’ve already been through and plotted everything out. New appliances are ordered and on their way, buying up lighting fixtures, picking out paint colors … it’s pretty much all done but the installation, which is scheduled for Friday.

So, after about a month, I finally get a chance to breath. So, what am I doing? Refocusing on Dark Sun stuff. Lots to do there, including actually following through on the site. At least that one will be public …

We demo today, which will basically determine whether or not we get to keep running with this little experement. At the moment it’s a very functional proof of concept. Covers all the basics, but … well, I wouldn’t call it robust just yet. Early demos have gone well, but this is the important one.

In all, I’d have to say that I’ve picked up a lot of Ruby on Rails knowledge, so it’s been a good experience in that respect, regardless of outcome.

I’m sure the demo will go well, but some of the guys havn’t gotten much sleep last night. Not much point in loosing sleep, what will be will be. And really, the demo will go well. Whether or not we get to take this beyond a proof-of-concept is, sadly, a matter of politics, and just a little bit out of my sphere of control. Hence, no sense worrying about it.

In the last two months at work, I’d have to guess that I’ve picked up a pretty strong working knowledge of Rails … still have hiccups, of course, but I’ve gotten a rather snazzy javascripty app put together for doing “news” page layout. It’ll never see the light of the ‘net, since the thing is intended to live on a private network, but it’s been a good workout, both of my Javascript skills, and my developing ruby muscles. So, yeah, really should be talking more about my experiences picking up that new langauge and platform. Whole thing is due for a set of demos over the next couple of weeks. The low pressure, “determine if we’re gonna keep funding the project” type of demo.

As for side projects, I’ve got a rewrite of athas.org in the works, which is going to be rails based. Really, I just need a couple of days without distraction. Once I get the “releases” section worked out and done, the rest is a cakewalk. Of course, those distraction free days have been kind of mythical. I’ll have a couple of days for it next week, I suppose — my girlfriend is getting knee surgury, and I’m taking some time off work (wonderful timing with the demos and all, but it’s been scheduled for a while).

And on the same lines, I’ve got an article due for Dragon magazine at the end of the month that I’m struggling with. It’s taking shape, but the constraints aren’t exactly what I’d call natural for the setting.

Other than that, my time has been tied up with the usual “summer” things — weddings, weekend trips, a bbq or two at the park … not much time for keeping up a blog. On the plus side, it also means that I havn’t had much time for keeping up with World of Warcraft … I think it might be safe to say that that particular distraction has finally let me go.

Of course, I’m mired in various bureacratic setup issues … you know, little things like system accounts and network access.

Promises to be interesting though. My project manager has just come back from some kind of conference on agile development, and she seems to be quite fired up. My network access issues look to be somewhat mitigated by the fact that she wants to give pair programming a good try … so, it turns out that I won’t actually need my accounts and such right away. I’ve never really done pair programming before, but it should be an interesting experience… The other developer I’m pairing with knows what he’s talking about, as far as the depths of Ruby go, so at least I will get something out of it …

Not without some trepidation, of course. The bad is that I’m looking at what could easily be a painful commute through traffic. Though there are supposedly enough ways to the campus, and I’ll have enough schedule flexibility, that traffic really shouldn’t be a worry. Still, I have this irrational fear of Nothern VA traffic. I like driving, not stop and go.

The other fear that I have is that I’ll find out that I really just can’t stand working in a vault. I’m very much a product of a connected world. Lacking quick and easy access to the internet is like lacking access my temporal lobe.

But, the good: I’ll be working on a project in Ruby on Rails. In the community I’m working in, that’s pretty big. “Early adopter” means that they managed to get Windows 2000 on desktops in 2005, so this is pretty big. I’ll get to work on a Unix system (yay!) and the project is relatively green-field — it’s a total redesign of a rather cumbersome enterprisey system that can’t be upgraded. I sort-of know one of the guys I’ll be working with. Enough to know for certain that he knows Ruby really well. Whereas I’ve just sort of dabbled with it. I’ll be learning a lot on that front. To top it all off, the intention of the program is not only one that I can agree with, but one that I think will actually do something useful.

So … new working environment, opportunity to learn something, and the chance to do something good out of it? I’ll deal with the drive.