If you haven’t heard by now, there is a huge security vulnerability using cffile to upload files. This effects every CF application out there and is being exploited as we speak. There is a ton of information out there about what causes and how to perform the exploit, however noone is doing anything about it at the moment to fix it. Needless to say, I wasn’t going to just sit by and wait for someone to fix it, so naturally, I came up with a pretty slick solution on my own. Below is a link to download a UDF that you should be able to use as a replacement until this whole thing gets sorted out.

If you have any comments on improvements or suggestions, please leave them below or feel free to edit the gist directly.

http://gist.github.com/138542

Compiled by following: http://osdir.com/ml/git/2009-04/msg01781.html

Thank you Martin Krafft @ http://madduck.net/, you saved my ass and I don’t even know you

Here’s the problem. I’m mirroring the CFWheels SVN repo (please migrate to github) using git and github. Last week my cygwin installation took a dive and in the midst of trying to fix it, I screwed up my local git repo used to do this mirror (completely my fault and not git’s or cygwin’s. Yes, I’m an idiot).

Anywho, I finally got everything up and running with cygwin, but now came the problem of getting the mirror working again. In the past to accomplish this, I actually did a forced push to the master branch on the mirror. It was OK since noone at the time had forked the mirror so it didn’t hurt anything. But now we have some people who have forked the mirror, so this isn’t an option for me any more. I actually had to figure out how to fix this.

After A LOT of searching and reading here is how I revived my git mirror of the CFWheels SVN repo. It turned out to be 4 simple command in git:

$ mkdir cfwheels
$ cd cfwheels
$ git clone git@github.com:rip747/cfwheels.git
$ git svn init https://cfwheels.googlecode.com/svn/trunk
$ git update-ref refs/remotes/git-svn refs/remotes/origin/master
$ git svn rebase

Now to explain each line (so I don’t forget):

$ mkdir cfwheels
$ cd cfwheels

Obviously I’m making a directory on my machine called cfwheels and switching to it (basic stuff)

$ git clone git@github.com:rip747/cfwheels.git

Here I’m cloning the svn mirror repo from github.

$ git svn init https://cfwheels.googlecode.com/svn/trunk

Here I’m creating a reference to the cfwheels repo on googlecode in my local git repo

$ git update-ref refs/remotes/git-svn refs/remotes/origin/master

This is the secret sauce! What I’m doing here is updating the HEAD of the git-svn remote (refs/remotes/git-svn, this is created for you by doing the “git svn init”) to match the HEAD I grabbed from github (refs/remotes/origin/master, again this is created for you by doing the “git clone”).

$ git svn rebase

Now that the two heads match, I’m able to pull the revision information from googlecode. What you’ll see at this point is a mess of lines run on the screen which corresponds to each commit in the svn repo. At the end you should get the following message:

Done rebuilding .git/svn/git-svn/.rev_map.d8ff095c-9719-0410-9cd3-1dd5d13d90f5
Current branch master is up to date.

Hopefully this helps you out. If I missed anything or you have an updated way to do this, please comment below.

UPDATE: I have created a custom cygwin repository that you can run setup against to get the last working version (1.5.6-1). You can download it from the box.net widget to the right or by clicking here.

Well it seems that I’ve completed hosed myself good. At work I updated my cygwin install and it installed the latest git and subversion packages. Long story short, this completely broke git-svn to the point where I can’t use it. What sucks is that I use git-svn to contribute to CFWheels which I’m using right now to rewrite some websites. It’s nice to be able to find a bug and fix it then and there and not have to wait until I get home.

Luckily I raced home tonight and saw that my cygwin installation on my home computer wasn’t upgraded, so that means I’m still able to contribute.

What really pissed me off is that this has been broken since version 1.5.6-1 and for over 4 months and hasn’t been fixed yet. I tried to install msysgit at work to see if that would work for me, but it’s a no go since their subversion packages are at 1.4 and GoogleCode is on 1.5.

Even sadder is that msysgit doesn’t seem to want to upgrade their subversion packages anytime soon as the maintainer himself told me here.

With the on going cygwin and msysgit problems, will git-svn ever get fixed?

What a strange problem. For the last 3 hours I’ve been trying to get my Linksys WRT54GL router to work. Seems that when I came home today something must of happened because my internet connection was totally screwed. I have Comcast as my ISP and I thought that there might be an outage in the area. After giving them a call, they determined the cable modem was OK and that my signal strength was perfect. Despite them being helpful on the phone, I would have to wait until Thrusday for a tech to come out and see what was the problem and I don’t have the luxary of being disconnected from the internet for 3 days.

