Shog's Worklog - Worklog

CruiseControl.NET: Configuration Error

nospam@example.com (Shog9) — Tue, 16 Oct 2007 18:51:25 -0700

Just upgraded to CC.NET 1.3. And it didn't work. It spectacularly didn't work. Ok, it just didn't work:

Configuration Error
Description: An error occurred during the processing of a configuration file required to service this request. Please review the specific error details below and modify your configuration file appropriately.

Parser Error Message: The format of the file 'ThoughtWorks.CruiseControl.WebDashboard' is invalid.

Unfortunate, that. After a few fruitless web searches, I re-installed 1.2, and of course, that worked. Which gave me an idea...

Loaded 1.3 again, checked InetInfo settings, and sure 'nuff - it was still set to the 1.1 framework (1.3 is the first .NET 2.0 version of CC.NET). Change it to 2.0, and all was right with the world.

I could cry

nospam@example.com (Shog9) — Tue, 25 Sep 2007 16:10:57 -0700

After almost three days, i finally narrowed down an intermittent problem with a certain library. Turns out, it's contained within a rules engine we borrowed from another group.

A rules engine that isn't thread-safe.

It's 2007. We're using .NET. There's precious little need to make random variables static (er, rather, "Shared" - this is VB.NET). And it's trivially easy to add a bit of locking to avoid the problem, if you really must share the current rule with every other instance.

Worse yet, this isn't even the problem i was trying to track down.

So now, i'm tired, depressed, and no where near done. I know in my head that this isn't the fault of VB, but my heart still lays blame.

New CPhog released

nospam@example.com (Shog9) — Thu, 05 Jul 2007 14:30:29 -0700

I've just uploaded the GreaseMonkey "boot" script for CPhog 1.9.1

This will probably be the last release before I bite the bullet and go in for some major restructuring. I've been using it for months now, and it's reasonable solid... but there are just too many remnants of the quick-and-dirty little script i threw together a couple of years ago.

Notable changes with this release include the ability to load threads longer than 50 posts, "QuickBio" pop-up user profiles, and "ForumWatch" panels.

