Wiki and Wiki; What is Wiki?!?

I've had a number of people talk to me lately about wikis, and from these conversations it has become clear to me that at least a few are unclear on what they are about. So, I'll take a stab at defining them.

First and foremost, wikis are about authoring a set of static HTML pages. That's it. If you're trying to do something with a wiki that would be hard to do well with a set of free form HTML pages written using Front Page, then you probably won't do it well with a wiki. A great example of this is discussions: wikis pretty much suck at threaded, back-and-forth conversations, because free form, static web pages pretty much suck at this. Note that more constrained or more dynamic web applications might still do a decent job (think message boards), but a big ol' pile o' HTML is a long way from being a discussion board. 

Still, for all the things it isn't good at, there are lots and lots of useful things you can do with a set of hyperlinked HTML pages. So why wiki? Well, a wiki gives you two things:

1. Collaboration.


2. A simple authoring language.

The collaboration one is the one you generally hear about most. The idea that lots of people can walk up to your website and author their very own page, or even edit one that you wrote is totally crazy-sounding, but turns out to be immensely powerful.in a lot of situations. Of course, because we can't trust everyone not to deface the shared page, most (not all) wiki engines offer version control to make it easy to undo what others have done, but I don't think version control is really central to the Zen of wiki.

However, I happen to think that the other major facet of wikis is every bit as important as the first: the fact that they introduce a simple authoring language. For example, if you look at the language that FlexWiki offers, it's simple do make something bold - you just *surround it with asterisks*. The wiki engine then interprets this into HTML that makes the enclosed text bold when the page is viewed. While this isn't much simpler than surrounding the same text with the equivalent <b> tags, it turns out that this syntax (and the other syntactic elements a good wiki language offers) are just _enough_ simpler to lower the bar on contributions to the point where people are actually willing to spew their brains onto a page. 

It really says a lot about human laziness that harnessing its power can do so much. :)

DefaultValue and XmlSerializer Don't Mix?

Maybe someone can explain to me why this:

using System;
using System.Xml.Serialization;

public class Foo {
  [XmlAttribute]
  [System.ComponentModel.DefaultValueAttribute("three")]
  public string value = "three";
}

public class App {
  public static void Main() {
    XmlSerializer ser = new XmlSerializer(typeof(Foo));
    Foo foo = new Foo();
    ser.Serialize(Console.Out, foo);
  }
}

produces this:

  <Foo />

whereas if you remove the DefaultValue attribute, you get this:

  <Foo value=”three” />

which is what I would expect. This is particularly troubling, since wsdl.exe will generate proxies that use System.ComponentModel.DefaultValueAttribute when it sees schema types with fixed value constraints.

I have to assume this is a bug in System.Xml.Serialization, but I'm willing to believe that there's some subtlety I've missed. I've confirmed this behavior in CLR 1.1 and 2.0.40607.

I Won't Miss It

Via Tim Bray, this amusing little story about how IE is not quite as universal as it once was. I for one, wouldn't miss it for a second if it went away tomorrow: I use Firefox, which is far superior.

Actually, I would miss it a little, but only because there are a few important sites that are busted in anything but IE. Sadly, all FlexWiki sites fall into this category (but hopefully not for much longer).

Mixing Forms and Windows Authentication

A client of mine wants to provide single sign-on (SSO) capabilities in their web application, so that users don't have to type in their domain password when authenticating to the application. The twist? Only some users of the application use SSO: the rest have accounts that exist only in the application database. So we couldn't just flip on “integrated authentication” in IIS and party on. But with the help of Keith Brown, I was able to figure out a pretty nifty solution.

The trick was realizing that if you enable both “anonymous“ and “integrated“ authentication for a particular virtual directory, the browser won't try to authenticate to the web server until it receives a 401 (Unauthorized) back from the web server. But you can issue your own 401 any time you like! So what I did was to just set up Forms authentication as normal, but also provided a checkbox on the login form that said, “Use my network credentials.” Then, in my login form, I did something like this:

public class Login : Page {
  protected Label ErrorMessageLabel;
  protected TextBox UsernameTextBox;
  protected TextBox PasswordTextBox;
  protected CheckBox CheckBox1;

