Authentication Filters - Part 1

One of the amazingly flexible concepts that WebCrossing does well is integrating into existing login/authentication systems. Because of this flexibility, it can also be a bit daunting to try and figure out how to do this with an existing single-sign-on solution that your website already has.

I will attempt to show many different ways that WebCrossing can integrate into these existing login systems by showing the ins and outs of what we call the "Authentication Filter".

HTTP - Stateless and Ignorant
First of all, the HTTP web protocol is a "stateless" protocol, meaning that each request of a web page or resource is completed and usually the connection is closed leaving the server to wait for another request. A simple web page makes many TCP/IP requests in the course of displaying the various pieces of a web page such as external CSS files, images, Javascript files, etc.

Since the protocol is stateless, there is no way for the web server to know who is asking for new information across these pages. Therefore, something must happen on the client side (browser) which identifies the user back to the server so that "state" of the user can be maintained across these page requests.

The browser can help with this in many ways including:
  1. Cookies
  2. Additional URL information
  3. HTML Header information
  4. HTTP Environmental Variables
  5. Basic Authentication

WebCrossing can integrate with any of these methods so that the user credentials can be transmitted across each page so that the perception of a user being "logged in" can be maintained.

Authentication filters are the basis for most of these login integration systems and I will start with one of the easiest, written in WCTL. This auth filter will log in ANYONE as the sysop of the site. This is obviously not practical in production, but is an easy way to bypass the sysop password on a database if perhaps the password is lost, etc.

The code for this is as follows:
%% macro authenticateFilter %%
%%   userLookup( "sysop" ) %%
%% endmacro %%

This is an obviously dangerous filter to put into place because anyone that comes to the site will be logged in as the sysop, but it serves to illustrate some points.

One of the values that are "returned" from a filter is the User ID of someone in the WebCrossing database. the "userLookup" function returns this value after finding them in the DB and then that value is "printed" to the output buffer, so the result of executing this function is to return the userID of the sysop. This then logs in the person specified by the userID.

The authentication filter is executed for EVERY SINGLE web request made to the server, so we try and make it as simple and as fast as possible.

There are LOTS more uses of authentication filters and different ways to write them, so I will continue this in future blogs on this subject.
Dave Jones
dave@lockersoft.com
http://www.youtube.com/lockersoft

Dave - a little about me...and WebCrossing History

Before I start blogging here at Webcrossing Rocks, I thought it would be appropriate to say a little about myself, perhaps to give some credibility to the information that I will be relaying.

You can read some details on my profile, but the history at WebCrossing is a bit more complicated. I started at Lundeen and Associates (L&A) back in 1993, before the WebCrossing product was even a pipe dream. We were working on a cross-platform word processing/drawing type application which would have competed with Microsoft Word in many different ways. My job was to convert everything to work on a Windows platform, which included the database, windows, drawing, mouse functions, windows events, etc. which was all written in the C language.

Even though the Macintosh platform was the where most of the development happened, (and my preferred platform of choice) my task was quite daunting and took a couple of years to get right since I was the only Windows developer on staff.

During this time, funding became difficult and L&A took some outside contracts to keep the cash flowing so we could finish our product. One of these contracts was for a web community called "The Well" based in San Francisco. They wanted a cross platform "browser" which could act like an off-line reader for their massive bulletin board system and community that they had developed over the years.

We were able to modify our existing code base to produce just such a system and added several underlying technologies like Telnet and a TCP/IP system that would work over simple dial-up modem to modem or through the VERY new Internet system that was becoming public and popular at the time.

I worked on many of those underlying technologies as well as moving these to the Windows platform. We added our own scripting language system so that we could create the many changes that the client kept adding to the system. This was called "Author" and is the basis for WCTL that is still used today.

Weeks before we were to deliver the final product for "The Well" to roll out to the public, the owner of The Well decided to scrap the entire project, which had grown to quite a good system at that time.

This was a devastating blow to our small company, but we decided to take lemons and make lemonade. Michael Krieg, over the course of just a few weeks, was able to convert our "Author" system into a very simple bulletin board/forum/community system which we named "WebCrossing" and began selling in 1995.