Under the hood, changes include lots more reliance on jQuery for DOM and plugin/content loading, some solid structure to new features (plugin-style loading rather than the "one huge script" style I'd labored under for so long), and the use of GlobalStorage instead of GM_setValue/GM_getValue (prefs.js). Many thanks to David Stone for his work on all of this, not to mention cleaning up a lot of my old code.

More details here...

Fit acceptance testing and OpenWiki

nospam@example.com (Shog9) — Sun, 24 Jun 2007 17:16:27 -0700

NUnit now includes the Framework for Integrated Test (Fit) engine. I'm not entirely sure why (there seems to be some support for using it to run NUnit tests) but my curiosity upon seeing the new DLL led me to read more about Fit. And it couldn't have been more timely - the project I was working on had something like 47 test cases taken directly from sales orders, complete with supplier-provided "known good" outputs - a perfect ahem fit for Fit testing.

And what a beautiful thing it is. A few minutes work, and the Excel spreadsheet of test cases was a HTML document suitable for feeding into the .NET version of Fit - much preferable to the manual translation of each scenario into a NUnit test, or (shudder) manually entering each case into my interactive testing app. I'd been planning on creating a bulk-testing interface anyway, and this just seemed too good to be true - it was almost exactly what I'd been planning, and saved me the time and effort of writing and debugging a custom CSV parser + test harness.

The only thing lacking was integration with our wiki, which was the other part of my idle plan... Sure, there's FitNesse - but that just solves one problem with yet another wiki to maintain.

So I hacked together an ASP.NET runner for Fit, threw it on our build machine, and then built in a new processing instruction to let OpenWiki forward on a page to this service for processing.

Satisfaction!

In case anyone else has a use for it, here's the code required:

OpenWiki #FITTESTS processing instruction (modify mywiki.asp)

Function MyWikifyProcessingInstructions(pText)
       
   ' other custom processing instructions...
   
   ' Fit integration: detect Fit processing instruction, flag for later processing
   dim FitPI, FitPILen
   FitPI = "#FITTESTS"
   FitPILen = Len(FitPI)
   if m(pText, "\n" & FitPI & "\s+", False, False) Then
      dim lineStart, lineEnd
      lineStart = InStr(pText, FitPI)
      lineEnd = InStr(lineStart, pText, vbCR)
      If lineEnd > lineStart+FitPILen Then
         gFitTestPath = Trim(Mid(pText, lineStart+FitPILen, lineEnd - lineStart - FitPILen))
      End If
      pText = s(pText, "\n" & FitPI & "[^\r\n]*\r*\n", "", False, False)
   End If

   ' other custom processing instructions...
   
    MyWikifyProcessingInstructions = pText
End Function

Additional modifications to mywiki.asp - these actually call the testing web service after the page has been mostly built.

Function MyLastMinuteChanges(pText)

   ' other custom last-minute changes...

   ' Fit integration
   If (gAction = "view" and Len(gFitTestPath) > 0 ) Then
      dim TestResults
      TestResults = RunFitTests(pText, gFitTestPath)
      If ( err.number <> 0 ) then
         pText = "<i>Error running tests: " & err.description & "</i><br />" & pText
      Elseif ( Len(TestResults) = 0 ) then
         pText = "Unknown error running tests" & pText
      Else
         pText = TestResults
      End If
   End If

   MyLastMinuteChanges = pText
End Function

Function RunFitTests(pText, gFitTestPath)
   dim url
   dim verb
   dim form

   ' location of FIT service. Need not be local.
   url = "http://localhost:8088/FitService.ashx"
   verb = "POST"
   form = "ClassPath=" & Server.URLEncode(gFitTestPath) _
      & "&TestData=" & Server.URLEncode(pText)
      
   on error resume next  
   
   dim xmlhttp
   set xmlhttp = Server.CreateObject("Msxml2.ServerXMLHTTP.4.0")
   if ( xmlhttp is nothing or err.number <> 0 ) then
      err.clear
      set xmlhttp = Server.CreateObject("Msxml2.ServerXMLHTTP")
   end if
   
   dim xmlDoc
   if ( err.number = 0 ) then
      xmlhttp.open verb, url, false ' synchronous
   end if
   
   if ( err.number = 0 ) then
      xmlhttp.setRequestHeader "Content-Type", "application/x-www-form-urlencoded" 
      xmlhttp.send form
   end if
   
   ' try to figure out if it worked or not. And if not, why. VBS error handling... yuck.
   dim status
   if ( err.number = 0 ) then
      status = xmlhttp.status
   end if
   
   if (err.number <> 0) then
   elseif (status <> 200) then 
      Err.Raise 65000, "", xmlhttp.statusText & "(" & status & ")", "", 0
   else
      ' clean up Fit html
      RunFitTests = Replace(xmlhttp.ResponseText, "&nbsp;", " ")
      RunFitTests = Replace(RunFitTests, "<br>", "<br/>")
      RunFitTests = Replace(RunFitTests, "<hr>", "<hr/>")
      RunFitTests = Replace(RunFitTests, "<font size=-1", "<font size='-1'")
   end if  
   
   set xmlhttp = nothing  
End Function

FitService.ashx - quick'n'dirty Fit runner. You might want to add some error handling...

<%@ WebHandler Language="C#" Class="FitService" %>

using System;
using System.Web;
using fit;

public class FitService : IHttpHandler
{

   public void ProcessRequest(HttpContext context)
   {
      context.Response.ContentType = "text/html";
      context.Response.ContentEncoding = System.Text.Encoding.UTF8;

      Fixture.assemblyDirs = context.Request.Form["ClassPath"].Split(new char[]{';'});
      
      Fixture fixture = new Fixture();
      Parse tables = new Parse(context.Request.Form["TestData"]);
      fixture.doTables(tables);
      tables.print(context.Response.Output);
   }

   public bool IsReusable
   {
      get
      {
         return false;
      }
   }
}

With these in place, i can add a line to the beginning of any wiki entry:

#FITTESTS c:\MfgEngineInterface\Current build\

...followed by a table containing the tests, and the tests will be automatically run and their results provided upon page generation.

The string '0000-00-00T00:00:00-05:00' is not a valid AllXsd value.

nospam@example.com (Shog9) — Sun, 17 Jun 2007 00:47:08 -0700

This is one of several exceptions that started cropping up recently in a little web app I'd written to display bugs in our TestTrack database.
Turns out, the value represented a null date (the server is located in CDT, GMT-5); however, the .NET SOAP framework doesn't seem to handle such things. I don't know enough about SOAP to say which party is in the wrong, but it turns out the value was part of a source control record that I wasn't particularly interested in anyway, so I just ditched the field altogether - filename + revision # should be enough.

Triple bug!

nospam@example.com (Shog9) — Mon, 11 Jun 2007 15:00:34 -0700

The Interface called The Engine to verify The Data before passing The Data to The Framework. This is redundant, as The Framework is already responsible for verifying any data passed to it. Bug #1.

The Framework called The Engine to verify The Data. Except, it skipped the call in all but two obscure scenarios. Bug #2.

The Engine was broken, and would always fail anything passed to it for verification. Bug #3.

None of this was unit tested, and so The Bugs lived in The Field for more than a year... Programmer Error!

WinInet ASYNC mode sucks

nospam@example.com (Shog9) — Fri, 30 Mar 2007 13:59:00 -0700

Spent most of the day wrestling with this wretched API. What a complete waste of time. Tells me the request is complete, but wants me to wait an unknown amount of time before actually letting me retrieve the response. Ugh.

Forget it. I'll just shove the whole thing off onto a separate thread and let that sit and wait for as long as it needs.

Dump calls

nospam@example.com (Shog9) — Thu, 22 Mar 2007 11:56:00 -0700

I'm working with a 3rd-party library that does some machine-specific calculations. It's called through COM interop, and takes a ton of parameters. When something doesn't come out right, it's nice to be able to quickly view what's being send in and returned without spending an excessive amount of time in the debugger... so I use this quick-and-dirty little wrapper to dump them to the output window:

using System;
using System.Collections.Generic;
using System.Text;
using System.Reflection;
using System.Runtime.Remoting;
using System.Runtime.Remoting.Proxies;
using System.Runtime.Remoting.Messaging;
using System.Runtime.InteropServices;
using System.Diagnostics;

public class DebugTraceProxy
   : RealProxy
{
   readonly MarshalByRefObject target;

   public static T NewObject<T>()
   {
      return (T)(new DebugTraceProxy(typeof(T)).GetTransparentProxy());
   }

   private DebugTraceProxy(Type t)
      : base(t)
   {
      target = (MarshalByRefObject)Activator.CreateInstance(t);
   }
   
   public override IMessage Invoke(IMessage msg)
   {
      IMethodCallMessage call = msg as IMethodCallMessage;

      Debug.WriteLine(call.MethodName + ":");
      for (int i = 0; i < call.InArgCount; ++i)
      {
         string name = call.GetInArgName(i);
         object arg = call.GetInArg(i);
         Debug.WriteLine("   " + name + ": " + DumpOb(arg));
      }

      IMethodReturnMessage ret = RemotingServices.ExecuteMessage(target, (IMethodCallMessage)msg);

      Debug.WriteLine("Returned:");
      for (int i = 0; i < ret.OutArgCount; ++i)
      {
         string name = ret.GetOutArgName(i);
         object arg = ret.GetOutArg(i);
         Debug.WriteLine("   " + name + ": " + DumpOb(arg));
      }
            
      return ret;
   }

   private string DumpOb(object ob)
   {
      Type t = ob.GetType();
      if (t.IsPrimitive || t == typeof(string))
         return ob.ToString();

      string obDesc = "";
      FieldInfo[] infos = t.GetFields(BindingFlags.FlattenHierarchy | BindingFlags.Public | BindingFlags.NonPublic | BindingFlags.Instance );
      if (infos.Length == 0)
         return ob.ToString();
      foreach (FieldInfo field in infos)
      {
         if (obDesc != "")
            obDesc += ", ";
         obDesc += field.Name + ": " + field.GetValue(ob).ToString();
      }
      return obDesc;
   }
}

To use it, I create the object like so:

CrazyOb myCrazyOb = DebugTraceProxy.NewObject<crazyob>();

Reflection... handy.

VS2005 DataTips for MFC collection classes (CMap, CArray, etc.)

nospam@example.com (Shog9) — Sat, 10 Mar 2007 17:19:00 -0700

I spend a lot of time debugging old code. Tracing through libraries written years ago, before the VC++ STL had reached maturity. And one of the often-frustrating aspects of this is how difficult it is to examine the contents of the old, MFC collection classes. CDWordArray, CStringArray, CMapPtrToPtr... not to mention the various templatized versions of these classes. While sometimes these can be easily replaced with newer, better-supported STL equivalents, often the effort involved outweighs the benefit.

At least for the array classes, it's only a minor inconvenience: the array pointer, and the size of the array are both readily available, and with these it's easy enough to view the contents.

But for the CMap classes, things get ugly. Internally, these objects are hash tables, with an array of buckets and each bucket a linked list. Viewing the contents of one of these maps in the debugger requires manually tracing the list of each bucket, then backing up and trying another bucket, then another... until you've found the item, or just given up.

The std::map<> class, implemented as a red-black tree, should be just as much of an annoyance to view - however, it gets flattened into what looks like an array:

Handy, eh? So enough of tracing through buckets.
Open \Program Files\Microsoft Visual Studio 8\Common7\Packages\Debugger\autoexp.dat, and at the end of the [Visualizer] section, add:

;------------------------------------------------------------------------------
;  CArray
;------------------------------------------------------------------------------
CArray<*>|CDWordArray|CWordArray|CByteArray|CUIntArray|CPtrArray|CObArray|CStringArray{
   preview
   (
      #( "[", [$c.m_nSize], "](",
         #array 
         (
             expr : $c.m_pData[$i],
             size : $c.m_nSize
         ),
      ")")
   )
   
   children
   (
      #(
         #array 
         (
             expr : $c.m_pData[$i],
             size : $c.m_nSize
         )
      )   
   )
}

