Friday, October 24, 2008

In Ruby, there are times when you want to access pieces of functionality that other people of written (3rd party libraries) and you normally have 2 options. You can install a plug in or install a gem. Normally the method you use is determined by which ever is made available by the author.

Gems are installed on the host machine and are pretty handy when you want to run things in the command line or else across lots of projects, but their downside is that if you use a gem in a Rails project there is no automatic publishing mechanism when you deploy your site. You will need to log onto the remote host machine and install the gem manually.

Plugins are specific to Rails and are similar to gems in that they are also 3rd party libraries. However they are associated with your Rails project as opposed to your machine so they will get posted to the server on a regular deploy.

Freezing a gem is the process of transforming a gem into a plug in. Essentially the gem is "unwrapped" and installed into your Rails plug ins directory.

Make sure the gem you want to freeze is installed.

Navigate to your Rails project's home directory and type the following

script/plugin install http://svn.ardes.com/rails_plugins/gems(this is the plugin which will freeze the gem)

rake gems:freeze GEM=gem_name

Note that not every gem can be frozen successfully. Some gems rely on executables which are platform specific and these cannot be accessed from the plugins directory.

Monday, October 20, 2008

There may eventually be a time when you need to allow people to write some HTML on your site. Maybe you have a bulletin board or something or else possibly you are writing some kind of email app or wiki.

The main problem with this is that you potentially open your site to Cross Site Scripting (XSS) attacks (more info at http://en.wikipedia.org/wiki/Cross-site_scripting). Basically in an XSS attack, someone puts in a little JavaScript in your site via a user input and when someone else looks at the page the first person steals the other's cookies. In fact you can unwittingly open your site to XSS attacks just by forgetting to encode all your user inputted text by using the h() function.

This is essentially a backwards approach to the problem however. What you really want to do is close everything down by default and then make a mental effort to allow it to use HTML. Even then, you may run into the problem of people running script tags.

Enter XSS Terminate. This is a handy little plug in which will basically strip all HTML tags out of any field going to and from the database by default. You can additionally apply either Rails' sanitize method to strip out scripts while allowing some basic HTML tags or else use html5lib_sanitize to strip out the scripts while allowing for normal browser quirks (sanitize requires strict XHTML standards).

In any case, the real reason I am writing this is that the XSS terminate usage instructions contain a couple of errors.

Basically though you probably don't want to use :except without using :sanitize or :html5lib_sanitize. Ever... And I mean it... Otherwise the next email you get will be from your sysadmin (if you are lucky) or your lawyer (if you are not).

In any case, the next problem is that the HTML elements entered by the user will probably read your default stylesheets. While you may want this, you may actually want the HTML to look kind of clean and distinct from your site (to highlight the fact that it is user generated content).

There is no easy way unfortunately to reset the css in a specific section so I had to search around for a default browser stylesheet online and then manually prefix every element with .text-entry. Because I am a nice guy, I am including it here (just do a text replace on .text-entry to use your own class name).

Thursday, October 09, 2008

When it comes time to run your fancy AJAX site on production, you may find that there will occasionally be minor JavaScript errors (possibly from 3rd party sites, never your own of course) which will not only prevent your scripts from running but may also pop up some warning boxes on the end users' systems (especially if your target audience is made up of web developers who have "Disable JavaScript Debugging" unchecked).

Even if the user does not have debugging turned on, they may still see the error symbol in the status bar (and this does not exactly put their fears at ease, especially if they are trying to make a cash transaction).

Fortunately, you can suppress these error messages by using the following JavaScript code

function noError(){return true;}window.onerror = noError;

Essentially what this does is catch any JavaScript errors and passes them to a null function. You should probably wrap this in a conditional which will only run on production and staging because as you are developing you will want to see these errors to prevent them from happening in the first place (i.e.<%if ENV['RAILS_ENV'] == 'production' || ENV['RAILS_ENV'] == 'staging' %><script type="text/javascript">function noError(){return true;}window.onerror = noError;</script/><% end %>).

window.onerror, as it happens, can also pass in some useful variables if you want to log them somehow. These are the error message, the url and the linenumber.

On the server side, create a small function which will take in these parameters and log them along with the user's remote address and user agent ( request.remote_addr and request.user_agent in Rails).

There are some browser differences (and inconsistencies) with this however. For a start, while Firefox will give you the url of the JavaScript file in which the error occurs, Internet Explorer will only give you the url of the page that is rendered in the browser (i.e. what is in the location box). Safari does not seem to support these at all (Safari will suppress the error, but not run the alertError function) and IE in debug mode behaves the same as Safari.