The site you are viewing is a member of the ATI Network. All ATI Network sites share a common authentication system - even though the network spans multiple domain names. Logging in on one network site automatically logs you in to all the others, and leaving all network sites automatically logs you out of the entire network. How is this done? Read on:

How Sessions Work:

Pretend like you are a webserver. Your entire life is spent serving pages to clients over the internet. All you know about a client is what it tells you when it asks for a page. When a client sends you a page request, it looks something like this:

GET /index HTTP/1.1
Host: theati.net
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.2) Gecko/20060308vFirefox/1.5.0.2
Accept: application/x-shockwave-flash,text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive

This is all you need to know to serve them a page. But how can you tell different clients apart? How can you tell a guest from a registered user?
Each user must be given a unique ID, and that id must be sent along with each page request. This will allow you (the server), to reference each user to the data you have stored for that user, and customize the page according to their needs.

There are three main ways to get clients to send an ID along with their request:

1. The most obvious option is to embed their id (in the form of GET data) in every url they visit by rewriting "on page" links.
   There are at least three problems with this approach:
   
   
   1. The first is with search engines. When a search engine visits a page, and has an id assigned to it, and has all the links rewritten to contain that id, every url it stores in its index will contain that id.Every person coming from that search engine will automatically "inherit" the search engines session. Worse, the next time the search engine comes back and you assign it a new id, all your sites links will appear to have changed. The search engine may get frustrated and leave!
   2. Another problem is with users copying urls. When an authenticated user copies a url out of their address bar and emails it to their friend, posts it to a forum, etc, their session will be "stolen" by anyone who visits that url.
   3. The final problem comes with histories. If a user logs into their account at a library or other public computer, completes their business, logs out, and leaves the computer, their session is "stealable" by anyone! All the next user of the computer has to do is press "back" a couple times, and they are logged in as the previous user!
      
2. An extension of the first technique, it is possible to use javascript to detect link clicks, rewrite the link hrefs to a hidden form's action tag, and submit the form along with the session id in a hidden field. While this does get around the url copying issue, it adds a requirement for javascript and most browsers display an incredibly annoying "are you sure you want to go back?" dialog for any pages containing postdata.
   
3. The best way is to give the client a cookie with their id inside, and have them give it back with every subsequent page request.
   The benefits of cookies are significant over url-based session preservation:
   
   1. Search engines, which generally don't accept cookies, are never presented with "changing" urls!
   2. Since cookies are not stored in the url, they can not be accidentally copied!
   3. Since logging out involves deleting the cookie from the client's computer, sessions can not be "hijacked" from the browsers history or cache!
   
   Cookies are less than perfect, however. Some people do not accept cookies, or may have their computer's date so far off that the cookies are deleted instantly. They are also not multi-domain. Some browsers reject cookies from all domains other than the currently visited one because of privacy issues. There is a way to work around this! Keep reading to find out how...
   
   Note that cookies and urls can both be stolen using techniques such as xss or a packet sniffer, so don't just assume your data is safe!

In summary: for most applications, cookies are better for session preservation than url rewriting. The rest of this article discusses how to use cookies to their full potential!

Multi Domain Cookies:

Since most browsers won't accept cookies from offsite domains, and since the browser must have a cookie for a domain to be authenticated in that domain, and since we want users to be able to log in to multiple domains at once, we will need to use a tool called iFrames to load cookie setting pages from each domain in the network on each network page.

How does it work, you ask? Simple. For our example, we will be setting up a network with three domains.When someone logs into d1.com, every subsequent page will have the following html appended to it:

<iframe xsrc="http://d2.com/loadcookie?id={SessionId}" width="0" height="0" frameborder="0"></iframe>
<iframe xsrc="http://d3.com/loadcookie?id={SessionId}" width="0" height="0" frameborder="0"></iframe>

This instructs our client's browser to request a cookie setting page from every other domain in the network. When that page is requested, the server replies with the following:

HTTP/1.x 200 OK
Date: Sat, 22 Apr 2006 02:16:05 GMT
Host: dX.com
Cache-Control: no-store, no-cache, must-revalidate
Set-Cookie: id={SessionId}; path=/; domain=.dX.com
Content-Type: text/html

Note that there is no expiry date set for the session cookie. This instructs the browser to delete the cookie as soon as the user's "session" ends, which is when they quit the browser. Below we will use javascript to delete the cookie when they leave the site, but this is there for users that don't have javascript.

Once finished, the browser will have separate cookies stored for every site in the network. No matter which domain the client requests a page from next, they will still be logged in!

You may be wondering why we don't instruct the browser to cache the iframes, and save several http requests per page. The reason is that since the cookies store the user's id, caching the iframes would allow session hijacking by loading the iframes from the browser's cache.

Auto Logouts:

Many sites "deactivate" sessions after a specific amount of time. They assume that if your session has not requested any new pages within a couple of hours, you probably aren't still sitting at your computer.
While this is better than not deactivating them at all, it has several flaws:

1. Just because your last page request was 10 seconds ago doesn't mean you are at your computer! People can log in to their accounts at public places, complete their business, and then leave the site. Even though they may think their data is safe, in reality the next person to visit the site within the next couple of hours is logged into their account!
2. People often have certain pages open for several hours at a time intentionally; especially when they are writing content. Imagine the frustration of spending hours writing an article, pressing submit, and being greeted with a login page after your article (in postdata) is lost in thin air!