It was a slow start, but we became quickly well known in the relatively small field of internet companies up until the Internet bubble burst in 2000 / 2001 where we then had to downsize significantly and enter a hibernation mode.

The product continued to be developed quite heavily according to massive customer input. We were constantly changing the software to meet new technology requirements that customers asked for. It has since become what we refer to as "The Swiss Army Knife of Web Development Technologies".

It has everything you need to develop an entire website - scripting language, dynamic Object Oriented Database, SMTP, POP3, NNTP, RSS, massive scalability through source/mirror clients. You name it - WebCrossing can do it.

It was an amazing time to work for the Internet industry and a great learning experience.

I look forward to sharing some of my insights, development secrets, coding techniques, and tricks of the trade in implementing a great site through the software.

We all welcome your comments as we begin this blogging collaboration.
Dave Jones
dave@lockersoft.com
http://www.youtube.com/lockersoft

Automatically updating footer copyright dates

Webcrossing supports 2 different scripting languages: standards-based server-side JavaScript, and the older proprietary Webcrossing Template Language (WCTL). You don't have to know a lot of WCTL to develop in Webcrossing, but since WCTL can be used directly in settings fields in many Control Panel HTML fields (and JavaScript can't), it can be helpful to learn a smattering of WCTL to make your life easier. Here's an example you can paste directly into your Control Panel footer field.

If you are like me, updating the copyright dates in the footer of the sites you manage is not your idea of a fun time on New Year's Eve. But with the magic of a little WCTL, you can have automatically updating dates in the footer. And that will be your last footer date update.

Say you want your copyright date to say © 2011 My Company

This is all you need:
%% set year date(dateObj).dateFormat("Y4") %%
© %% year %% My Company


Or if it is 2011 now but you want your date next year to say © 2011-2012 My Company
%% set year date(dateObj).dateFormat("Y4") %%
© %% if year > 2011 %%2011-%% endif %%%% year %% My Company


This year it will say © 2011 My Company, and on January 1 next year, while you are sleeping in, it will say © 2011-2012 My Company.

Inheritance and the forum hierarchy

Sue wrote an earlier post about Webcrossing's object-oriented database, and the built-in objects that support forums. Objects representing folders, discussions, and messages descend from the parent Stored, and they inherit properties and methods from it that describe each object and its content and make manipulation easy.

There's another kind of inheritance available to you, one that depends on how you decide to structure your forum hierarchy. Every node you create, whether a folder, or a discussion, or an object you prototype yourself, has a parent in the forum hierarchy, analogous to the directory structure on a hard drive. You can define custom properties for any individual node. And then it's trivial for the node's descendents to access those properties.

Using Webcrossing's server-side javascript you could, for example, associate a folder with an external url, just by naming the property and setting it to a value:

myNode.externalUrl = 'http://www.someotherplace.com/somewhere';

Using Webcrossing's hierarchy support, that property is now available to any child of the node without looping. The special global function $() makes this possible. $() first looks for a method at the current location. If not found, it looks for a property at the current location. If not found, it checks the immediate parent location for a method, and if not found, a property. If neither are found, it checks the next-higher parent, etc. For example,

$( 'nodeBanner' )

will show the banner for the current node, if one is defined. If not, the function looks at the parent, then the parent's parent, and so on until it finds a node for which the property is defined, or it reaches the root of the site. As this example suggests, this works with built-in properties and methods as well as those you have defined yourself.

You can also call the function on a specific node, rather than the current location:

someplaceElse.$( 'someProperty' )

Built-in support for a hierarchical forum, custom properties and methods that are defined by reference, and the $() function all work together to unlock the power of Webcrossing in your scripting.

WCTL and SSJS duke it out [Part 3]

OK, here's where it gets fun. Part 1 was about WCTL (Webcrossing Template Language) and Part 2 was about Webcrossing's newer, more powerful scripting language, SSJS (server-side JavaScript). Now they'll both put on their boxing gloves and show us their stuff.

