Anodyne Development Blog

Every couple of weeks, the Anodyne forums will have a question asked about how to install a skin or rank set.  It’s a fair question, but it’s tough when you’ve answered it a hundred times over the years and people don’t read FAQs or do a search on the forums.  While Nova can’t solve people’s inability to search before posting, it does attempt to tackle the install issue with a feature that allows quickly installing skins and rank sets.

One of the big changes with skins and ranks was grouping them together into system catalogues.  Doing this gave us a lot more flexibility for manipulating the skins and ranks, setting defaults, dealing with deleted skins/ranks and setting statuses for skins/ranks.  The original thinking was that installing a skin or rank was much easier this way because you’d just click Add a Skin and fill in the form and be done.  But as we started to think about it, one thing dawned on us: people are lazy.  As harsh as it sounds, it’s true.  People are lazy and they want to do as little work as possible.  Fair enough, but when someone has slaved over a skin for weeks, they’d appreciate getting credit for the skin.  A lazy admin might not put the credits in the skin, thereby screwing the skin developer over.  I’ve been in that situation before, so I can certainly sympathize.

To solve the issue, we’re using YAML files to store basic skin information like name, location, credits, the sections, etc.  The YAML file is placed in the root of the skin where Nova can look for the file.  If it finds the file, it’ll prompt the user that there are uninstalled skins.  All the admin needs to do then is click on the install button and Nova does the rest.  All the credits and information remain intact and the process has happened almost instantly.  The same thing goes for ranks, too.

As we put the finishing touches on the feature, the flexibility of such a solution really hit us hard.  One of the things we’d been struggling through was the most efficient way to handle shipping multiple skins with the system that related to different genres.  The only thing we could come up with was calling the skins the same thing then hardcoding the information into the install files.  Only problem was that it relied on us maintaining as many install files as we have genres.  Wildly inefficient.  Then it dawned on us, we can use Quick Install just without the user interaction.  We hardcode the default skin in to the install files since it’ll be the same for all the genres then simply ship whichever skins we want with each genre.  After that, we use Quick Install to simply install whatever skins are left besides the default one.  The same thing happens with ranks.  It means that a game master can throw a handful of skins and ranks into the proper places before installing and when the system is done installing, there are all the skins and ranks they wanted (assuming the developers have used the Quick Install files … all of Anodyne’s stuff will).

Quick Install was one of those features that just kinda hit us and after we did the legwork we realized it’s potential.  Those are the best kind of features!

CodeIgniter’s structure is built around the idea of re-usable libraries, helpers and models and we’ve taken that concept to the nth degree in Nova by building our own authentication library to handle things like logging in, checking login attempts, setting session variables, setting cookies and much more.  The best part about the Auth library though is that it’s available to any developers to use for checking a user’s credentials or hashing a string!

I realize this is a topic that the average user is going to read with glazed eyes, so I’ll do my best to keep the technical details to a minimum.  Essentially, the library is a PHP class that handles checking a user’s credentials and passing information around the class for doing things like setting session variables or checking if a user is a system administrator.  Because the Auth library is separate from the login page, it means we can reuse those components elsewhere in the system, giving us a whole new level of flexibility with our components, something SMS never had.

Why would a developer care about this?  Being able to verify if a user is a system administrator allows a developer to create a page with logic to show a link or different components based on that without having to manually write the code to do so.  More to the point though, building the Auth library like this has allowed us to add a killer feature to the system: remember me.

The Nova login page now includes a check box that, when checked, will set a cookie with the user’s username and password.  If a user goes to the site and has that cookie set, Nova will automatically log them in so they can continue with what they’re doing without interruption.  By default, the cookie will be active for 14 days, but that setting can be changed from the config files.  For the span of a few weeks a few years ago, several people requested the feature, but CodeIgniter made it incredibly easy to add this feature.  How easy?  The entire authentication system was built in 2 days as opposed to the weeks it took to build and tweak the SMS authentication system.

It’s getting real now!

This morning, I made the official announcement that Nova 1.0 will be released on April 15, 2010 at 11:59p ET.  Kind of a weird release date, right? A Thursday night just before midnight. What gives?