  public void Page_Load(object o, EventArgs e) {
    if (IsPostBack) {
      string authenticatedUser = null;
      if (CheckBox1.Checked) // Use their network credentials
      {
        string user = Request.ServerVariables["LOGON_USER"];
        if (user.Length == 0) // They haven't provided credentials yet
        {
          Response.StatusCode = 401;
          Response.StatusDescription = "Unauthorized";
          Response.End();
        }
        else // They have
        {
          authenticatedUser = user;
        }
      }
      else // Use the username and password they provide
      {
         if (IsPasswordOK(UsernameTextBox.Text, PasswordTextBox.Text)) {
          authenticatedUser = UsernameTextBox.Text;
        }
      }
      if (authenticatedUser != null) // They authenticated successfully
      {
        // Issue the Forms Auth cookie and send them on their way
        FormsAuthentication.RedirectFromLoginPage(authenticatedUser, false);
      }
      else // They didn't
      {
        ErrorMessageLabel.Text = "Invalid username or bad password. Please try again.";
      }
    }
  }
}

What this does is - when the user submits the login - check to see whether they want to authenticate by providing a username and password (normal Forms authentication) or whether they want to authenticate automatically, using their logged-in credentials. Right now, I'm figuring this out by having them explicity check a checkbox, but I do lots of other things. For example, I could have them always enter their username, and then go look in the database to see whether they're supposed to get a SSO login or a normal one. Or I could have them check the checkbox once and remember their settings forever after in a cookie.

Whatever mechanism I decide on, the trick here is that I can force the browser to authenticate by sending back a 401. Then, in subsequent visits, I can check the LOGON_USER server variable to see if the authentication was successful or not. If it is, I'm perfectly welcome to issue them a valid Forms Authentication login, secure in the knowledge that the user has proven knowledge of their password to IIS already.

If the user is using IE, the authentication will happen automatically, using whatever credentials they're logged in to the client machine with. It works in Firefox, too, but they get that little username/password popup dialog box. Oh well - maybe the Firefox people will add auto login in a future release, or someone will write an extension. But failing that, providing SSO only to IE users is good enough for us.

Keith Brown Seeks Help - See Your Name Up In Lights

Keith was helping me out with an interesting security problem yesterday (more about that in another post), and he pointed me to his online book as a resource for some code I needed. I'd read almost all of it already, and we fell to talking about how it would be to port it to a wiki format. After all, it's a series of interconnected pages that occasionally need to get updated, which is pretty much the definition of what a wiki is good at.

Well, I wake up this morning and discover that he's already started moving the darn thing over. And he's looking for your help to finish porting it. I've already signed up to help - you should, too: being part of distributing good information about security is a community service.

MIT Grad Wins Miss Massachusetts

While others may have different preconceptions about women at MIT, I've always known there are some great-looking women there...after all, I married one. Now, an MIT grad has won Miss Massachusetts and will compete in the Miss America pageant. The coverage here is a bit condescending, but her take is interesting nonetheless.

Announcing the Pluralsight Wiki

Being as involved as I am in FlexWiki, it seemed odd to me that I have a repository of articles (i.e. CraigWriter) that I edit once in a while that isn't in wiki form. After all, I've spent a large chunk of my free time in the last six months writing tools to make editing FlexWiki easier. So this weekend, while I was in Minnesota attending a wedding of a close friend, I found myself sitting around my parents' house with no broadband Internet. After recovering from email withdrawal, I decided it was a good time to port my content to the heretofore empty Pluralsight wiki.

And so I have! This change of technologies brings several benefits:

1. It's easier for me to edit things in real time.


2. I can ditch the hand-rolled code I wrote to support my articles.


3. Other people can contribute more easily.


4. The wiki has a series of RSS feeds so people can find out about changes and new articles.


5. Since FlexWiki is open source, we get the benefit of any improvements the community makes, without having to wait for Craig to get free time.

I think I've got everything moved over except the translations of my Direct3D tutorial. Because they're not in English, it's a bit harder for me to make sure I got everything right, and I'm punting it for now. I do plan to move those as well, though, after I recover from being offline for four days. I'll also put up redirects for the existing repository before too long.

In the meantime, have a look at the new wiki and let me know if you see anything wrong, stupid, or broken.