WCTL
Webcrossing Template Language
SSJS
Server-side JavaScript
tight integration with OODB yes yes
easy for beginners yes no
good for experienced programmers if you can get used to its limitations definitely
tag-based yes no, every string going to the response buffer must be quoted (with one exception I will write about later in a full post)
use with client-side JS easy-peasy can be a bit of a hair-puller
case sensitivity no yes
number crunching ability limited, integers only full suite of JavaScript Math methods
execution speed very fast fast
use directly in Control Panel HTML textareas yes no
error handling graceful, but little information not always graceful, but great stack traces
out-of-box scripts most are WCTL a few are SSJS
object-oriented pseudo, not really yes
has arrays no yes, plus StoredArray() objects stored in DB
function parameters no yes
variable scope very broad, across entire execution request normal JavaScript variable scope
have multiple database location objects open at once no, just current location yes
have multiple user objects open at once just user and author yes
create new object types sort of yes
bottom line blazingly fast, good for beginners, a little quirky powerful, not so forgiving, just a trifle slower than WCTL

SSJS: powerful and full-featured, not so forgiving [Part 2]

Webcrossing's second scripting language is server-side JavaScript (SSJS), sometimes referred to Webcrossing JavaScript (WCJS). What Web Crossing did along around version 3 was add support for the Mozilla Spidermonkey implementation of JavaScript.

JavaScript isn't usually thought of as a server-side language, but it's really quite rich and powerful on its own, and coupled with the OODB, you can do some really cool things. Since it's tightly tied to the object-oriented database (OODB), it's trivial to set properties on built-in forum objects.

Like WCTL, SSJS starts with the concept of "location" as the forum object at which the script is being run. From there, you can look up any other objects you want to work with. Any properties you set are automagically just saved in the database.

var someMessage = Stored.lookup( uniqueId );
someMessage.lastEditor = somebody;


But, unlike WCTL, you aren't stuck with a single current location. You can have as many Node objects available as you like:

var theFirstFolder = Node.lookup( uniqueId );
var theSecondFolder = Node.lookup( uniqueId );
var theThirdFolder = Node.lookup( uniqueId );


From there, you can do whatever you like with the first, second, and third folder objects you have open.

Same with users - no user/author dance like with WCTL.

var someUser = User.open( uniqueId );
var someOtherUser = User.lookup( name );


You can also create your own new object types based on the built-in primitive forum objects, prototype them as you see fit, and store them in the database.

As you can see, SSJS is really just plain old JavaScript, but there are some special methods added just for use within Webcrossing, like the $( someproperty ) hierarchical property-fetcher, date formatting methods, and more.

But SSJS might not be the best for beginners without any programming experience: as you would expect from a "real" programming language which is CaSe sensitive, has arrays and more than one variable type, and has functions with parameters, there is more than a small learning curve.

If you don't program defensively, it tends to throw up errors all over the page, but on the bright side, you get a really nice helpful stack trace for each error. Every bit of HTML going to the page needs to be quoted, which can eat up some time, and getting complex client-side JavaScript quoted and escaped just right in server-side JavaScript can be a bit of a nightmare sometimes.

Some of us swear by SSJS, some of us swear at SSJS, and all of us use it at least part or most of the time. When you need the power and flexibility of a real programming language, want to create and prototype your own objects, have to do something with multiple locations or users at once, or need to do some serious number crunching, SSJS is for you.

We covered the Webcrossing Template Language (WCTL) in Part 1, and Part 3 will summarize what the two languages are each best and worst at.

WCTL: fast, great for UI, but a bit quirky [Part 1]

Webcrossing's original scripting language is a proprietary, built-in language called WebCrossing Template Language, or WCTL. Some years later, the Mozilla Spidermonkey JavaScript engine was grafted onto Webcrossing to act as a second server-side scripting language. We'll cover that in more detail in Part 2 of this series.

But first, WCTL. WCTL is currently officially "deprecated," so as not to scare off new developers, but it is still supported, and it has a number of useful qualities. In other words, you don't have to learn vast amounts of WCTL if you don't want to, but if you happen to pick it up, it can be quite handy.