Long story short, after hours of testing and trying things out, I determined that for some reason the DCHP client on my Linksys router died. I should mentioned that I was running Tomato 1.23 on the router. Don’t know what could of caused this, but with that I downloaded Tomato 1.25 and flashed the bios. Now everything is working again.

Whatever happened to the router today must of corrupted something in the bios and flashing it to a new version seems to have fixed the problem.

Your little spot on the net for me to tell you that I love and miss you deeply. Rest in peace now.

It was a small goal in my life to brake 1000 reputation points on stackoverflow.com. I’m happy to report that this was finally achieved!

If there’s one tool I have completely fell in love with it’s Dependency Walker (DW). DW is a tool that let’s you see what a file, in many cases DLLs, depends on in order to get them to run or register.

Case in point, just yesterday I was trying to get Office 2003 SP 3 installed on our intern’s computer. No matter what I did, I was getting the dreaded 1904: Cannot Register MSRCLR40.dll error and it was driving me insane. Now according to Microsoft and other sourcesI found on the net, this is a problem with not having the latest MDAC installed for XP (2.81 sp1), however I checked (by following Microsoft’s instructions) and I did have the latest MDAC installed. In any case, I reinstalled the latest MDAC, rebooted, tried the installation again and got the same thing. Dammit!

At this point, I knew that I could be downloading and installing different things all day, so I opted to run a repair on Microsoft Office and see what that did. Wouldn’t you know, I got the 1904 error during the repair, go fig. Now I’m screwed. I ran out of options the net handed me, so that’s when I decided to download DW and give this magical life saver a run.

As I mentioned above, DW is a stand alone tool that let’s you select a file and shows you which other files (or modules) the file needs in order to run or, in our case, register. It’s extremely easy to use and understand.

The first thing you need to do is download and unzip the latest version of DW. As of this writing it’s 2.2.

After you have it unzipped, open up the folder and double click the depends.exe file. Once DW loads up, all you need to do is click File -> Open and select the file that you DW to inspect (for this example I selected MSRCLR40.dll that was in c:\windows\system32 on my machine).

Is that cool or what? As you can see from the screen shot above, DW will show you all of the files that MSRCLR40.dll needs in order to work. Now if there are any files that are missing from your machine, they will show up in RED at the very top of the list (I have everything this file needs, so I don’t have any errors). Once you have your list of files that you need, all you need to do is to either download the files from the internet or copy them from another machine and copy them to the appropriate place. Then just hit View -> Refresh (or F5) and see if everything is OK. Don’t worry about any delay-load dependency module errors you might get since these module aren’t loaded until you actually try to run or register the file.

In the case of my intern’s computer, DW told me that the machine didn’t have MSJET40.dll, MSJINT40.dll and MSJTER40.dll. I managed to copy these from my work machine, however you can download them from Microsoft. After that I went to a command prompt and ran:

regsvr32 c:\windows\system32\msrclr40.dll

The file registered successfully and I finally got Office 2003 SP 3 installed!

Using a tool like DW from the get go can save you hours of searching the internet and trying different solutions until you find the magical one that fixes your problem. I find that in the world of tech support this tool is invaluble and hopefully you will too.

Well Day3 and 4 ended up with me having to do client work and some work for my day job. Those two days were a bust and I should of ended the days with doing some more coding, but afterwards my mind just wasn’t into it. I’m learning that this wasn’t the smartest idea. I now see why it takes a long time to get things done.

On top of all that, while I was just sitting down to type this out, I saw that the two commits to trunk that I made today weren’t the smartest changes either and I was asked to revert them, which I did.

I think I’m going to take a break tomorrow from testing and trying to find bugs since I basically creating my own

Wheels was donated some migration code quite a while ago from Ryan. One of my goals this weeks was to try to get migrations working. I figured tomorrow I fork the my local repo and see what I can do to get this in.

Today was WAAAAY more productive then yesterday, way more, even though I went to bed at 6:30am this morning. I had to finish a project for a client and decided that I better get it out of the way before it started to haunt me and dip into my Wheels time.

