Jason King Studios contributed the art direction, design and html/css production for the site.

Visit the Site: www.ChrisSuchorsky.com.com

I’ve been developing web sites since 1997. I started with a Pentium 150 with 32MB RAM running Windows 95. Notepad was the editor of choice and WS-FTP was what we used to upload files to the production server. It was a beastly setup, but exciting times. I moved on through several home-brewed Windows systems and a few product cycles of Allaire’s Homesite and then Macromedia’s Dreamweaver before switching to a Mac in 2006. Since Adobe had bought Macromedia and I used Adobe’s Creative Suite for the rest of my work I ended up using Dreamweaver for a while, reasoning that I owned it and it was “supposed” to be good. It sufficed as a code editor but I found the additional “features” packed into it and the poor interface a real distraction and hindrance to my workflow. I decided to look around for alternatives and found that the developers of the FTP client Transmit, which I use, had developed a web site coding environment called Coda.

Panic’s Coda features a tight-knit elegant user-interface which perfectly suits the way I work. Coda plays nicely with my development server, MAMP, handles Subversion repository check-in and out, features Panic’s Transmit FTP-engine, has site management capabilities including a built-in Terminal for quick SSH access to a server and all of that’s without even getting into the actual coding environment which I will get to later.

Using Coda for Web Site Management

Coda is predominantly a web site development environment and as such it provides a method and interface for managing multiple web site projects. Once you create a site by either importing one of your Transmit favorites or setting one up from scratch, Coda presents you with a screen of thumbnails representing your sites. You can either choose your own thumbnail or Coda will use it’s built in webkit rendering engine to create one from the home page of your live site.

Coda’s site information includes live and local URLs and roots which allow Coda to track and publish changes between your local development site and a production site on a remote server. There’s also support for FTP, sFTP, and WebDAV connections and Coda will save your authentication information in your system keychain. You can also store SSH credentials and manage the entire site as a Subversion repository checkout if you desire. I’m fond of the simplicity with which Coda approaches site management. While the thumbnails themselves border on the hokey with taped up corners and a slight curl at the bottom, overall I like being able to see a visual representation of my projects, double click one and begin working.

Coda’s Editor Mode Is Defined by Simplicity

Once you’ve created a site you can double-click the thumbnail image to enter the edit mode. The file browser on the left will automatically switch to the local root directory you have specified and you will also be able to change to the remote root via the built in ftp module. Files opened from the remote root will be transferred immediately upon saving them.

Several syntax modes are available by default including HTML, PHP, CSS, Actionscript, Javascript, Perl and Ruby. The syntax modes include automatic text color-coding and syntax completion. Additional syntax modes supporting third-party software such as WordPress and Drupal are also available in the developer community. Coda’s edit mode also supports sharing documents via Bonjour, programming hints, HTML validation and a code snippet/clipboard manager. Line numbers and invisible characters can be toggled on or off and a code navigator makes working with large files more manageable.

Coda also has a great find and replace feature. As with most editors you can choose to find and replace in open documents, documents within a specific directory or documents within the entire site. Coda also has the ability find and replace matches based upon standard perl style regular expressions and its own built in wildcard variables.

Coda’s Preview Holds A Few Surprises

Having used Coda for the last two years I was recently surprised to learn how powerful Coda’s built-in preview function really is. Built on the open-source WebKit rendering engine, the same one used by Apple’s Safari and Google’s Chrome to render web pages in the browser. Coda’s preview includes the ability to view the rendered source of a URL, track javascript errors with a console debugger, launch the URL in any other installed web browsers including IE and other Windows browsers (if you are using VMWare Fusion) and comes complete with a handy DOM inspector which although broken at the moment by the release of Safari 5 gives you the option to inspect any element in the DOM with Safari’s developer tool: Web Inspector…very handy indeed. Once in preview mode just click on the magnifying glass in the bottom bar and then hover over the element on the page you wish to inspect. Clicking on the element will lock the highlight on that element and then display the DOM hierarchy in a breadcrumb style at the bottom of the window.

