A common approach to Rails authentication is with a before_filter in your controller to authenticate your users:

before_filter :authorize

The authorize method stashes the originally requested URL in your visitor's session if they are not logged in yet:

def authorize
  unless session['user']
    session['return_to'] = request.request_uri
    redirect_to some_login_path
  end
end

When the user logs in they are redirected to the 'return_to' session parameter:

redirect_to session['return_to'] ? session['return_to'] : some_default_path

This is all pretty standard. However, I have found that the above approach can break thanks to some odd favicon requests. Here is an excerpt from my web server log:

xxx.xxx.xxx.xxx - - [01/Apr/2009:12:42:02 -0700] "GET /users/favicon.gif HTTP/1.1" 302 106 "-" "Mozilla/4.0 (compatible; GoogleToolbar 5.0.2124.6042; Windows XP 5.1; MSIE 7.0.5730.13)"

Looking through the log, there appears to be a pattern where these requests include "GoogleToolbar" in the agent header. A Google search for "google toolbar favicon" returns some mystified webmasters but not much of an explaination to why the toolbar is doing this.

Anyhow, here is a series of events that will trigger the 404 for your user:

1. Browser requests /some/path/requiring/authentication.
   Rails puts '/some/path/requiring/authentication' into the user's 'return_to' session parameter.
2. Google Toolbar requests /some/path/requiring/authentication/favicon.gif
   Rails replaces 'return_to' session parameter with '/some/path/requiring/authentication/favicon.gif'
3. The user logs in.
   Rails forwards the user to '/some/path/requiring/authentication/favicon.gif' and gets a 404 error.

The Google toolbar request to favicon.gif overwrote the original 'return_to' session parameter with a bad url.

The fix for this problem is to reject 'return_to' session parameters that include 'favicon':

redirect_path = if session['return_to'] && !session['return_to'][/favicon/]
  session['return_to']
else
  some_default_path
end
redirect_to redirect_path

Here's a quick grep for slow responses from the rails log file:

tail -f production.log | grep '[0-9]\{3,\}ms'

I took a safari through the build scripts used to compile Ruby 1.8.7. Here are some ruby build script nuggets that I gathered:

Some files, semi-explained

configure	This file is generated from the configure.in file in source control. Ruby releases (tgz downloads) have it pre-generated. The configure script explores your system for available libraries, architecture, and other helpful info for compiling.	Generated by configure.in
miniruby	A small ruby implementation whose main purpose is to execute native ruby build scripts, such as mkconfig.rb. Ruby builds this as a tool to compile the full ruby distro.
mkconfig.rb	A ruby script that parses config.status, explores directories and other settings, and generates rbconfig.rb
config.status	Bash script that is generated by the configure script	generated by the configure script
rbconfig.rb	A generated ruby script that is basically a hash of all build settings.	generated by mkconfig.rb, which parses config.status

What happens when you build ruby

Here is an overview of what happens when you compile Ruby, at a really, really, high level.

configure =[generates]=> Makefile =[builds]=> miniruby =[executes]=> mkconfig.rb =[generates]=> rbconfig.rb

Sample hackery

The Ruby 1.8.7 build process in Mingw was stripping debug symbols from external libraries. It turns out that configure has the following line:

cygwin*|mingw*)	: ${LDSHARED="${CC} -shared "'$(if $(filter-out -g -g0,$(debugflags)),,-s)'}

The "-s" flag is the culprit which is stripping out the debug symbols. The conditional that checks if "debugflags" is set to something other than -g or -g0 works fine in the main Ruby Makefile.

However, a separate Makefile is generated for each extension, and these generated Makefiles do not have "debugflags" set to anything. As a result, the ruby make process will strip out debug symbols for extensions no matter what debug flags are set.

The quick fix for this is to edit the line in the configure script:

cygwin*|mingw*)	: ${LDSHARED="${CC} -shared"}

It took me a while to figure out how to perform a diff against the remote branch that you forked. Here goes:

git fetch git://github.com/user/repo.git master:user_master
git diff --stat user_master

The first command, "git fetch" will fetch the remote branch and adds it as a local branch under the new name "user_master". For example, fetch git://github.com/why/shoes.git master:why_master .

The second command performs the diff against the local copy of the remote repository.

I got the dependencies for bloopsaphone (and the other libs) to compile and run in windows. I had to use the snapshot release of portaudio to compile in mingw.

Shoes + mingw support + some bugfixes:
http://github.com/ender672/shoes/tree/master

Customized rubyinstaller for building shoes in windows:
http://github.com/ender672/rubyinstaller/tree/master

Compiling latest Shoes in Windows instructions:
http://www.holymonkey.com/building-shoes-in-windows

There are a few issues with my shoes branch:
  * windows/http is broken (fixing now by reverting to winhttp)
  * The shoes splash screen doesn't come up properly with ruby 1.9 (but you can still load in your scripts with <alt>+">")
  * VLC libraries are not being built (working on it now)

I just migrated holymonkey.com away from Google Pages, which appears to be deprecated in favor of Google Sites. Some old articles didn't make the cut and are no more.