While these problems can be mitigated by making it very clear to users that they are not safe till they have pressed "Log Out" and writing a complicated postdata preservation system, there is a better way!

Using javascript, it is possible to automatically log users out. Below is the code that does the trick:

function doCookie() {
var now = new Date(); //Create a date object
now.setTime(now.getTime() + 3000); //Set the object's time to three seconds in the future
document.cookie = "sessionname=sessionid; expires=" + now + "; path=/; domain=.thisdomain.com"; //Update their session cookie!
}
setInterval("doCookie()",1000); //Run function every second

As you can see, all it does is run in an endless loop, every second setting the cookie to expire three seconds in advance. When a user requests a new page on the site, The cookie is carried to the new page, and they are logged in. When they leave the site, the loop stops, and their browser automatically deletes the cookie within three seconds.

If the user doesn't have javascript, you can display a "be sure to remember to logout" message using the <noscript> tag.

Bringing it together - Conclusion:

Combining the iframe technique with auto logouts is easy, and provides an awesome session managing system!
All you have to do is add the javascript doCookie() code to the page the iframes request. That way when the multidomain iframes are loaded, the infinite cookie setting loop is instantiated for every domain in the network.
Whatever domain in the network the user requests by clicking a link, they are sure to have the session cookie for it. And when you leave the network, all the cookies delete themselves automatically by timing out!

Although I did invent both techniques described in this article on my own, I am now beginning to see some instances of iframes used as described here. As far as I know however, this is the first ever documented usage of javascript to automatically deactivate session cookies! And its nearly certainly the first use of them together! If you know of someone else using the javascript system, please tell me. And if you write an article about it, credit would be appreciated! :-)

You should now have a thorough understanding of the basic concepts behind http sessions, and a couple tricks up your sleeve for making them even better!
I hope you find many creative uses for the techniques presented here, and take them to new levels! Please post any ideas you have for improving these techniques in the comments.

1. >> The Swashpack Two players worth of pieces
2. >> The Rules Dispute resolution has never been easier!
   Our rules all fit on a single page :-)

Greetings everyone!

I just added a sticky system to PlexPedia, which will enable moderators to feature the finest content on this site for everyone to enjoy. I also added a new "removed" state for posts, which will make it easier to permanently bury blatant spam and other items that serve no purpose.

Notes:

• Please don't "bam" things anymore - the sticky system should serve this purpose admirably without adding useless posts to the most important of topics.
• Moderators - sticky only the very best content, and possibly rotate the stickies if you have a lot of content that should be featured. We should never need more than ten simultaneously stickied items, for example.
• "Remove" only threads which are completely devoid of value. Most content should be switched to "Resolved" after it's useful life comes to an end.
• Hearty thanks are due to Achilles - who inspired me to create an official sticky system by building his own automated state toggling machine, as well as reported several important security flaws.

I also just fixed some other PlexPedia oddities, such as the display of "About" pages for usernames with dashes, and several permission escalation attacks that enabled non-moderators to alter the state of threads.

I am currently in the process of consolidating my domain names, web servers, and file servers into several manageable accounts - ATIServer sites, and my personal email account may go down for an hour or two later today.

Great progress has been made on the next Mars Explorer for iPhone, and a release is imminent. I am striving for biweekly app releases for the mext month or two, one of which will enable Whirld support. So - get your block worlds ready and polished, they are about to take on a whole level of relevance!

In other news, the next release of Syn3h (which is still a couple weeks away) should be a fully viable Mars Explorer replacement with finalized keybindings, a perfected GUI, vastly simplified camera systems, and excellent reliability.

All the best,

-Aubrey

(Specifically those of you inhabiting the Unites States of America)

With the presidential elections near at hand, I would like to take this opportunity to share my thoughts with you on the important civic duty of voting. I want to encourage you to vote for principle, and not to waste your vote on a candidate that would horrify our founding fathers.

Yes, game theory is important. In certain cases, I agree that it could make sense to cast a vote for someone that isn't your first choice to help prevent someone that would be your last choice from becoming the president. But in my opinion, arguments like the above have no place in discussions regarding this election.

As far as anyone can tell, Obama may not be a natural born citizen of the USA, and would therefore be constitutionally ineligible to hold the office of president. Both Obama and McCain have contemptible positions on the sanctity of human life. Neither Obama nor McCain have any respect for the 2nd amendment - or the rest of the constitution, for that matter. Listen to them debate - they have few things to offer besides socialism and meaningless, empty mantras of "change" and "straight talk".

As many of you know, I have long supported Ron Paul - and although he has switched gears to the Campaign for Liberty, Chuck Baldwin is now carrying Paul's banner.

I honestly don't expect to see a "third party" candidate win the election - but by voting for someone you can truly support, you can at least have a clear conscience that you weren't a party to one small step in the gradual demise of our once-great republic.

Below is a short video I produced nearly a year ago.
Before you cast your vote this year, please take a minute to consider the implications of the course you are taking.

-Aubrey

• Mars Explorer used to have a "tutorial" level built into the game - but I removed it because of technical reasons, and also because it was never very elegant to begin with.
• We currently have a bunch of boring text I wrote to provide a basic introduction to the game plastered on the "Play" page, which I doubt that new players ever read.
• In just about every game I join these days, there is a player or two typing things into the messaging console such as "How do I fly?", "What's the point?", and "Stop NQSing, you AnNoYing n00b!!".