Start a debug session. You should now be able to quickly examine the various CArray (CDWordArray...) objects as easily as std::vector<...>s. Note that the preview (...) section controls what's viewed in the initial DataTip or watch line, while the children(...) section controls what's displayed when you expand it.

Now for the fun one. Start with:

;------------------------------------------------------------------------------
;  CMap
;------------------------------------------------------------------------------
CMap<*>|CMapPtrToPtr|CMapPtrToWord|CMapWordToPtr|CMapWordToOb|CMapStringToPtr|CMapStringToOb|CMapStringToString{
   preview
   (
      #( "[", [$c.m_nCount], "](",
         #array 
         (
             expr : $c.m_pHashTable[$i],
             size : $c.m_nHashTableSize
         ) : #list (
                 head : &$e,
                 next : pNext
             ) : $e,
      ")")
   )
   
   children
   (
      #(
         #array 
         (
             expr : $e.m_pHashTable[$i],
             size : $e.m_nHashTableSize
         ) : #list (
                 head : &$e,
                 next : pNext
             ) : $e
      )         
   )
}

Ah, now this one will save some serious time - it'll flatten the various CMap objects such that they look like arrays in the debugger. A CMap with 3000 items will show 3000 children, numbered 0-2999.

But it can still be better: each of those children is a key-value pair, specifically a CMap::CAssoc object. It'd be nice if we could get a preview of those keys and values as we scroll through those 3000 items, rather than having to expand each one...

