Brilliant Thinking

Contents

The site engine is the application (software) that sits behind the scenes processing any data as needed. It may be as simple as a contact form that captures a request for information and sends you and email, right through to complex database functionality.

A standard 3-tier architecture approach to designing web applications is the most common, separating data, presentation and application layers. This ensures greater reliability and easier maintainability of the system but also requires more forethought in order to structure the website (application) so that the engine where all the hard work is performed runs separately from the actual layout (presentation). The application then “talks” to the database (the data layer) where all the variable data is stored. So, a typical request for a page looks something like this:

• Visitor browses to page on the site
• Page runs application (engine) behind the scenes
• Application communicates with the database to get necessary information
• Application formats data for use in the page
• Page lays the data out correctly
• Page is displayed to the visitor

There are also template engines which allow you to separate the design and the application completely (such as Smarty), although good software engineering principles should be applied to web development and a web application be as close to the 3-tier model as possible where relevant.

The more complex the engine, and the more complex the data structures, the more testing is required to make sure everything fits together properly. In the example of an eCommerce site, there is a complex series of events that all relate to products. Firstly, people can browse the catalogue, so we need a “display” engine. People can also add them to their basket, so we need a “basket” engine. People can purchase items, so we need a “payment” engine plus a “customer account” engine so we can track who bought what. We also need a “shipping” engine to calculate shipping costs, a “tax” engine to calculate VAT, and also a “stock” engine if we want to manage stock online. We also need a “fulfilment” engine so that orders can be marked as paid, and subsequently shipped (and marked as shipped) by the warehouse. There is a “notifications” engine so that the system can send out messages to customers about order status, and a “customer account” engine so that customers can log in and check the status of their orders. And all of these need to talk to the database in the same way to ensure the application (the ecommerce site) works. That’s 10 engines - and this is just a quick overview of a “standard” ecommerce site. There are numerous other engines (modules) that make up more complex sites, such as “special offers”, “related items”, “marketing updates”, “news”, “accounting”, etc, etc.

The most important aspect in determining the complexity of the site engine is knowing what the site should do, both now and in the future. The clearer these two pictures, the easier it is to scope, build and deliver the application required to do the job. The future picture is important because things like “we’d like to be able to have multiple languages in the future” can have a significant impact in the underlying database structure and the way the engine talks to it. Knowing this in advance allows us to adapt the initial architecture in preparation for the future additions, instead of having to throw away large amounts of the engine to add in the new functionality. Some people call this future-proofing, and it’s an important part of approaching the build of a professional, effective web presence.

In the next episode we’ll look at hosting …

According to the Sydney Morning Herald:

Companies will soon have to buy the electronic equivalent of a postage stamp if they want to be certain their emails are delivered.

America Online and Yahoo!, two of the largest email account providers, are about to start using a system that gives preference to messages from companies that pay up to US1¢ each to have them delivered. The senders must promise to contact only people who have agreed to receive their messages or risk being blocked.

The internet companies say this will help them identify legitimate mail and reduce junk email, identity-theft scams and other scourges that plague users. They also will earn millions of dollars a year if the system is widely adopted.

Full story here: AOL & Yahoo! announce pay-per-email strategy.

So does this mean the end of free email as we know it?

I doubt it. This looks more like a way for real advertisiers to ensure their message is received by the larger free email account providers, and for those large free account providers to establish a profitable new revenue stream. The small players, phishers, and mass-mailing companies (legitimate or otherwise) who choose not to engage in this pay-per-email scheme will still have to run the gauntlet of spam checkers.

Furthermore, additional DNS configuration (adding an SPF record) would ensure that emails can only be sent from the domain that they claim to be sent from. This is a simple configuration change that many ISPs don’t enforce but one that allows widespread abuse of email. The lack of an SPF record means that spammers can easily send out email that looks like it came from your domain, which can then make your domain look bad (if the recipient thinks you really sent it), and can cost you time and money (when people complain to you, rather than the spammer). 1st October 2004 was the target date for domains to have SPF records in place (Hotmail, for example, started checking SPF records on 1st Oct 2004).

SPF records by themselves don’t stop spam, but they help to better ensure the legitimacy of emails you do receive and pass one more test in the spam filter instead of disappearing down a black hole.

Back in August 2005, we wrote about the potential vulnerability of Linux systems in our article entitled There are no Pickpockets in the Desert. Although Linux itself remains strong, systems deployed on Linux are receiving more and more unwanted attention from hackers and crackers as reported by Netcraft:

Security holes in PHP-based content management and forum apps are an increasingly active front in Internet security, as hackers target unpatched weaknesses. The latest example is Monday’s hack of chip maker AMD’s customer support forums, in which an older version of Invision Power Board was compromised and used to distribute malware using the Windows Metafile (WMF) exploit.

Internet criminals have targeted unpatched vulnerabilities in open source CMS apps including phpBB, PostNuke, Mambo, Drupal and others, hoping to build botnets for use in phishing scams and distributed denial of service (DDoS) attacks. Compromised web forums hosted more than 600 phishing spoof sites identified by the Netcraft Toolbar Community in 2005 (as noted in their Year in Phishing roundup).

The tip of the iceberg? Maybe.

But effective software development of [bespoke] applications, whatever language they are written in, should take account of the environment that the application is to be deployed in and build in security systems as appropriate. It is also true that no software can be 100% secure, it’s just that the Web exposes these vulnerabilities so much quicker and with more visible consequences. How secure you decide to build an application will depend on the risk associated with compromise, and is also affected by budget constraints. However, professional software development should not be confused or compared with inexpensive freelance work, as the latter is often not developed to the same standard. I use the term inexpensive deliberately as there are numerous freelance developers who produce excellent work which can be more secure than other systems. It’s a case of using the right tool for the job! Remember too that much open source software is developed for free by talented people and is distributed for free to be used “as is with no warranties or liabilities”. As the old adage goes, “you get what you pay for”.

Link to full Netcraft Story.