2013-10-01 12 views
18

Jest dziwne zachowanie w Google Chrome, która jest również opisany w tej kwestii: rails redirects to 'data:,'Szyny 4 przekierowuje do „danych :,” w Chrome

Kiedy nowy zasób jest tworzony i mój kontroler przekierowuje do pokazu action, chrome inicjuje ładowanie pustej strony za pomocą 'data:,' w pasku adresu. Odpowiedź autora, który zadał powyższe pytanie jest następująca:

Jest to funkcja zabezpieczająca, treść HTML nowej strony jest zgodna z treścią HTML przesłanego formularza, który blokuje Chrome.

Jednak nie wyjaśniono, jak to naprawić. To zachowanie występuje tylko w przeglądarce Chrome.

+1

Jeśli ktoś wie, jestem też ciekaw części zabezpieczenia tego. Dlaczego Chrome uważa to za funkcję bezpieczeństwa? –

+0

+1 Spotkanie z "funkcją" – itsnikolay

+1

Już miałem podobny problem. Przekierowania 301 w pamięci podręcznej Google Chrome. Musisz wyczyścić pamięć podręczną przeglądarki lub rozwinąć ją w trybie incognito. http://bugsquash.blogspot.fr/2008/12/google-chrome-caches-301-redirects.html rozwiązany przez – Ludovic

Odpowiedz

0

OK Myślę, że wiem, co to jest. Możesz określić obrazy i tekst w protokole danych: i uważam, że Chrome widzi kod HTML z ewidencją i myśli, że to dane. Ponieważ typ MIME nie jest określony, pozostawia typ MIME pusty po dwukropku i po prostu wypisuje przecinek.

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

Szyny 4 automatycznie ucieka HTML, więc jeśli próbujesz do renderowania HTML, trzeba wskazać, aby nie uciec. Spójrz na opcje renderowania:

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

Można użyć raw() do renderowania bezpośredniego HTML.

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

0

nie jestem przekonany, że dotyczy kwestii mimetype. Mam ten problem, gdy użytkownik publikuje wpis blogu, który zawiera elementy iframe w jego zawartości. Po zapisaniu wpisu przekierowuje do akcji "show", która zawiera zawartość użytkownika (raw/html_safe). Chrome wyświetli stronę na ułamek sekundy, a następnie z jakiegoś powodu przekieruje ponownie na pustą stronę "data:" (w historii pozostanie tylko dane: i strona przesyłania).

oto nagłówki odpowiedzi Zarejestrowałem:

Ruby 2.0.0/Rails 4 migrację aplikacji z nieprawidłowego zachowania (serwera testowego)

 


    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 z właściwego zachowania (serwer prod)

 


    HTTP/1.1 200 OK 
    Date: Thu, 23 Jan 2014 16:32:53 GMT 
    Server: Apache 
    ETag: "f12135ddd373205352f9754328368217" 
    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 

 

również próbował mając to jako początkowy HTML:

 


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

 

a także po prostu (jak losowe testy do wykrywania co może być źle)

 


    <!DOCTYPE html> 
    <head>... 

 

Wiem tylko, że jeśli przedstawiony zawartość ma iframe, gdy przekierowanie do dziwnych kopnięć zachowań blogu „Display” strona Chrome w.

10

Przeszukałem go i okazało się, że edytowanie postów z iframe w Rails 4.0 powoduje przekierowanie do "danych :,"

Rails 4 teraz ustawia nagłówek X-XSS-Protection dla wszystkich żądań, więc iframe wycieczki do ochrony XSS w Chrome po to forma przedstawienia. (https://github.com/elektronaut/sugar/issues/41#issuecomment-25987368)

Solution, dodać go do kontrolera:

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

Mogę potwierdzić, że wykonanie tego "rozwiązuje" problem. Chociaż zgadzam się, to prawdopodobnie nie jest najlepsze rozwiązanie. – cimtico