CMap<*>::CAssoc|CMapPtrToPtr::CAssoc|CMapPtrToWord::CAssoc|CMapWordToPtr::CAssoc|CMapWordToOb::CAssoc|CMapStringToPtr::CAssoc|CMapStringToOb::CAssoc|CMapStringToString::CAssoc {
   preview
   (
      #( 
         "(", 
         $e.key, 
         ",", 
         $e.value, 
         ")"
      )
   )
   
   children
   (
     #(
         key: $c.key,
         value: $c.value
     )
   )
}

There! All happy.

Of course, you can write rules for your own datatypes too, if you want them to be immediately visible in the preview. For a good reference, see the excellent writeup over at virtualdub.org

Tables and numbers and colorful graphs and...

nospam@example.com (Shog9) — Mon, 26 Feb 2007 08:44:00 -0700

A while back, I needed to generate some reports off of a small database I maintain. I needed them to be updated frequently, and didn't want to spend a lot of time putting them together.

Of course, I could have used Crystal Reports. But it just didn't seem right - I keep a large number of knives at home, and should I ever desire death by a thousand cuts, I'm sure it could be arranged on my own time. No reason to mix such activities with work.

So based on a recommendation, I decided to give SQL Server Reporting Services a shot. Installed it on my desktop, threw together a few reports, and that was it. It was quick and easy, and I was happy. Until it suddenly stopped working. I messed around with keys and permissions and database users, and after about a day it was all working again... until, roughly a month later, it suddenly wasn't. This went on for some time, and then, one day, it was time to bring the reports out of development and make them available to other people.

