Programming

After 7 months a new version of phpTodo has arrived. I've spent the last month or so working on this and polishing it up. I think I have a pretty decent release put together.

New additions include a "Next Action" field, validated RSS feeds, UI enhancements, and tons of bug fixes. You can read all about the enhancements and bug fixes in the release itself, so head over and download it!

Future plans include adding ATOM 1.0 support, sub task support (todos for your todos!), group support (so you can assign a single task to multiple people), and more. I'd like to eventually migrate into an entire management system that can be used for project management.

I'd love to hear any feedback regarding this project. This is my first sourceforge project and really the first open source code I've released into the wild. So please feel free to leave me comments!

Gamasutra has some news about Microsoft's XNA Game Studio Express, a game development tookit geared towards the amateur/hobbyist developer. From the article :

"The details of the new tech are as follows: XNA Game Studio Express will be available for free to anyone with a Windows XP-based PC, and will provide them with what's described as "Microsoft's next-generation platform for game development." In addition, by joining a "creators club" for an annual subscription fee of $99, users will be able to build, test and share their games on Xbox 360, as well as access a wealth of materials to help speed the game development progress."

So it looks like Microsoft is taking the first steps towards making the need for modchips obsolete! Maybe. According to the article, the content created won't be available to "regular" 360 owners, just to those who are part of the creator's club. However, they go on to state that the content may be available via Xbox Live Arcade (XBLA) at some point in the future. It's not explicitly stated, but it looks like PC owners will have access to the content regardless of membership.

Other companies have already pledged support. GarageGames has already ported their Torque Engine over to the studio, and Autodesk has confirmed support for their FBX file exchange format. Apparently some universities and game development schools have decided to add the studio to their curriculum and will use the XBox 360 exclusively. While I'm not sure I like the lock-in to the 360 console, it is nice to see awareness and knowledge growing.

So, what does this mean for the indie developer? Well, in short, it gives access to a pretty powerful console. And since it's officially sanctioned by Microsoft you can expect mailing lists and forums dedicated to development. Ownership of a 360 isn't necessary either as the studio runs on a Windows XP PC. It may also mean a revenue stream as well. If Microsoft opts to allow content to be available on XBLA, they may also allow the developer to charge for downloads. I'm sure Microsoft will get their cut, but this could mean some serious cash for the young developer.

Overall, this is definitely a step in the right direction. Despite what you and I may think of Microsoft, I think they're doing something right here. Only time will tell how it turns out. I'll definitely be downloading this when it becomes available on August 30th.

UPDATE : Maxconsole dug up the official FAQ direct from Microsoft. This is different than the FAQ on the XNA site. Looks like you'll have to sign up to get the beta :

"A beta of XNA Game Studio Express will be released on August 30. To receive a notification on when the Beta is available, please go to http://connect.microsoft.com and select "Available Connections." Then choose the XNA connection and follow the link to sign up for the XNA Game Studio Express Beta. (Note: A valid Windows Live ID is required, if you do not have one, you will be given the option of creating one.)"

It looks like the beta will be limited to PC content only. It uses .NET technology on both the 360 and PC to create the games and according to the FAQ, it looks like it will be limited to C# code only.

I read an interesting article today over at Darknet. It brings to light some of the "new" techniques that can be used to exploit newer Web 2.0 applications.

The article was an interesting read and got me thinking about application security again. I find myself spending more and more time on security in an application, and less time on features and actual logic. Generally I'm splitting coding time between idiot proofing the application so the end user is forced to put in the right data, and hack proofing the code against would-be hackers. Even with custom frameworks to handle the boring bits, it still takes a lot of time and effort to make sure you've covered your bases. Oh well, such is the world we live in nowadays.

The new ways to exploit applications are interesting as well. Actually, most of them aren't new, but rather the same old hacks used to exploit the new way of doing things. For instance, in an AJAX application you pass information between the browser and the server, behind the scenes. Ok, all well and good, but how do you make sure you're still talking to the original browser that opened the request? You could use a cookie, or perhaps some sort of a session ID. Maybe a combination of the two. And on top of it, you might check the User Agent string and the referrer URL. Mind you, this can all be spoofed. In fact, spoofing the UA and referrer is extremely easy and can be done with tools like curl and wget. So what is the best way to secure these apps?

I haven't really started working with AJAX very seriously, so I haven't done much research into the matter. But, thinking about it, maybe there is a way to secure things a little better? Perhaps a variable in the browsers memory rather than a cookie? Combined with a session ID? Right now I like to secure my apps by using a combination of a session ID, the IP address of the user, and a cookie with seemingly random data in it. This has worked pretty well thus far, but I'm not sure how hard anyone has tried to hack it. I'm definitely interested in more security, though, provided it doesn't slow things to a grinding halt.

Of course, there's always the one true way for security. Unplug it. Turn it off. If it's not running, it can't be broken into.. Well, not yet anyways.. There's always the quantum level.

Pawel Foremski is preparing to release the latest version (0.42) of his qmail-spp patch for qmail. This incredibly useful patch allows you to modify the behaviour of qmail, on the fly, through use of external scripts. These external scripts can be written in any programming language that allows STDIN and STDOUT. I have found this to be incredibly useful and it has haled tremendously when targeted by spammers and virii.

There was some initial concern about the overhead involved with calling an external program for processing, but my fears have been calmed since then. I've seen this patch in production on machines processing over 250,000 emails per day. That's a LOT of email.

The patch allows you to inject special processing during specific portions of the smtpd process. These areas include
HELO/EHLO, MAIL, RCPT, DATA and (if supported) AUTH. There is also another hook available when the client connects, before any data is transferred between the client and server. These 6 areas allow for a massive amount of power. For instance, you can interrupt the process right after the HELO/EHLO and run an spf plugin. Or, you can check the from address during the RCPT portion and determine if the user is relaying, and if they're allowed. Basically, a chkusr function. Tarpitting is fairly simple at the RCPT level as well. The initial connection point is a great time to check for blacklists. In fact, you can set different SPP config files for use depending on where the connection originates. Thus, you can add additional RBL lists depending on the source. So, you can skip RBL altogether for known local connections, and use a wider range of blocklists for external connections. All in all, the flexibility is incredible.

I highly recommend the use of this patch for any qmail installation intended for normal mail use. Obviously if you're never going to allow mail delivery, there's no real point, but if you need a strong, secure mail server, this is definitely a step in the right direction. In fact, I worked with Pawel to create a patch that will work with the SMTP AUTH/TLS patch that Bill Shupp put together. Bill has a nice page with a complete qmail toaster on it. His toaster was the basis for my own foray into the qmail scene, and I owe a lot to the work he's done. I've built my own toaster based loosely on his, but using the qmail-spp patch, and some of my own experience. You can find my toaster by either clicking here, or on the link to the right.