Rails 4 redirects to 'data:,' in Chrome

后端未结

关注

 3  490

予麋鹿

There is a weird behavior in Google Chrome, which is also described in this question: rails redirects to 'data:,'

When a new resource is being created and my

相关标签:

3条回答

不思量自难忘°

2020-12-31 04:26
I've been googling it and found that editing posts with an iframe in Rails 4.0 causes a redirect to "data:,"

Rails 4 now sets the X-XSS-Protection header for all requests, so the iframe trips up the XSS protection in Chrome after a form submit. (https://github.com/elektronaut/sugar/issues/41#issuecomment-25987368)

Solution, add it to your controller:
```
before_filter :disable_xss_protection

protected
def disable_xss_protection
  # Disabling this is probably not a good idea,
  # but the header causes Chrome to choke when being
  # redirected back after a submit and the page contains an iframe.
  response.headers['X-XSS-Protection'] = "0"
end
```
0 讨论(0)
发布评论:

提交评论
- 加载中...
时光取名叫无心

2020-12-31 04:35

Ok I think I know what this is. You can specify images and text inside a data: protocol, and I believe Chrome is seeing escaped HTML and thinking it is data. Since the mime type is not specified, it leaves the mime type blank after the colon, and just prints the comma.

http://guides.rubyonrails.org/security.html#redirection

Rails 4 automatically escapes HTML, so if you are trying to render HTML, you have to indicate not to escape it. Look at the options for render:

http://guides.rubyonrails.org/security.html#redirection

You can use raw() to render direct HTML.

http://www.webbydude.com/posts/9-the-h-helper-in-rails-3

0 讨论(0)
发布评论:

提交评论
- 加载中...

鱼传尺愫

2020-12-31 04:37

I'm not convinced it is related to a mimetype issue. I have this issue when a user posts a blog entry that has iframes in its content. When the entry is saved it redirects to the "show" action which will have the user's content (raw/html_safe). Chrome will display the page for a split second and then for some reason re-direct again to the blank "data:," page (in history it will only leave the data:, and the submit page).

here are the response headers i registered:

Ruby 2.0.0 / Rails 4 migrated app with incorrect behavior (staging server)



    Cache-Control:max-age=0, no-cache, no-store
    Cache-Control:max-age=0, private, must-revalidate
    Connection:Keep-Alive
    Content-Encoding:gzip
    Content-Length:25359
    Content-Type:text/html; charset=utf-8
    Date:Thu, 23 Jan 2014 16:37:11 GMT
    ETag:"6d9d4961ea2df12de67f8a92c43579fb"
    Server:Apache
    Set-Cookie: _**********_session_dev=1774518c571bf4e65189d607b276e65e; domain=*********.com; path=/; expires=Thu, 23 Jan 2014 18:37:11 -0000; HttpOnly
    Status:200 OK
    Vary:Accept-Encoding
    X-Content-Type-Options:nosniff
    X-Frame-Options:SAMEORIGIN
    X-Mod-Pagespeed:1.6.29.7-3566
    X-Request-Id:9f5314a5-ad01-4aec-bd0f-04e8afd9bdac
    X-UA-Compatible:chrome=1
    X-XSS-Protection:1; mode=block

Ruby 1.8.7 / Rails 2 app with correct behavior (prod server)



    HTTP/1.1 200 OK
    Date: Thu, 23 Jan 2014 16:32:53 GMT
    Server: Apache
    ETag: "f12135ffffd373205352f9754328368217"
    Cache-Control: private, max-age=0, must-revalidate
    Status: 200
    X-Mod-Pagespeed: 1.4.26.5-3533
    Cache-Control: max-age=0, no-cache, no-store
    Vary: Accept-Encoding
    Content-Length: 27167
    X-Cnection: close
    Content-Type: text/html; charset=utf-8
    Connection: Keep-Alive
    Content-Encoding: gzip

also tried having this as the initial html:



    <!DOCTYPE html>
    <html>
    <head>...

and also just (as random tests to detect what could be wrong)



    <!DOCTYPE html>
    <head>...

All I know is that if the submitted content has iframes, when redirecting to the blog "display" page chrome's weird behavior kicks in.

0 讨论(0)