Wyłącz przycisk Wstecz przeglądarki

98

Jak wyłączyć przycisk WSTECZ przeglądarki (w różnych przeglądarkach)?

priyanka.sarkar
źródło
92
Nie jesteś właścicielem komputerów użytkowników ani ich przeglądarek.
Instance Hunter
47
+1 Ponieważ chociaż zgadzam się, że wyłączenie przycisku Wstecz w przeglądarce jest „złą praktyką”, nie widzę powodu, by odrzucać samo pytanie, odpowiadać i wyjaśniać, dlaczego jest właściwą drogą do imo.
ChristopheD
45
Dlaczego jesteśmy wrogo nastawieni do tego pytania? Z tego, co wiemy, osoba zadająca to pytanie już wie, że jest to kiepska praktyka użyteczności, ale po prostu przestrzega wymagań, a może po prostu chce się czegoś nauczyć. Dlaczego po prostu nie udajemy, że jest to hipotetyczne pytanie, i nie odpowiemy, jak byśmy to zrobili, gdybyśmy zrobili coś takiego?
thomasrutter
5
Niektórych rzeczy nigdy nie należy robić, niezależnie od chęci ich zrobienia. Posiadanie niepodlegającego negocjacjom wymogu natychmiast mówi, że wymagania zostały ustalone przez ludzi, którzy nie mają biznesu, co jest znacznie większym problemem.
annakata
37
ugh, jestem autorem najbardziej niesamowitego komentarza w historii, ale straciłem go, gdy przypadkowo wcisnąłem przycisk Wstecz.
Dan Williams

Odpowiedzi:

26

To pytanie jest bardzo podobny do tego jednego ...

Aby to zadziałało, musisz wymusić wygaśnięcie pamięci podręcznej. Umieść następujący kod w kodzie strony za.

Page.Response.Cache.SetCacheability(HttpCacheability.NoCache)
RSolberg
źródło
14
Zwróć uwagę, że wyłączenie strony z pamięci podręcznej nie daje tego, czego chciał OP: wyłączenia odwiedzania stron za pomocą przycisku Wstecz. Nawet jeśli przeglądarka przestrzega funkcji no-cache podczas korzystania z przycisku Wstecz (które przeglądarki nie są zobowiązane do wykonywania AFAIK), nadal umożliwia ponowne załadowanie tej strony (zwykle po wyświetleniu okna dialogowego z ostrzeżeniem). Więc jeśli naprawdę nie chcesz, aby Twoi użytkownicy wracali na tę stronę, może to być gorsze, ponieważ żądanie dotyczące tej strony MUSI dotrzeć aż do serwera źródłowego. Będziesz potrzebować czegoś po stronie serwera, aby wykryć, że strona została ponownie odwiedzona. Nagłówki można zignorować.
thomasrutter
60

Nie wyłączaj oczekiwanego zachowania przeglądarki.

Spraw, aby Twoje strony obsługiwały możliwość cofnięcia się o jedną lub dwie strony; nie próbuj uszkadzać ich oprogramowania.

Jonathan Fingland
źródło
6
Dzięki stary, chodzi o to, że jeśli tworzysz aplikację AJAX, kompromis między kosztami a korzyściami między wyłączeniem przycisku Wstecz lub przeglądaniem aplikacji i opracowaniem odpowiedniego działania wstecznego dla każdego możliwego scenariusza może zmierzać do wyłączenia przycisk Wstecz jest bardziej atrakcyjną opcją z tych dwóch.
david.barkhuizen
Zgodziłbym się z Jonathanem, zwłaszcza w przypadku zalewania Internetu przez zalewające obecnie reklamy złośliwego oprogramowania przekierowującego, którzy już nadużywają systemu ostrzegania, aby utrudniać opuszczanie swoich stron bez możliwości zablokowania Cię na swojej stronie
MikeT
46

Wymyśliłem mały hack, który wyłącza przycisk Wstecz za pomocą JavaScript. Sprawdziłem to na chrome 10, firefox 3.6 i IE9:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" >
<title>Untitled Page</title>
<script type = "text/javascript" >
function changeHashOnLoad() {
     window.location.href += "#";
     setTimeout("changeHashAgain()", "50"); 
}

function changeHashAgain() {
  window.location.href += "1";
}

var storedHash = window.location.hash;
window.setInterval(function () {
    if (window.location.hash != storedHash) {
         window.location.hash = storedHash;
    }
}, 50);


</script>
</head>
<body onload="changeHashOnLoad(); ">
Try to hit the back button!
</body>
</html>

Co to robi?

Z komentarzy:

Ten skrypt wykorzystuje fakt, że przeglądarki traktują to, co następuje po znaku „#” w adresie URL, jako część historii przeglądania. Co to robi: podczas wczytywania strony do adresu URL jest dodawany znak „nr 1”. Po 50 ms „1” jest usuwane. Kiedy użytkownik kliknie „wstecz”, przeglądarka zmienia adres URL z powrotem na taki, jaki był przed usunięciem „1”, ALE - to ta sama strona internetowa, więc przeglądarka nie musi ponownie ładować strony. - Yossi Shasho

Yossi Shasho
źródło
1
Wygląda na to, że ten skrypt dodaje znak „#” do adresu URL podczas ładowania strony i co 50 ms dodaje 1 do adresu URL.
popioły 999
6
Ten skrypt wykorzystuje fakt, że przeglądarki traktują to, co następuje po znaku „#” w adresie URL, jako część historii przeglądania. Co to robi: podczas wczytywania strony do adresu URL jest dodawany znak „nr 1”. Po 50 ms „1” jest usuwane. Kiedy użytkownik kliknie „wstecz”, przeglądarka zmienia adres URL z powrotem na taki, jaki był przed usunięciem „1”, ALE - to ta sama strona internetowa, więc przeglądarka nie musi ponownie ładować strony.
Yossi Shasho
1
zwróć uwagę, że adres URL zmienia się dwukrotnie: Robimy to tylko w celu ukrycia implementacji, więc nikt nie zobaczy, że dodaliśmy „1”. Tak więc w rzeczywistości, gdy użytkownik klika wstecz, strona ponownie dodaje na chwilę „# 1” i ponownie je usuwa. Przy okazji - nie musi to być „1”, może to być dowolny ciąg.
Yossi Shasho
2
Problem polega na tym, że strona przewija się do góry co 50 ms. Jeśli masz formularz większy niż wysokość okna, uniemożliwi to wypełnienie wartości formularza.
3komma14
Dziękuję bardzo. Jest to bardzo przydatne w przypadku szczególnie interaktywnej strony opartej na JavaScript, w której przewijanie w lewo i w prawo jest częścią mechaniki. Pomaga to wyeliminować problem gestu przewijania w systemie Mac OS X, który powoduje przypadkowe „cofnięcie” użytkownika do strony (wszystko to jest łatwe, jeśli są już przewinięte do końca).
Iain Collins
34

Inni przyjęli podejście, by powiedzieć „nie rób tego”, ale to tak naprawdę nie odpowiada na pytanie autora. Załóżmy tylko, że wszyscy wiedzą, że to zły pomysł, ale i tak jesteśmy ciekawi, jak to się robi ...

Nie możesz wyłączyć przycisku Wstecz w przeglądarce użytkownika, ale możesz sprawić, że aplikacja ulegnie awarii (wyświetli komunikat o błędzie, wymagając od użytkownika rozpoczęcia od nowa), jeśli użytkownik wróci.

Jednym ze sposobów, które widziałem, jest przekazanie tokena do każdego adresu URL w aplikacji i w każdym formularzu. Token jest ponownie generowany na każdej stronie, a po załadowaniu przez użytkownika nowej strony wszystkie tokeny z poprzednich stron są unieważniane.

Kiedy użytkownik ładuje stronę, strona pokaże się tylko wtedy, gdy został do niej przekazany poprawny token (który został podany do wszystkich linków / formularzy na poprzedniej stronie).

Aplikacja bankowości internetowej oferowana przez mój bank wygląda tak. Jeśli w ogóle użyjesz przycisku Wstecz, żadne linki nie będą działać i nie będzie można więcej ładować strony - zamiast tego zobaczysz powiadomienie z informacją, że nie możesz wrócić i musisz zacząć od nowa.

thomasrutter
źródło
1
Mój bank ma inne podejście - całkowicie kończy sesję. Użycie przycisku wstecz jest równoznaczne z wylogowaniem.
RobG
To brzmi jak to samo podejście. Wykrywają, że wróciłeś i wystąpił błąd.
thomasrutter
również joomla działa wokół rozwiązania tokenów, token jest generowany przez każdą stronę i każdy formularz, faktycznie istnieją pewne problemy z tą praktyką, takie jak „gdy użytkownik pozostaje zbyt długo na stronie i jego token
traci
1
Nie zrozum mnie źle, z tą praktyką jest DUŻO problemów. Nie polecam tego, po prostu mówię, jak to się normalnie osiąga. Przekazują unikalne tokeny między stronami, aby wykryć, że nie skorzystałeś z jednego z oczekiwanych linków z poprzedniej strony, a następnie kończą sesję lub pokazują błąd. Łamie przycisk Wstecz, przerywa przeglądanie w kartach, przerywa tworzenie zakładek i / lub udostępnianie linków i nie tylko - a co więcej, tak naprawdę nie rozwiązuje żadnych problemów.
thomasrutter
jeśli problem polega na tym, że informacje są tracone lub psują się już, gdy użytkownik spróbuje użyć przycisku Wstecz, wówczas wyłączenie przycisku Wstecz byłoby bardziej pożądanym podejściem.
PoloHoleSet
10