And I balked. Here it was, running on a local machine that had no other users, no onerous loads, a machine that, most days, ran only one very light application... and it was still breaking periodically. Did I really want to put up with babysitting this thing on a remote server? No, I decided, I did not want that.

So, back to the drawing board. Of course, I didn't exactly have time to research and learn a whole new reporting framework. Heck, I didn't have time to do much of anything - any work would have to be done while waiting for builds to complete or tests to run on other projects. So I buckled down and started coding: I needed a few basic statistical routines, a histogram routine, some tables, and a few graphs. Some quick-and-dirty C# took care of the stats, quick-and-dirty HTML for the tables... and the newest addition to my toolbox took care of the graphs.

I'd first run across ZedGraph a few years ago, when John Champion posted his article on The CodeProject. While it looked nice enough, I had no need for such a thing at the time, and forgot about it. But now, running across it in a frantic Google search, it looked like just what I needed. A couple of hours spent playing with it confirmed this notion: it fit my simple needs like a glove, quickly turning the dry, drab reports into slick, colorful affairs, ready for inclusion in any presentation. Best yet, it fit neatly into the quick-and-dirty ASP.NET code I'd already written.

A full day spent hacking (during the aforementioned gaps in testing...), and the new reports were ready. Fast, ridiculously simple, and perfectly suitable for XCOPY deployment.

Optimization: structure and algorithm

nospam@example.com (Shog9) — Sun, 25 Feb 2007 08:32:00 -0700

I've spent the past few weeks re-working a library that is used to construct 3D models of machines. The library accepts as input a set of options for the machine - the components that are required for it, basic dimensions, etc. - and uses several sets of rules written by the manufacturer to calculate exact positions and dimensions for each aspect of the machine.

This is a heavily-used library: not only is it used to display several different preview images of the machine as its being specified, but the output is also used as a base for several other important calculations, as well as the generation of a final set of detailed construction drawings and measurements used as input in the manufacturing process. In short, those rules are processed frequently, and there are many of them.

Therein lies the problem. This system had been in place for nearly a decade, and while it had been tweaked over the years to better handle the ever-growing library of rules and options, the heart of the beast was still chained to a decision made early on: the rules were to be pulled from the database periodically and cached, stored on disk and in-memory in nearly the same way they were stored in the DB - flat tables. While this did go a long way towards eliminating the problems of latency when communicating with a remote, heavily-loaded database, it strongly encouraged the use of some very bad algorithms. When i first started profiling, the calculations involved anywhere from several hundred thousand to several million iterations over some of the tables, with each iteration involving at least one look-up into the hash table used to store the options specified for the machine.

