index

About Visitor Code

Visitors

We have a way of password protecting user comments without password protection.

This Visitor Code thing is experimental and is now off by default. We get a little "philosophical" here... And recent changes to the code are not described here.

We are slowing adjusting all of this and this will change. Yet the basic philosophy no not requiring user registration will remain. There is a better way.

If you find this all too weird for you there is always rm -r this.

As you may have learned by now (and might not think it too outrageous if you are still reading this) we allow anyone to post comments. We just don't allow any URL links in the comments.

Again we find ourselves writing some hundreds of words of text to describe a few lines of code — we do this for two reasons: 1) to enable a thorough understanding of the code; 2) to make sure we thoroughly understand the code. We do this because if there is not a thorough understanding of the code there will be a security flaw. We chose the word "will" over "may" deliberately.

Preamble

We use the term "Visitor" instead of "User" with regard to comment submissions because we do not require "User Registration" just to submit a comment. (That one definition of the word submission is the act of "yielding" or "surrendering" is not lost on us.) Let us re-phrase: We do not want to require anything like "User Registration" just to allow a visitor to submit a comment.

Preventing comment spam is, of course, the main reason websites force casual visitors to become registered users in order to submit comments. We, um, submit, that that is wrong. There are ways to prevent comment spam (which is the topic of a separate file). But forcing users to submit in order to submit is like forcing users to accept a shrink-wrap license. We think it is wrong. We do not want to do that.

(There are, of course, other reasons for requiring users to register, but there is no need to discuss them here. We simply choose to do things this way.)

Implementation

Our visitor handling code will not be obvious, trust us on that. But we do what we do because, as we said, we do not want to impose any user registration or even any required data on visitors. Yet, we want to give visitors the option of being "remembered". And, when being remembered, to provide a way to allow a visitor to have exclusivity of his or her chosen user name.

We use what we call a name/code pair — which is not unlike a username and password, just that there is no registration process.

There are two visitor checkpoints: when displaying the comment form and when parsing a comment for submission.

There are two states of visitorship for the form display: 1) cookie set; 2) cookie not set:

        state one = no cookie
        state two = cookie set

The form inputs are set accordingly:

        state one = inputs for name and code = empty
        state two = input for name = cookie, code = hidden

Initially the cookie is not set.

A comment is allowed if 1) cookie is set; 2) the entered name/code has no matching stored name; 3) the entered name/code pair matches the stored name/code pair; which is:

        if cookie set
        if name and code are not empty and not DB(name)
        if name and code and DB(name) equals code

where DB() is a lookup function that returns the code associated with name if it exists.

In the second case (a new visitor) the name/code pair is stored in the database and a cookie is set (if cookies enabled):

        if name and code and not DB(name) then DB(name,code), set cookie

If a visitor does not enable cookies he or she will have to enter the code for each comment.

Each name/code pair value must be non-empty. There are limited length and content restrictions in our code, but that's just us. Each name stored must be unique, of course. (We store names with a character set of UFT8 and a collation of UTF8_BIN.)

There is a special case that disallows a submission: when the name cookie is defined and does not match the entered name. This could happen if a visitor, once getting a form with the cookied name in it, changes the name before submitting. A User Agent can only not display the stored name when a cookie is set (i.e. it's type is "hidden") but it cannot prevent someone from mucking with the HTML form.

Summary

If a visitor enters both a name and a code, and the name does not exist in the visitor database, the comment is allowed and a new visitor record gets created for that name/code pair.

If the visitor has cookies enabled, then she gets "logged in" with that name via a cookie. If the visitor doesn't have cookies enabled, each time she posts she would have to enter the name/code pair.

If she tried to comment using an existing name, she probably wouldn't get the code correct, so the comment would be denied.

We chose to allow anonymous comments, in that if a visitor does not enter a code, the comment is allowed and no visitor record is created nor is a cookie set. (A visitor does not even have to enter a name.) But as we said, that's just us.

Notes

1. Eventually there will be some sort of user registration code (configurable, of course). We would really like to support OpenID but find their source code to be incomprehensible!
2. We also do not use a "password" input type on the code, and not just because we are a lazy lot (which we are, but more about that later), and not just because we are sick of seeing all those "Do you want to save this password?" web browser messages! We want to let the visitors see their code as they type it. This does two things: 1) prevents errors, as typos are seen as they occur; 2) eliminates the need for a redundant duplicate field which is used to prevent such typos. It is a fallacy that echoing * characters somehow protects passwords, and may lull novice users into thinking that such hiding of their typing is some magical device that will protect them from "hackers". It may protect you from your little brother looking over your shoulder, but it does nothing else.
3. Let me tell you a story. I once installed a very popular, open source, BBS application on a website. It was really cool. It had anti-spam stuff, and user registration and validation stuff, word and IP bans, a really nice admin interface, etc. Not too long after I installed it, I started getting half a dozen or so new user accounts created every week that were simply trying to comment spam. I got so sick of that that I abandoned that BBS. And it turned out that for over two years after I did so, my website was still getting attempts to access that BBS. Hopefully, THIS will never get to the point where it has a "signature" by which automated spammers can exploit the code.