WCTL is a tag-based language, and everything not inside WCTL tags is HTML output to the page. Server-side JavaScript (SSJS) is, of course, just the opposite. WCTL tags are delimited by %%'s, for example:

Hello, %% userName %%, welcome back!

Because it's not necessary to quote everything sent to the page, WCTL is much faster for front-end developers writing user interface. Besides just being faster to develop, WCTL runs a trifle faster than SSJS. WCTL can be used directly in Control Panel HTML textareas (SSJS can't). WCTL at its simplest is quite accessible for the amateur site owner who wants to add just a bit of dynamic content here and there, like the simple example above. But WCTL can be quite powerful, as demonstrated by the fact that most of the out-of-the-box scripts are written in WCTL. And it's CaSe INsensitive and is very forgiving of errors, unlike SSJS, which tends to barf all over the page if you aren't careful.

But WCTL is limited in some ways, and is admittedly a bit quirky. It is not really object-oriented, has only one data type (strings, although integer math can be done), has no arrays, and you can't use parameters with functions ("macros") you create yourself (although variable scope is very broad, so in reality that's more a nuisance than a real problem).

Webcrossing has the concept of "location" (in the forum hierarchy), which refers initially to the location at which a script is being executed. In WCTL, a sort of pseudo object-oriented dot notation - %% path.someproperty %% - makes it possible to reference stored properties of the current location. To reference the values at some location other than the initial one, you can %% setPath( uniqueID ) %% to the unique ID hex number of the forum object you want to reference so that %% location %% then refers to the new location, and then %% path.someproperty %% will refer to the new location's property.

You can do the same thing with users. %% user %% refers to the currently-viewing-user, and %% author %% can refer to either the actual content author of the current location, or some arbitrary other user whose properties you are interested in. For example, %% user.userEmail %%. Or %% author.userEmail %%. To examine that arbitrary user (author) you do: %% setAuthor( userId ) %%. From there, use %% author.someproperty %%. But, if you do that - Danger, Will Robinson! - you lose access to properties of the current location and will have to %% setPath() %% to regain access. (Remember, I did say it was a little quirky.)

You can mix and match SSJS and WCTL, although there is a small performance hit for doing so. So you could write your user interface in WCTL for speed, error-forgiveness, and to save time; and call SSJS functions to provide the complicated programming that is more convoluted to do in WCTL. In fact, that's exactly what some of us do.

We'll cover the Webcrossing implementation of SSJS in Part 2, and then Part 3 will summarize what the two languages are each best and worst at.

Power and Simplicity

Despite its name, Webcrossing offers more than just browser-based content. The powerful Webcrossing engine actually integrates a full suite of internet server tools. It can not only deliver web pages through the HTTP protocol, it can also send emails (SMTP). It can provide your users with email addresses they can access via POP3 or IMAP (as well as through a simple web interface). It can be used as a news server (NNTP), or even to transfer files (FTP).

Of course, any $300 Unix box can run all those daemons. What sets Webcrossing apart is the way all these protocols are tightly integrated with its NoSQL database and its online community tools. Making your web content available as an email listserv is a simple as checking a box. Want to send every user post to an external email address? Check a box. Want to pull content from an existing listserv and repost in your community, with subjects preserved and threads intact? Check a box.

What about NNTP? Webcossing can function as its own news server. Each folder within the community can be a separate newsgroup within a hierarchy that mirrors the web interface. You can also push your content to another news server, and thereby publish it to the thousands and thousands of news servers throughout the world. You can just as easily pull content from those same news servers to post on your Webcrossing community.

And you can do all of this without ever going near a command line, or writing complicated scripts to control how emails or news postings are translated into your community hierarchy. It really is just a matter of checking a few boxes.

Power and simplicity: that's Webcrossing.

Why OODB (object-oriented database) is not a dirty word

Webcrossing's built-in server-side scripting language is JavaScript, which is, of course, object-oriented. Webcrossing also uses a NoSQL object-oriented database. Are you seeing a pattern yet?