And remember, these calculations happen often. Even on a fast machine with plenty of memory, making non-trivial changes to the machine quickly became very, very slow. To say nothing of operations that involved a series of changes, with each change dependent on an accurate model of the machine having been calculated following the previous change!

After spending a few days analyzing the system, it became obvious that it cried for a thorough re-design and re-implementation of the class structure. Not only was nearly everything stored in a list of some sort (slowing iteration beyond even what a flat array would have provided), and nearly devoid of any intelligent indexing, but guessing at the cost of a routine was made frustrating by the reliance on MFC's old, non-type-safe collection classes: all objects were stored by void* or CObject*, all IDs were LONGs (or worse yet, CStrings!). Even identifying the purpose of a routine became an exercise in searching through code for the source of every parameter, then searching the rest of the code to extract the (otherwise implicit) requirements and constraints.

Unfortunately, I've nowhere near enough time to do a thorough analysis of the system as a whole, much less a re-write. One month is barely enough time to properly document such a system, and I knew the more changes I made to it, the less likely they would be properly tested before release. And this was hardly the only urgent project on my plate.

And this is where templates and the STL really come into their own. One piece at a time, I took the slowest routines, identified a better (usually non-iterative!) algorithm, and re-wrote just those routines. Since the new routines depended on having either an index or a fast method of filtering the rules they were driven from, I then wrote specialized containers for that data, taking into account the requirements of the newly re-designed routines that used them. LONGs became RuleID, lists of arrays became std::multimap combined with std::vector, complex filtering routines became simple look-ups on containers with complex keys. Finally, I wrote adapters for the new types that would allow them to be used with the old, un-changed routines: ID types converted to / from LONGs / CStrings as necessary, routines were provided for iteration / serialization / etc. In this way, one set of routines could be re-written, profiled and regression tested, without worrying about the rest of the system.

By the time I was seeing acceptable speed, I'd modified probably 30% of the entire library, one small piece at a time. And a good number of those changes were things like making parameters or access methods const, just so I could have a better idea of where things were actually being modified.

It's hard to be proud of work like this. The library is still a mess. In some ways, it's a bigger mess than it was before, since now there's a mix of new, type-safe, near-orthogonal code, in with the old; it's harder to know what to expect. If given the chance, I'd spend a lot more time cleaning things up... but for now, I've accomplished my primary goal in time for release. Proud? No. But satisfied.

Faster C++ compilation on VS2005

nospam@example.com (Shog9) — Thu, 02 Mar 2006 17:02:00 -0700

So after a couple years of putting up with very slow build times, i couldn't take it anymore. We're preparing to migrate to VS2005 for primary C++ development, and a 20x increase in the time needed for a full build just isn't gonna cut it. So i started going through the options, hoping there was an option or something, hoping that they hadn't made the compiler itself that much slower in the process of adding new features and increasing standards compliance.

Sure enough, there was a simple solution. Seems the "automatic" option for using pre-compiled headers isn't available anymore, and so during the conversion PCH was just turned off for all projects.

At this point, i'm going to admit that i've never given too much thought to PCH support in VC++. The only other time i've used PCH at all was with Borland's C++ compiler, where manually specifying what you wanted pre-compiled was the only option (at the time anyway). That It Just Worked on VC++ was enough for me - why mess with what works? But the downside was, i didn't have a very clear idea of what was actually going on. Put the system headers in STDAFX.H, rebuild all, check in and forget it. Upon realizing that this was no longer an option, i didn't really know what to do...

Then i found Bruce Dawson's excellent article on the subject. Going well beyond MSDN's dry descriptions of how, Bruce details the various methods for configuring, optimizing, and using PCH in VC++.