Chociaż sam szukam odpowiedzi, „Najlepsza praktyka” jest ... nieaktualna ... Tak jak przeglądarki. (Naprawdę przeglądarki to brzydkie skamieniałości)

Najlepszym / najbezpieczniejszym rozwiązaniem byłoby zaimplementowanie przez przeglądarki metody / żądania, w ramach których użytkownik może przyznać stronie możliwość kontrolowania interfejsu.

Czemu? Ponieważ dla mojego obecnego projektu buduję interfejs w 100% zbudowany i kontrolowany w JavaScript .. A przycisk Wstecz nie ma miejsca w moim projekcie, ponieważ nie ma zmiany strony. (Tj. Cholernie szybko i bez migotania stron z powodu odświeżania ... Tak jak w prawdziwej aplikacji!)

Wiem, dlaczego nie ma możliwości „highjack” interfejsu, i rozumiem to. Ale przynajmniej powinniśmy mieć możliwość zażądania tego z przeglądarki! To naprawdę byłaby „najlepsza praktyka” bez niebezpieczeństw związanych z highjackiem.

Ale przeglądarki są przeglądarkami… Nie spodziewam się niczego ekscytującego w tym zakresie.

StellarDevil
źródło
1
100% nie zgadzam się, podczas gdy ta funkcjonalność byłaby wspaniała dla 99% twórców stron internetowych, pozostawiając pozostały 1%, który nadużywałby tej funkcji, moim zdaniem zbyt niebezpieczne jest pozwolenie stronie internetowej na kontrolowanie możliwości korzystania z Internetu skrypt przekierowania między domenami wymaga zablokowania lub zezwalania na potwierdzenie, czy skrypt może zostać uruchomiony z powodu tego rodzaju nadużycia
MikeT
@MikeT - W jaki sposób wyłączenie przycisku „Wstecz” podczas nawigacji na moich własnych stronach aplikacji uniemożliwiłoby komukolwiek korzystanie z Internetu?
PoloHoleSet
@PoloHoleSet, jeśli masz możliwość wyłączenia przycisku wstecz przeglądarki, to robi to każdy, wystarczy jedno przekierowanie, aby wysłać Cię na stronę, na którą nie chciałeś przejść i czy mogą wyłączyć elementy sterujące nawigacją w przeglądarce, jak uciekasz? Jestem pewien, że natknąłeś się na stronę „masz wirusa”, na której pojawiają się monity o zainstalowanie ich wirusa w celu usunięcia nieistniejącego wirusa. Wyobraź sobie teraz witrynę, na której mogą faktycznie uniemożliwić ci opuszczenie
MikeT
@MikeT - mogę wpisać dowolny inny adres w oknie nawigacji, mogę zamknąć zakładkę, mogę wyłączyć javascript. Nie chodzi o to, czy ktoś może, bo ty możesz, ja mogę, każdy może. Zgodnie z polityką, ludzie mówią, że NIE POWINIENEŚ, jeśli możesz. Nie mówimy o tym, jak zaprojektowalibyśmy przeglądarkę, mówimy o tym, jak programujemy aplikację.
PoloHoleSet
@PoloHoleSet, jeśli zamierzasz zablokować nawigację, musisz zablokować coś więcej niż tylko przycisk Wstecz, ponieważ historia przeglądarki i wpisane adresy URL również zapewniłyby użytkownikom możliwość obejścia przepływu pracy. i tak jak powiedziałem, nie mówimy o tym, co ty lub ja byśmy zrobili, ale o złośliwym elemencie, jeśli jedynym sposobem, aby uniemożliwić złośliwej witrynie przejęcie kontroli nad twoją przeglądarką, jest wyłączenie wszystkich js w przeglądarce, to zepsułeś Internet, ponieważ współczesna sieć opiera się na skryptach do dostarczania treści, o co mi chodzi, jeśli chcesz mieć taką kontrolę nad użytkownikami, stwórz aplikację, która będzie obsługiwać Twój przepływ pracy
MikeT
4

Szukałem tego samego pytania i znalazłem następujący kod na stronie. Pomyślałem, że podzielę się tym tutaj:

function noBack()
{
   window.history.forward()
}
noBack();
window.onload = noBack;
window.onpageshow = function(evt){ if(evt.persisted) noBack(); }
window.onunload = function(){ void(0); }

Jednak, jak zauważyli powyżej użytkownicy, nigdy nie jest to dobra praktyka i należy jej unikać ze wszystkich powodów.

user704988
źródło
2
dobrze by było, gdybyś mógł podać powody, dla których należy tego unikać.
Chris Snow
Zgodnie z moim zrozumieniem, technicznie nie można wyłączyć przycisku Wstecz w czyjejś przeglądarce, możesz go tylko ustawić tak, aby przycisk nie był dostępny lub kontynuował ładowanie tej samej strony. Zamiast robić to przez JS, użyj kodu po stronie serwera i użyj odpowiedniej logiki, która nie musi używać przycisku Wstecz. Należy zastosować alternatywną czynność, taką jak ponowne załadowanie tej samej strony lub wyświetlenie niestandardowego komunikatu.
user704988,
2

Jeśli polegasz na technologii po stronie klienta, można to obejść. Na przykład JavaScript może być wyłączony. Lub użytkownik może wykonać skrypt JS, aby obejść twoje ograniczenia.

Domyślam się, że można to zrobić tylko poprzez śledzenie sesji użytkownika po stronie serwera i przekierowanie (jak w Server.Transfer, a nie Response.Redirect) użytkownika / przeglądarki na wymaganą stronę.

devio
źródło
2
<body onLoad="if(history.length>0)history.go(+1)">
Londyn
źródło
2

Było kilka różnych implementacji. Jest rozwiązanie flash i kilka rozwiązań iframe / frame dla IE. Sprawdź to

http://www.contentwithstyle.co.uk/content/fixing-the-back-button-and-enugging-bookmarking-for-ajax-apps

BTW: Istnieje wiele ważnych powodów, aby wyłączyć (lub przynajmniej uniemożliwić 1 krok) przycisk Wstecz - spójrz na Gmaila jako przykład implementujący rozwiązanie hashujące omówione w powyższym artykule.

Google „jak Ajax złamał przycisk Wstecz”, a znajdziesz wiele artykułów na temat testowania użytkowników i zasadności wyłączenia przycisku Wstecz.

DallinDyer
źródło
Sprawdź także nową przeglądarkę zdjęć na Facebooku. Zauważ, że przycisk z powrotem zabierze Cię z powrotem fotografię (czyli to, co chcesz) zamiast robić domyślną przeglądarkę
DallinDyer
2

Miałem też ten sam problem, użyj tej funkcji skryptu Java na tagu head lub w, jej 100% działa dobrze, nie pozwoli ci wrócić.

 <script type = "text/javascript" >
      function preventBack(){window.history.forward();}
        setTimeout("preventBack()", 0);
        window.onunload=function(){null};
    </script>
Abdul Khaliq
źródło
1

Wypróbuj ten kod. Pracował dla mnie. Zasadniczo zmienia hash zaraz po załadowaniu strony, co zmienia ostatnią stronę historii, dodając „1” do adresu URL. Więc po naciśnięciu przycisku Wstecz za każdym razem przekierowuje na tę samą stronę.

 <script type="text/javascript">
    var storedHash = window.location.hash;
    function changeHashOnLoad() { window.location.hash = "1";}
    window.onhashchange = function () {
        window.location.hash = storedHash;
    }
</script>

<body onload="changeHashOnLoad(); ">

</bod>
P. Shrestha
źródło
0

Powinieneś używać postów z odpowiednimi wygasającymi i buforowanymi nagłówkami.

epascarello
źródło
Zobacz mój komentarz do tej odpowiedzi, aby dowiedzieć się, dlaczego to nie działa.
thomasrutter
0

Zamiast próbować wyłączyć przycisk Wstecz przeglądarki, lepiej go wesprzeć. .NET 3.5 bardzo dobrze radzi sobie z przyciskami wstecz (i dalej) przeglądarki. Wyszukaj w Google: „Scriptmanager EnableHistory”. Możesz kontrolować, które akcje użytkownika dodają wpis do historii przeglądarki (ScriptManager -> AddHistoryPoint), a aplikacja ASP.NET otrzyma zdarzenie za każdym razem, gdy użytkownik kliknie przyciski Wstecz / Dalej w przeglądarce. To zadziała dla wszystkich znanych przeglądarek

Corne
źródło
0

Globalnie wyłączenie przycisku Wstecz jest rzeczywiście złą praktyką. Ale w niektórych sytuacjach funkcja przycisku Wstecz nie ma sensu.

