Great article on the misunderstood scope of the “Model” in the Model-View-Controller architecture. The takehome: Models are commonly thought of as wrappers for database access/stored objects, but application state and business logic need to go in them, too. Otherwise you get bloated controller and/or views that clumsily try to take care of these concerns.
Earlier today I was building a multi-step wizard app—no DB storage—and found my controllers getting messy with session and state handling code. The solution was a Wizard class that encapsulated the steps through the forms and the maintenance/validation of the collected data, but until this article I might not have thought of it as a model.
Zend Framework kinda, sorta has a hack for making a wizard using “subforms” and what makes this an awkward construction is that a view helper is not the best place to maintain the state info that a wizard requires. A “Zend_Wizard” class would need to encapsulate several forms; requirements and behaviors for moving forward and backward through the forms; and methods to inc/dec the step state, fetching the active form injected with session data. Only a single controller would be needed with 2 next/back methods, rather than methods for each step.
In the Elgg plugin ecosystem, there’s very little guidance/emphasis on creating models, so writers rarely encapsulate business logic at all. Instead it becomes spread out amongst controllers and—worse—views. Since views can easily be overridden depending on the order of plugins in a list, business logic can easily be mangled by logic from another plugin. That said, the view system does allow mods to mix behaviors in ways that would be difficult were views to be tied more closely to individual plugin models; a few exemplary mods—that store state and validation in a model rather than the controller/views—might help positively influence the culture.
Google is offering programmers their own personal sandbox application—called Jarlsburg—and hints of how to exploit the common vulnerabilities purposefully left in it. Although Google is basically walking folks through how to attack apps, publicizing this info is a necessary evil in order to build safer programmers. We have to start thinking of each line of code, cookie, HTTP request, and configuration option as another attack surface.
The table of contents lists the who’s who of vulnerabilities (though there are a lot more out there). Several of these attacks no one would’ve even dreamed of a few years ago, so the sad reality is that the web is chock full of vulnerable “legacy” apps just waiting to be exploited—unless we can fix them in time.
- Cross-Site Scripting (XSS)
- XSS Challenges
- File Upload XSS
- Reflected XSS
- Stored XSS
- Stored XSS via HTML Attribute
- Stored XSS via AJAX
- Reflected XSS via AJAX
- More about XSS
- Client-State Manipulation
- Elevation of Privilege
- Cookie Manipulation
- Cross-Site Request Forgery (XSRF)
- XSRF Challenge
- More about preventing XSRF
- Cross Site Script Inclusion (XSSI)
- XSSI Challenge
- Path Traversal
- Information disclosure via path traversal
- Data tampering via path traversal
- Denial of Service
- DoS – Quit the Server
- DoS – Overloading the Server
- More on Denial of Service
- Code Execution
- Code Execution Challenge
- More on Remote Code Execution
- Configuration Vulnerabilities
- Information disclosure #1
- Information disclosure #2
- Information disclosure #3
- AJAX vulnerabilities
- DoS via AJAX
- Phishing via AJAX
- Other Vulnerabilities
- Buffer Overflow and Integer Overflow
- SQL Injection
Don’t miss Patent Absurdity, a free half-hour documentary that “explores the case of software patents and the history of judicial activism that led to their rise, and the harm being done to software developers and the wider economy.”
Had the modern interpretation of software patent law existed in the 60s, our computers, and the state of technology in general, might be very different. The clumsy technology in “Brazil” comes to mind.
With so much of the world’s economy and productivity now tied to software, the proliferation of software patents and worse—areas where those laws can apply—threatens to severely stifle innovation and funnel ever more of our resources into the pockets of law firms and of patent-trolling organizations that exist simply to extort from others.
OccasionallyVery infrequently, with help from my caffeine addiction and Intense Focus On Writing Awesome Code For Employers Who May Read This, empty Coke Zero cans will slowly accumulate in my vicinity. I couldn’t say how many. In the worst of times enough to not want to know how many.
The awareness of more severe dysfunction in others is a cold comfort.
(Written July 2007)
The digital dark ages is already a reality for a lot of people who grew up with hosted e-mail services like Compuserve and AOL. A lot of those users had no choice but to accept the loss of all their received and sent e-mail when they unsubscribed, the service went under, or their account was deleted from inactivity. Mark Pilgrim wrote about the challenge of long-term data preservation without open formats and source code:
Data readable by only one application is a big risk factor, because the application won’t be around forever. If that application only runs on one operating system, that’s even worse, because the operating system won’t be around forever either. If that operating system only runs on one hardware platform, that’s even worse still. No hardware lasts forever, and you may eventually need to resort to emulating the hardware in software. Emulation is the ultimate fallback. But if any or all of those layers are closed, emulation may be costly or even impossible. And if any of the layers are DRM-encumbered, emulating them may be illegal.
Most social network users don’t keep a copy of their data in any format, so how can we expect to preserve it? Will MySpace be around for 5 years? 20 years? People have already declared Friendster dead; all your testimonials and contacts of old friends could be gone any month now.
The next killer social networking application shouldn’t be another Friendster or MySpace, but rather an open standard allowing us to create and manage our own social data. And it is “our” data. Points of contact with old friends we’ve managed to track down, new friends made from shared interests, anecdotes and testimonials we’ve written for friends and loved ones, snapshots of our interests and personalities. Only by keeping this information in an open format, available for us to backup, can we expect for it to survive.
Let’s say that MySpace suddenly had an export feature. How much would it need to include to be meaningful in 50 years? Obviously you’d want your profile, pics, videos, and blog posts; your inbox and sent mail; probably comments you’ve made on friends’ profiles and blog posts. How much of your friends’ data would you want?
October 2009: We’re still not there. Google Wave will vastly improve the situation (at least having a permanent record for IM), but the real goal here is something trivially easy to install, letting users host their own personal and networking data. Big web providers could still carve out a business by caching copies of user data (to save bandwidth, or for backup) and concentrating on indexing, searching, and providing apps like those for Facebook.
When Opera released Unite (basically a webserver in the browser), I wasn’t sure what they’d get out of it, or what the use case was, but actually this the perfect platform on which to build a distributed social network app. The default storage location of all your data would be on your computer, easily backed up at any time.
Next best thing: SocialSafe, a Facebook backup tool. For three bucks you could be able to show your kids how their parents met, and what they were like then.
Miško Hevery gave several presentations at Google last year that are worth checking out, I think even if you’re familiar with Dependency Injections and unit testing. They cover the ways that global state can sneak into applications, how undeclared dependencies make classes harder to test and reuse, and how DI in general eases a lot of pain. He’s just a good teacher and the examples are clear and made me want to attack a lot of old code. Hig blog also covers a lot of the same topics.
Luis von Ahn creates simple games that have people solve problems that computers can’t (Google video). Every time you play a game of Taboo, the hinter generates associations between words and the guesser, by guessing the correct word, is verifying the quality of those associations. By isolating players via the web and collecting their responses, on online version of Taboo could generate mountains of data that help computers associate words with other words. Luis took this idea and created several games that use humans to associate words with images, objects within images with words, even words with what they mean… My favorite bit is that, given the same input (eg. a card in Taboo), he gets more good data by recording the actions of all human players and using them against other live players or even other recordings. Eg. Jim and Jane play a game. When Mike comes along, the computer can use Jane’s recorded actions as Mike’s partner. If Steve and Sue also played, the computer could even go back and match Steve’s recording against Jane’s and Jim’s against Sue’s, generating even more data without any human involvement. These “zero player” games wouldn’t give you new associations, but could aid in ranking them.
This game is all about scale. Think “The Sims” from the molecular level to the galactic with everything in between. At least watch long enough to see your animal doin’ it (soft jazz with sax helps set the mood). As a programmer, this thing makes my greatest accomplishments feel like Pong.
I’ve been hearing great things about source control for awhile so I dug in and installed Subversion using this new tutorial. While you can interact with the svn server from the command-line, the TortoiseSVN Windows shell extension makes managing imports, updates and commits as simple as a right click.