With this, i enabled PCH manually on our various projects, and brought build times back down to something acceptable (roughly 1.5x what it takes in VS6). VS2K5 is usable at last!

Now, if i could just do something about that annoying "Updating Intellisense..."

123 files modified

nospam@example.com (Shog9) — Thu, 05 Jan 2006 17:28:00 -0700

...but now, The App builds under VS2k5.

Most of it came down to code that took advantage of the broken scoping rules for for loops in previous versions of VC++. A few interesting changes though: code that had mistakenly been using the address of a function rather than the return value was my favorite.

No mapping between account names and security IDs was done

nospam@example.com (Shog9) — Sat, 23 Apr 2005 15:02:00 -0700

Or, Friday Afternoon Stupidity

I spent a good two hours staring at that message.

Well, ok, i did a lot of other things during that time also, but still, for those two hours, staring at that message was happening fairly often.

See, i was throwing in a bit of code that would disable certain features if the user wasn't a member of certain groups on the domain. The idea seemed slick, we'd use build-in Windows authentication, and so wouldn't have to distribute encrypted files, or set up our own server, or anything troublesome like that... just check if the user is in this group, and if not disable stuff.

Well, it sounded easy. And it would have been too, except i've never worked with any of this before. The most i've ever done with regards to Windows security was to do a string comparison to the result of GetUserName(). So i started Googling for info on it, and after maybe an hour of reading about LookupAccountName() and CheckTokenMembership(), i had a routine that seemed to do what i wanted, at least with local groups. Smiling, i changed the group to check against to one on the domain... Failure. "No mapping between account names and security IDs was done." To quote a veteran Windows developer, "Blast!"

So now what? I go and bring up the MSDN page for each function i'm calling, double check that the parameters are of the right type and of the right size. I re-write the memory allocation to simplify it, just in case that's causing problems. I start searching newsgroups for that error message. I list all the groups available on the domain, just in case i'd gotten the name wrong for the one i'd tried.

Finally, i read a thread that ends with the original author seeing success and admitting that it was due to a rogue space in the username. Well, i think, that can't be it, 'cause the name is hard-coded, and any spaces would be obvious next to the quotes... and as i'm thinking this, i'm already seeing the problem.

Yup. I'd only used one backslash to separate the domain and the group. Once that was escaped, everything works beautifully.

sigh... Time for a beer, a pizza, and a weekend away from staring at code.

Painless NTLM authentication in Firefox

nospam@example.com (Shog9) — Wed, 09 Mar 2005 14:23:00 -0700

I've used Firefox heavily at work ever since they built NTLM authentication in, but have always been rather annoyed at how limited it is compared to the support built into IE. With IE there is no difference between accessing an intranet site that requires NTLM, and one that requires no authentication, assuming you're already logged into the network on your machine. Firefox on the other hand, would bring up its authentication dialog for each site, prompting for a username and password. Although allowing Firefox to save the password helped reduce the trouble to simply hitting Enter whenever such a box appeared, it was still annoying, and worse yet, slowed access to these servers.

After being notified by a server admin here that i was causing frequent authentication errors to show up in the logs, i decided it was time to investigate this problem further. Fortunately, a quick Google search brought me several hints at a solution, which was soon put in place.

The fix

In Firefox, type about:config into the address bar and hit enter. You should see a huge list of configuration properties.
Find the setting named network.automatic-ntlm-auth.trusted-uris (the easiest way to do this is to type that into the filter box at top).
Double-click this line, and enter the names of all servers for which NTLM is desired, separated by commas. Then press ‘OK’ to confirm.
Open the options dialog (Tools->Options menu), and on the General page press the Connection Settings button to get the proxy configuration dialog:
Make sure the correct proxy server is configured, and that the same list of servers are listed in the No Proxy for: entryfield as were set in step #3.
Done.

Result? No more slow access, no more authentication errors, no more clearing the list of saved passwords when i change my network password (or worse yet, having to call support and have my password reset because i forgot to do this...)