Some people may be concerned about trying an OODB because they are so familiar with SQL, and feel they don't know much about OODBs. But in truth, there isn't a whole lot you do need to know, from a programming standpoint. You can store your JavaScript objects directly in the database without jumping through any hoops. It pretty much Just Works. No complicated SQL with required serialization, table joins or complex queries.

Webcrossing's database comes with a number of built-in, ready-to-use primitive object types. At the lowest level, there are primitive Stored objects. These are the same as a JavaScript Object, except that they are stored into the database.

All objects stored in the OODB can be accessed through JavaScript objects. Setting new property values for stored objects stores the values into the OODB and saves them on disk. Fetching values from stored objects loads them from disk automatically.

So, you can just do something like:

SomeFolder.myObject = new Stored();

Voila. Stored.

Adding properties is just as easy:

SomeFolder.myObject.color = red;

You can create your own kinds of objects derived from the built-in classes, giving you an extremely powerful tool for extending and customizing Webcrossing.




As you might imagine, with built-in users and content nodes, you can save a lot of time not reinventing the wheel. So take the leap. Try an object-oriented database with an object-oriented programming language. You might never turn back.

WebX != WebEx

Before we get too far here, let's be clear about who we are and what product we're talking about.

One thing that irks me to no end is people confusing Webcrossing (often abbreviated WebX, like in our URL even) with Cisco's WebEx product. I discovered this tweet just a few weeks ago: "Bayspire, current owners of Web Crossing (née WebEx)..."

AGH!

But I have to admit there are, unfortunately, reasons people get confused:
  • Cisco owns the domain WebX.com. So some unwary surfer looking for Webcrossing.com would end up at WebX.com and the wrong product. Since they had lawyers with bigger biceps than Webcrossing's, it stayed that way. (Right now a surfer looking for Webcrossing.com lands at Bayspire.com, but I digress...)
  • The old Webcrossing logo - which I believe predated the existence of WebEx - didn't help, as it used a swoopy red X between the words "Web Crossing."

    old logo

    [Trivia fact: A large version of that logo was actually animated on the Webcrossing website splash page way back when people actually had splash pages]
  • Before the advent of actual WebEx-style web conferencing, the word "conferencing" used to refer to a large-scale web forum like, say, Salon or Electric Minds (archive) or the WELL. Along comes WebEx, offering - you guessed it - web conferencing.
So next time you see or hear somebody referring to Webcrossing as WebEx, set them straight, willya?

Webcrossing: the best [fill in product definition here] you never heard of

Webcrossing was a pioneer; it was Web 2.0 when there barely was a web.

Back in 1995, Webcrossing was born as a product from a software group named Lundeen and Associates, headed by Tim Lundeen, a brilliant developer with a track record of success with mass market software. Tim was the lead developer for Apple's port of Microsoft Works.

Since the beginning Webcrossing has been about user-generated content and "the participatory web," providing industrial strength forum software to big-name companies. It has been lauded for its extreme customizability and flexibility, and its ability to support large sites. (A single discussion on CNN once generated a quarter million posts during a US Presidential race and Webcrossing didn't blink.)

Since then, Webcrossing has grown and evolved into forum software, content management, social networking, and more. It's a multi-protocol server (http, smtp, pop, imap, nntp, ftp) tightly integrated with an object-oriented NoSQL database. There are dozens of plugins and a web application development platform with built in content and user objects that can save tons of development time. In reality, Webcrossing can actually be just about anything you can dream up.

Which explains why you may never have heard of it. It's a difficult product to market, to categorize, to explain in an elevator pitch.

And that's where we come in. Some of us are employees of Bayspire, the current exclusive licensee for Webcrossing support, service, and sales. Some of us are independent developers with a lot of Webcrossing experience. All of us share an unbridled enthusiasm for the Webcrossing platform, and we are are dying to tell you just what we think is so cool about it.

So let's get started, and we'll give you the grand tour of Webcrossing.  Soon you'll know why WebX Rox!