Coda also has the ability to provide a split pane view so that you can work on the same document in different places, work on two different documents at the same time or work on a document and preview the site at the same time. I find the last option particularly handy when making changes to the site’s CSS as I can use the DOM browser to inspect an element and then after seeing all the CSS rules that a particular selector is inheriting its style from make the necessary changes in the stylesheet.

Edit Stylesheets with Style

Coda offers two ways to edit and create stylesheets. Hand-code them in the editor or use the built-in CSS editor to organize your styles and set attributes with the handy visual editor. You can use the CSS selector browser to visually organize your stylesheet selectors. Each selector’s name is displayed using the corresponding text and color attributes from the CSS making it very easy to identify typographical and colored styles, but unfortunately other attributes like padding, margin, position, etc. are not possible to display with this method leaving some of the style selectors as plain text.

Coda’s Built In Terminal

Coda’s Terminal view provides quick access to a local or remote SSH session. Since each Site managed by Coda has the option to store this information securely in the system keychain it provides a fast and convenient way of accessing remote servers via SSH and replaces the need for a separate terminal window.

A Web Developer’s Reference Library

Panic decided to round the whole One Window Development environment out with a neat feature called Books. Coda comes with PHP, HTML, CSS and Javascript references built into its library and gives the user the ability to add other books, websites and documentation via their URLs. These sit along with the built-in documentation in a page format similar to that from the Sites Management view. The user can define a thumbnail to be used as the Book’s cover art and associate the book with one of the syntax definitions. There is also an option to provide a formatted search URL. By holding down command and double-clicking a word Coda will look up the word in the Book associated with that syntax mode.

Jason King Studios provided the two design concepts you see here, pro bono, likewise another member of the organization provided his time for the production and coding of the site.

Visit the Site: www.NYMSTF.org

Jason King Studios contributed the art direction, design and html/css production for the site.

Visit the Site: www.Snap311.com

Jason King Studios was hired to provide a complete identity design and online store while the product was still in its conceptual phase. Jason worked around the clock with the client to take their idea and make it into a tangible product, providing art direction, logo and identity design, brochure design, packaging design and an ecommerce-enabled website.

Visit the Site: www.LockerShelfCo.com

www.SakuraExpressPrinceton.com

This post is inspired by the true events of March 26, 2009 as a fellow web developer and I spent the better part of the day working out why the web server his installation of WordPress lives on was returning a 500 Internal Server Error whenever he tried to create a new Page by cutting and pasting HTML. It turns out a poorly formed rule in the default cPanel Mod_Security installation was throwing false positives as it matched the content of what he was posting to a rule denying a specific kind of SQL Injection Attack. But as is often the case in the behind-the-scenes world of web development one solution only leads to a new problem. This account is posted to document the problem(s) and solution(s) we worked out that day.

“/wp-admin/page.php” and the Dread 500 Server Error

If you’ve ever gotten 500 Server Errors while posting to your blog, forum, CMS, shopping cart or other web application there’s a very good chance you’ve been caught by a poorly formed rule in your server’s mod_security configuration. While a thorough accounting of mod_security is beyond the purview of this post let it suffice to say that for those who aren’t familiar with it, mod_security is a firewall for web applications (Read More: ModSecurity.org). ModSecurity is an Apache module which attempts to prevent malicious execution of code by filtering all requests to the server through its rulesets. It works by matching incoming requests against patterns designed to catch code that could compromise or otherwise harm a website or the server itself.

On closer examination of the mod_security log file you will probably find something that looks like this:

Access denied with code 500 (phase 2). Pattern match "(insert[[:space:]]+into.+values|select.*from.+[a-z|A-Z|0-9]|select.+from|bulk[[:space:]]+insert|union.+select|convert.+\\(.*from)” at ARGS:content. [id "300016"] [rev "2"] [msg "Generic SQL injection protection"] [severity "CRITICAL"]

