Amusing comment from my last entry by Aaron:

Roebot (guest)
Comment posted on October 29th, 2007 at 10:46 PM
LOL, "Today, I cut off the dead leaves, watered the plants for the first time ever, and gave all the leaves a nice cleaning." Did you do it in the nude while you weeped sweet sweet tears?

Yes, after setting the mood with some scented candles and my Fiona Apple CD!

. . .

So one Tabulas-related feature I've been working on are domain aliases. After switching over to sub-domains, it finally became possible to map domains to their sites. After a little bit of hacking tonight, I created a test Tabulas site: http://kidwest.tabulas.com and mapped kidwest.net to it.

The two hardest problems for this feature is smart URL mapping and cross-domain cookies.

Smart URL mapping means that when you come into your domain, it doesn't map to some other domain. TypePad doesn't do very smart URL mapping - take a look at CuteOverload.com; the home page is an iframe to the account http://mfrost.typepad.com/cute_overload.

One can assume if a Tabulas user pays money to map some domains to their account, they want their URLs to be correct - they want to seem like they "own" the site, not that they want to own a domain which is an iframe to their real site (LAMMMMEEE).

You'll notice when you come in through either the kidwest.net domain or the Tabulas URL (kidwest.tabulas.com), the URLs smartly rewrite themselves. One place that has not been updated has been the friends' list - if kidwest is your Tabulas friend, when that link appears on your friends' list, it should link to kidwest.net, not kidwest.tabulas.com (this will be done, eventually). The goal is that getting a domain name for your Tabulas will make it seem like you don't run Tabulas at all! (No URLs or ANYTHING!).

This poses the second problem: How do we handle cross-domain authentication?

A short background for those of you who are not tech-savvy: cookies are a short snippet of information that your browser stores that identifies you. When you log-in to any site (like Tabulas), your browser stores a little piece of information that says "You are Roy of Tabulas". Unfortunately, a website can only set cookies for its domain - Tabulas could never set a cookie for Yahoo! (or vice-versa).

In the case of Tabulas, what you see depends greatly on your logged-in state. There are many users who rely on friends-only (or friends-locking) of journals; if visiting your domain-ed Tabulas account logged your friends out every time, it'd quickly render your Tabulas pretty useless!

I had been tossing this idea around for a while - there seems to be a few ways to approach this:

• OpenID - the easy one, but it doesn't handle automagical login component, plus Tabulas doesn't have OpenID support yet
• Google seems to use iframes to do some magic when logging in - frankly I know nothing of this process, and my short 20 second Google search yielded no results, so I passed. Embedding an invisible iframe onto every Tabulas page didn't seem viable - a lot of users really take liberty to the "You can embed anything into your template" mentality by doing all sorts of crazy overrides - I've long since given up trying to force any type of markup loading with all the crazy templates out there.
• Use some sort of tricky cookie-detection and crazy 301 redirects to accomplish this task

I decided to take a stab at using 301 redirects and using a pseudo time-bombed hash to try to accomplish this. This is how I hacked it up:

1. You request kidwest.net and Apache forwards the request to Tabulas
2. Tabulas checks to see if you've already been authenticated into this domain with a cookie (You'll notice visiting kidwest.net when you're not logged in creates a "tabcheck" cookie with a "true" value)
3. If this authentication check cookie doesn't exist, then create it, and redirect to the tabulas.com domain - which then sees if you have a valid tabulas.com cookie
4. If you do, it creates a time-bombed hash and stores your cookie information on the server and redirects you back to a special location on your domain, which retrieves the stored cookie information and issues it to you.

Sort of simple, sort of hacky, but it seems to work in my 10-minute tests. Of course, the caveat is that if any browser isn't accepting cookies, this whole process gets hosed - you'll be stuck in an endless loop on step 1. That's totally not cool, so I'll have to rack my brain a bit more to figure out a way around that.

The problem after you issue the cookie becomes cleaning them up - how can you know when you log-out that all your cookies across all your domains have been cleared?

There are two approaches here:

1. The server actually stores the state of which cookies have been duplicated across which host names - upon logout, I can keep 303 redirecting between all the domains you visited, cleaning those cookies up.
2. When you log-in, the cookie hash generated uses a server salt; I created a server salt so that I could invalidate all logins at once by changing a string. I can extend this to create a user-specific salt which gets blown up every-time you logout: in this situation, logging out from the main tabulas.com domain would implicitly hose all your logins from other domains.

Option 1 seems safer, but it's a total mess to code (maintaining constant states is annoying). Option 2 seems much easier, but it'll have to be thoroughly tested to make sure that cookies don't collide with one another.

If anybody else knows a better way to solve this problem, please drop in on the comments. I'm going to continue experimenting with this feature, cause I'd really like to release it on Tabulas soon! :)