Like I mentioned on the forums, SMS 1.2 was first released to the world on April 15, 2005 and I thought it was only fitting that if we were going to be making SMS obsolete, we should do it on the anniversary of its original release. About a year ago, I picked that date and kept it to myself until a few months ago when I quietly told some people who work closely with Anodyne about the plan. They all loved the idea and it’s been smooth sailing since.

Because the release date is a Thursday, it needed to be in the evening and just shy of midnight ensures everything can be backed up and rolled out with time to spare. There will be more launch day details coming over the next 6 weeks, but until then, mark your calendar and make sure your SMS site is running at least version 2.6.9 to be ready for the upgrade!

Most people will give you a confused look when you talk about User Access Control, but really, a simplified explanation is that it’s a system that tells Nova who can and can’t do stuff.  Starting with SMS 1.2 all the way up through SMS 2.4.4, Anodyne employed a rudimentary access system that consisted of static levels.  If you had level 5, you could do everything, but if you had level 4, you couldn’t do things X, Y and Z, but you could do everything else.  Obviously such a system is pretty limited and doesn’t give game masters much control.  To combat that, SMS 2.5 introduced a new system where admins could choose exactly what pages a user had access too, but even that was too bulky because each user was their own access entity.  SMS 2.6 added the ability to set the defaults for pre-defined groups, but that doesn’t help when you want to change the access for all standard players in the system.  Nova takes the best of these ideas to create a role-based access control system.

Roles are simply a series of pages and, in some cases, access levels that are grouped together.  For instance, a power user may have access to 15 admin pages while a standard user only has access to 8.  Instead of assigning those pages to a user’s access like SMS does, those items are tied together into a role and that role is then assigned to the user.  This has the advantage of storing less information in the user table, but also allowing admins to change the access levels for everyone in a group simply by updating the role itself.  The next time the user logs in, those changes are reflected because every time a user authenticates to the system, it goes out and gets a fresh copy of the role pages to use in the access array.

So what if you have a user who’s acting up and needs to have their permissions scaled back?  Roles can be duplicated with the click of a button, meaning that Joe can have his own access role that is unique to him and his needs.  Once you’ve duplicated the role, simply make the changes and save it then assign that role to Joe and the next time he logs in, he’ll have those restrictions applied to him.

The new User Access Control system in Nova is far more powerful and flexible and provides ample opportunity to build on the system later for even more power!

I’d be remiss if I didn’t spend at least a little time talking about the major security overhaul that happened in Nova.  While most of it is under the hood and handled by CodeIgniter, we’ve taken our own measures to secure your site even more than SMS.  Security starts with the foundation and we’ve chosen a framework that, while fast, put security at a premium.

At the very base, it starts with comprehensive SQL injection protections to make sure a malicious user can’t destroy your database from the outside.  Using CI’s built-in Active Record database class, we’re assured that all inputs are properly escaped before any attempts are made to put them into the database.  Anodyne focused heavily on this type of vulnerability in SMS 2.6 (and subsequently dropped support for SMS 2.5 because of the same issue) and using the framework’s built-in tools has allowed us to maintain protection against such attacks.

One area that received a lot of attention as well is in the area of Cross Site Scripting attacks (XSS).  Some of the most common vulnerabilities in web applications are their vulnerability to XSS attacks.  Again, we relied on CodeIgniter to do the heavy lifting here with a whole slew of XSS filtering done before any data is handed to the database.  This helps us ensure that all of your information and your database is safe!

A final item we addressed during the course of development was brute force attacks.  Hackers will sometimes set up servers to cycle through a dictionary and attempt repeated logins of a web application in hopes of finding a username and password they can use to get in.  Not only is that a drain on server and network resources, but it potentially exposes your data to hackers if you don’t have a very secure password.  Nova addresses that issue head on by limiting the number of logins a user can attempt to 3.  If there are 3 unsuccessful attempts, the system will lock the user out for 30 minutes before they can try logging in again.  It may seem annoying if a legitimate user runs in to this, but in the long run, it’s worth it to prevent hackers from brute force hacking your site.

As you can see, security was a pretty important issue for us, but we wanted to make the additional security as transparent as possible.  We don’t want the system prompting you for everything it has to do; it should just be secure from the start and that’s been our goal since day 1.