That is the rule that is causing the false positive. You should also see a line that looks very familiar because it’s the path and parameters of the file the web application you are using is trying to POST to.

Overall, ModSecurity is an extremely effective tool when it comes to preventing SQL Injection attacks, however, every once in a while it can be the cause of extreme frustration as you helplessly try to figure out why all of a sudden you are getting a 500 Internal Server Error instead of the success screen you expect after posting your latest to WordPress, Zen-Cart, phpBB or any of the other widely available open source web applications. And because Mod_security is so ubiquitous, quietly humming away in the background, as you go about your business, you may go months or even years without running into a problem with it and by that time you of course will be completely stumped, you may even start thinking up crazy explanations for what’s causing the problem. You may be told to reinstall your cms, blog, forum, etc. Maybe there’s a corrupt file in there. Or if you’re really bright you might even start hacking the code itself trying to find the fix yourself. Please don’t do this. Unless of course you are the code’s author in which case–please do.

Even once you narrow it down to Mod_Security you may be tempted to try an .htaccess override because the web is full of examples of how to override Mod_Security per site, per file just simply by adding lines like these to your .htaccess file.

SecFilterScanPOST Off

SecFilterEngine Off

<IfModule mod_security.c>SecFilterEngine off</IfModule>

<IfModule mod_security.c>SecFilterInheritance Off</IfModule>

If you are one of the (un)fortunate ones who are unable to get things working by some variation of these tricks then you have essentially three choices:

• 1. If you are on a shared hosting account you will need to call or email your web host and ask that they add a white list rule that disables the rule that is giving the false positive. Ideally you would do this for the file in question and not just disable Mod_Security for your entire account which some people will try to tell you is the best solution. Personally, I’d run if that were the case.
  2. If you are the webhost and you’re administering your own dedicated server or a VPS you should have the option of opening a support ticket with the company you are leasing from and one of their admins will do this for you. LiquidWeb and their Heroic Support is fantastic for things like this.
  3. If neither of the above apply and you’re on your own, or if you just have time to burn and want to learn something about the way your webserver works you can add a rule yourself

Whitelisting WordPress with Mod_Security

While previously I stated that the false positive was caused by a poorly formed rule in Mod_Security’s configuration files, it would be equally reasonable to assume the rule was crafted by design and that the best practice for solving your Mod_Security woes and getting on with it is to create another rule specifically telling Mod_Security that it’s okay to let these requests pass unmolested. This is a fairly conservative i.e. paranoid security model but it’s tried and true: Deny All, Accept Few. So how to do this? Fortunately if you are somewhat handy with the shell you should be able to patch your Mod_Security in no time. You will need root access to your server, so if you don’t have that then see Step 1, above.

In the example that follows I assume you have root or access to sudo, can SSH into your server and can use a vi or nano to edit files and that you are running cPanel 11 and WHM. Here’s what you need to do.

1. 1. Log in to your server either with the root account or with your regular user account. You can wrap your commands with sudo or escalate your privileges to root as necessary.
2. 2. Change to the Mod_Security configuration directory: cd /usr/local/apache/conf/modsec2
3. 3. Open the whitelist.conf file for editing: vi whitelist.conf
4. 4. Add the following lines of code to whitelist.conf<LocationMatch "/wp-admin/post.php">SecRuleRemoveById 300015 300016 300017

   </LocationMatch>

   <LocationMatch "/wp-admin/admin-ajax.php">

   SecRuleRemoveById 300015 300016 300017

   </LocationMatch>

   <LocationMatch "/wp-admin/page.php">

   SecRuleRemoveById 300015 300016 300017

   </LocationMatch>

5. 5. Save whitelist.conf
6. 6. Restart Apache

If all goes well once Apache restarts your web server should stop sending 500 Internal Server Errors when you try to post your content and instead do what it’s supposed to do and accept your post.