The entire day was spent revamping the testing framework for the last time (I hope) as I think I finally got it to where I want it to be. I did a bunch of optimizations to the testrunner and the output display. In doing so I discover the beauty of getComponentMetaData().

When running the tests, I had some logic in place that basically would inspect the meta data of the component you wanted to test to see if it is extending the wheels.test base component. There’s no reason to even waste the time searching for tests to run if the component won’t even have any and the only way it’s going to have tests is if it extends the wheels.test base component.

In order to do the check I would use createobject to create an instance of the component and then use getMetaData() to inspect the meta data. To me this seemed kinda dumb and it bothered me that I knew there had to be a better way and that’s when I found getCompoentMetaData(). Basically this does the same thing as getMetaData() but you don’t have to waste your time instantiating the component. All you have to do is pass the component path to getComponentMetaData() and it does the work for you and returns the exact same meta data that getMetaData() would. Very handy function indeed.

The other thing that was bothering me was the hackery way I was altering the application.wheels.modelPath and the application.wheels.modelComponentPath so that I could call test models with the model() function. Before I was performing my half ass hack inside the test cases themselves in the setup(), but I knew that this was going to get messy. It finally dawned on me to just add them into the testing framework itself for now. Later on we’ll think of a better way to pass a component path to model(), but as for right now this prevents me from having to do the hack manually and even though it’s still a hack, it’s a bit cleaner.

After finally getting the testing framework ironed out, I moved on to refactoring all the tests to get more output and separate the multiple calls to assert() I was doing in each test. All and all, Wheels not has 61 tests in 19 cases. Not bad for a start. It’s definitely NOT where I wanted to be at this point, but there’s no sense in rushing either.

Tonight I ‘m going to do some research into designing a testing database that I can use to properly test the model layer. I’m sure I’ll be totally OCD about the way it’s designed and will spend most of the day second guessing myself over and over. One of the ideas to get around this was was to look at maybe using the blogCFC database since it’s already been ported to like EVERY RDBMS engine out there (go Ray!). We’ll have to see.

Will update again tomorrow.

So how is it going so far? HORRIBLE!

Well first off, I updated my cygwin install with the latest version of git and subervion-perl a couple of weeks ago and when I went to rebase with the CFWheels repo, it would die. Only one commit at a time would be pulled down and then errors all over the place. After searching on google I found out that this is a known problem with the latest subversion-perl so I had to downgrade. That took me about an hour to figure out. I could have applied a patch to the version that I had already installed, but I wasn’t in the mood to be jerking around like that and I figured I’d leave that stuff to the experts.

After that I was finally able to sync with the svn repo and get everything up and running.

With my confidence in the toliet, I started writing tests and finding bugs that needed to be fixed. When I found my first bug, I decided to use trusty old tortoisesvn  to write the patch and get it into trunk since I had local checkout already. That went well, but it wasn’t the best way to do it. I should be using git and git-svn to do this stuff and by using tortise I had to litterally duplicate the patch that I already had in git. NOT SMART!

Anyhow, I continued coding and soon found another bug that needed some attention. “WHAT LUCK!” I thought because now I could submit the patch through git-svn like I should have been doing all along. BIG MISTAKE! Let’s just say that I fought with this for almost two hours, because I kept screwing up the workflow left and right and having to git reset –hard. Thank God that stackoverflow.com exists and after reading carefully, the solution that I found, and some playing around, I finally got the workflow down and was able to commit the patch.

All and all, I’m having a rough time. Maybe I’m just off my game today since I have a lot of other things in my head right now and my mental state isn’t in sync. No matter, tomorrow is another day and more coding.

Tomorrow I’m planning on completing the creation of a test database so that I can test out all the functions that depend on models and cleanning up the tests.

About the tests. Right now, the way I’m writing tests, I’ll have more then one assert in each test. From what I’ve seen and researched how other people write tests, this is the wrong way. You should have one assert for each test. After writing a bunch of them, this makes sense. Reason being is because if you have 5 asserts in one test and one of the asserts fails, the whole test fails. Now currently this isn’t a problem because I know it’s the last assert I wrote that failed. However, down the road I can see this becoming a problem when we’re trying to figure out where the test is failing. It’s not like I want the rest of the team to be commenting out asserts until they find the one thats failing. I come to the conclusion at this point that I’m going to have to rewrite all the tests I’ve created into this new format. Oh well it’s what learning is all about and the reason I love doing open source stuff.

I’ll update again tomorrow.