Oto jeden ze sposobów zapobiegania niechcianej nawigacji między stronami:

Pierwsza strona (plik top.php):

<?php
    session_start();
    $_SESSION[pid]++;
    echo "top page $_SESSION[pid]";
    echo "<BR><a href='secondary.php?pid=$_SESSION[pid]'>secondary page</a>";
?>

Druga strona (plik secondary.php):

<?php
    session_start();
    if ($_SESSION[pid] != $_GET[pid]) 
        header("location: top.php");
    else {
        echo "secondary page $_SESSION[pid]";
        echo "<BR><a href='top.php'>top</a>";
    }
?>

Efektem jest umożliwienie przechodzenia z górnej strony do przodu na drugą stronę iz powrotem (np. Anuluj) przy użyciu własnych linków. Jednak po powrocie na stronę główną przycisk Wstecz przeglądarki nie może przejść do strony dodatkowej.

Anono Mouser
źródło
0

Nawet ja miałem wcześniej taką samą sytuację ... i nie miałem żadnej pomocy. spróbuj tych rzeczy, może te będą działać dla Ciebie

w <head>tagu strony logowania :

<script type="text/javascript">
    window.history.forward();
</script>

w przycisku wylogowania zrobiłem to:

protected void Btn_Logout_Click(object sender, EventArgs e)      
{
    connObj.Close();
    Session.Abandon();
    Session.RemoveAll();
    Session.Clear();
    HttpContext.Current.Session.Abandon();
}

a na stronie logowania skupiłem się na polu tekstowym Nazwa użytkownika w następujący sposób:

protected void Page_Load(object sender, EventArgs e)
{
    _txtUsername.Focus();
}

mam nadzieję, że to pomoże ... :) niech ktoś mnie nauczy, jak edytować tę stronę ...

Rudzik
źródło
a) edytuj swoją odpowiedź b) kliknij znak zapytania c) kliknij pomoc zaawansowaną d) przeczytaj i zastosuj :-) Zwróć również uwagę, że ctrl-k usuwa / wcina wybrany blok, aby usunąć / sformatować jako kod. Plus formater nie może również obsługiwać kart (prawdopodobnie nie jest to problem tutaj, choć)
Kleopatra
0

JEŚLI potrzebujesz delikatnie ukryć klawisze delete i backspace w swojej aplikacji internetowej, aby podczas edycji / usuwania elementów strona nie została nieoczekiwanie przekierowana, możesz użyć tego kodu:

window.addEventListener('keydown', function(e) {
  var key = e.keyCode || e.which;
  if (key == 8 /*BACKSPACE*/ || key == 46/*DELETE*/) {
    var len=window.location.href.length;
    if(window.location.href[len-1]!='#') window.location.href += "#";
  }
},false);
nvd_ai
źródło
0

Wypróbuj ten kod. Wystarczy zaimplementować ten kod na stronie wzorcowej i będzie on działał na wszystkich stronach

<script type="text/javascript">
    window.onload = function () {
        noBack();
    }
    function noBack() {
        window.history.forward();
    }
</script>
<body  onpageshow="if (event.persisted) noBack();">
</body>
Suhaib Janjua
źródło
0

Problem z Yossi Shasho kodeksu jest to, że strona jest przewijanie do szczytu co 50 ms. Więc zmodyfikowałem ten kod. Teraz działa dobrze we wszystkich nowoczesnych przeglądarkach, IE8 i nowszych

var storedHash = window.location.hash;
function changeHashOnLoad() {
    window.location.href += "#";
    setTimeout("changeHashAgain()", "50");
}

function changeHashAgain() {
    window.location.href += "1";
}

function restoreHash() {
    if (window.location.hash != storedHash) {
        window.location.hash = storedHash;
    }
}

if (window.addEventListener) {
    window.addEventListener("hashchange", function () {
        restoreHash();
    }, false);
}
else if (window.attachEvent) {
    window.attachEvent("onhashchange", function () {
        restoreHash();
    });
}
$(window).load(function () { changeHashOnLoad(); });
Vishnu TS
źródło
0

Wydaje się, że to zadziałało dla nas.

history.pushState(null, null, $(location).attr('href'));
window.addEventListener('popstate', function () {
    history.pushState(null, null, $(location).attr('href'));
});
jgabb
źródło
0
<script>
    $(document).ready(function() {
        function disableBack() { window.history.forward() }

        window.onload = disableBack();
        window.onpageshow = function(evt) { if (evt.persisted) disableBack() }
    });
</script>
chetan
źródło