link_to helper doesn't work with :back

[lewis-od]

link_to helper doesn't work with :back

[davydotcom]

Could be fixed by setting referer on fetchReplacement

[dhh]

I like the sound of that. That's what a normal link would do, no?

On Sep 27, 2012, at 10:16 AM, David Estes wrote:

Could be fixed by setting referer on fetchReplacement

—
Reply to this email directly or view it on GitHub.

David Heinemeier Hansson

[lewis-od]

I tried this:

fetchReplacement = (url) ->
  xhr = new XMLHttpRequest
  xhr.open 'GET', url, true
  xhr.setRequestHeader 'Accept', 'text/html, application/xhtml+xml, application/xml'
  xhr.setRequestHeader 'Referer', historyCache[window.history.state.position - 1].url
  xhr.onload  = -> fullReplacement xhr.responseText, url
  xhr.onabort = -> console.log "Aborted turbolink fetch!"
  xhr.send()

But it doesn't work (on chrome) and gives the warning Refused to set unsafe header "Referer". I don't think it'll possible as setting the referer is disallowed by the XHR spec (see here).

[davydotcom]

Ah, so are we going to have to do a custom header var and server side handling to override referrer?

[davydotcom]

This is actually a history pushstate bug and is already fixed in chromium

http://code.google.com/p/chromium/issues/detail?id=45361

May have to wait for that.

[davydotcom]

Also already fixed in firefox 4 and greater..
https://developer.mozilla.org/en-US/docs/DOM/Manipulating_the_browser_history#Adding_and_modifying_history_entries

[davydotcom]

perhaps we can add header X-Push-State-Referer to the request, and leave it to the user to implement a server side solution.

[davydotcom]

Recommend using alias_chain_method for Rack::Request referer method...something like

def referer_with_turbolinks
  @env['X_PUSH_STATE_REFERER'] || referer_without_turbolinks
end
alias_chain_method :referer,:turbolinks

If we are ok with that approach, ill implement later.

[dhh]

Wonder is that's too broad. Maybe you patch redirect_to :back?

On Sep 27, 2012, at 22:35, David Estes [email protected] wrote:

Recommend using alias_chain_method for Rack::Request referer method...something like

def referer_with_turbolinks
@env['X_PUSH_STATE_REFERER'] || referer_without_turbolinks
end
alias_chain_method :referer,:turbolinks
If we are ok with that approach, ill implement later.

—
Reply to this email directly or view it on GitHub.

[davydotcom]

personally I almost never use :back, i prefer to be explicit on the redirects. doing it at the rack level would ensure rails treats the request just like any other regular request.

[davydotcom]

We do have to override redirect_to, checked source it uses

request.headers["Referer"]

not request.referer to determine back.

[dhh]

Fixed in 46818ee

[chourobin]

I think this issue still occurs and I am using turbolinks 1.1.1. Does anyone else have problems with the link_to :back helper generating a link to the current page?

<%= link_to "Back", :back %>

[davydotcom]

Probably needs an override to look at custom referee header like redirect_to :back does.

On Apr 7, 2013, at 11:57 AM, Robin Chou [email protected] wrote:

I think this issue still occurs and I am using turbolinks 1.1.1. Does anyone else have problems with the link_to :back helper generating a link to the current page?

<%= link_to "Back", :back %>
—
Reply to this email directly or view it on GitHub.

[yasuoza]

One way to make :back option works, we have to override HTTP_REFERER in request header, however it is blocked by browser.

Another way to make :back option works, we can change _back_url method defined in actionpack/lib/action_view/helpers/url_helper.rb, like this

def _back_url # :nodoc:
  referrer = controller.respond_to?(:request) && (controller.request.env["HTTP_X_XHR_RFERER"] || controller.request.env["HTTP_REFERER"])
  referrer || 'javascript:history.back()'
end

But this makes the newly potential xss pitfall, since attacker can prepare to send another referrer by setting X-XHR-Referer header.

So in my opinion, to use javascrtip:hisotry.back() you should write it to link_to target path, or hook history.back() on clicking the link.

[leckylao]

+1 with @chourobin that link_to back doesn't work on neither v1 nor v1.1.1

[speedmax]

+1 @lecky it's funny how we run into the same bug

[shoutsid]

+1

[n-studio]

+1

[antonjn]

+1 . @kuboon, thx!

[zaksoup]

I'm on turbolinks 1.1.1 and still seeing this occur.

[zaksoup]

Still seeing this happen in Rails 4 rc2 with turbolinks 1.2.0

[davydotcom]

PR #234 contains a fix

[m5n]

This issue still exists with Rails 4.0.2, Turbolinks 2.2.0. Here's how to reproduce:

$  rails new TurbolinksTest
$  cd TurbolinksTest
$  rails generate controller First
$  rails generate controller Second
$  vi config/routes.rb
root 'first#index'
get 'second' => 'second#index'

$  vi app/views/first/index.html.erb
<h2>First Page</h2>
<%= link_to 'Second', second_path %>

$  vi app/views/second/index.html.erb
<h2>Second Page</h2>
<%= link_to 'Back', :back %>

$  rails s

Load http://localhost:3000, click on "Second" link, once on the 2nd page click on "Back" link. You stay at the 2nd page.

Now reload the page. The link changes to javascript:history.back() .

Tested in Firefox 25 and Chrome 32.

[m5n]

Just to close the loop on this, @reed's commit above fixed my issue. Thanks!

[rodrigoruiz]

@reed It is still not working on Safari 7.0.1.