oauth works manually or by before_filter but not going to /sign_in

My app currently has two ways a user can sign in using OAuth via Github:

- Click a button to read something protected. This triggers a
before_filter called authorize, which says:

    authorize_github_and_return_to request.url unless signed_in?

  This way works just fine (though using the same technique on a
Destroy link doesn't work, presumably due to the _method=delete stuff
not working in the wrong context).

- Click a link that goes to /sign_in. This triggers
SessionsController#new, which says:

    authorize_github_and_return_to params.fetch(:return_to, root_url)

  This way does NOT work, whether I use a return_to parameter or not.
It leaves me with a page that says "You are being redirected." with
"redirected" being a link to a Github auth page... the very same URL
as the way that works, except for the part after final_url (where to
return to). In the browser's address bar is
"http://localhost:3000/sign_in?return_to=http%3A%2F%2Flocalhost%3A3000%2F".
The logs say:

Started GET "/sign_in?return_to=http%3A%2F%2Flocalhost%3A3000%2F" for
127.0.0.1 at 2013-06-30 17:52:02 -0400
Processing by SessionsController#new as HTML
  Parameters: {"return_to"=>"http://localhost:3000/"}
Redirected to https://github.com/login/oauth/authorize?response_type=code&client_id=de15557094c58f8b146d&redirect_uri=http%3A%2F%2Flocalhost%3A3000%2Fauth%2Fgithub%2Fcallback%3Ffinal_url%3Dhttp%3A%2F%2Flocalhost%3A3000%2F
Completed 403 Forbidden in 2ms (ActiveRecord: 0.0ms)

Now here's the weird part... if I then go to the address bar and hit
return... IT WORKS! Then the logs say (note the EXACT SAME
redirection url above and below):

Started GET "/sign_in?return_to=http%3A%2F%2Flocalhost%3A3000%2F" for
127.0.0.1 at 2013-06-30 17:52:52 -0400
Processing by SessionsController#new as HTML
  Parameters: {"return_to"=>"http://localhost:3000/"}
Redirected to https://github.com/login/oauth/authorize?response_type=code&client_id=de15557094c58f8b146d&redirect_uri=http%3A%2F%2Flocalhost%3A3000%2Fauth%2Fgithub%2Fcallback%3Ffinal_url%3Dhttp%3A%2F%2Flocalhost%3A3000%2F
Completed 302 Found in 1ms (ActiveRecord: 0.0ms)

Started GET "/auth/github/callback?code=f622c143d1321386ea60&final_url=http%3A%2F%2Flocalhost%3A3000%2F"
for 127.0.0.1 at 2013-06-30 17:52:53 -0400
I, [2013-06-30T17:52:53.041032 #26853] INFO -- omniauth: (github)
Callback phase initiated.
Processing by SessionsController#create as HTML
  Parameters: {"code"=>"f622c143d1321386ea60",
"final_url"=>"http://localhost:3000/", "provider"=>"github"}
Redirected to http://localhost:3000/
Completed 302 Found in 0ms (ActiveRecord: 0.0ms)

Started GET "/" for 127.0.0.1 at 2013-06-30 17:52:54 -0400
Processing by PullRequestsController#index as HTML
   (0.2ms) SELECT COUNT(*) FROM "pull_requests"
  PullRequest Load (0.2ms) SELECT "pull_requests".* FROM "pull_requests"
  Rendered pull_requests/index.html.erb within layouts/application (2.4ms)
  Rendered layouts/_log_in_out.html.erb (0.1ms)
Completed 200 OK in 12ms (Views: 11.0ms | ActiveRecord: 0.5ms)

The method authorize_github_and_return_to is in
application_controller.rb and says:

  def authorize_github_and_return_to final_url
    github = Github.new(client_id: ENV['GITHUB_KEY'],
                        client_secret: ENV['GITHUB_SECRET'])
    redirect_uri = oauth_callback_url(:github, final_url: final_url)
    auth_address = github.authorize_url(redirect_uri: redirect_uri)
    redirect_to auth_address
  end

If I put a binding.pry right before the redirect, I can see that the
URLs are identical (again, except for the final_url part).

I'm guessing that the key to this mystery is WHY the link to /sign_in
is returning 403. I've Googled "OAuth Github Devise sign_in (403 OR
forbidden)" (sans quotes) and didn't find anything useful. Any clues?

Thanks,
Dave

AHA!

My subconscious put together something I had seen on OAuth not liking
JavaScript-submitted credentials, and the fact that Rails 4 uses
Turbolinks by default. Adding "'data-no-turbolink' => true" to the
link_to makes it work! Yaaaay! I'm reporting this in case anyone
else comes across the same problem.

-Dave

And premature release of Turbolinks takes another victim.