Jak w pełni opróżnić buforowane przekierowania z Safari?

27

Mam urządzenie z internetowym panelem sterowania i przypadkowo ustawiłem przekierowanie wszystkich httpstron https, nawet jeśli niektóre nie działają https. Chociaż od tego czasu poprawiłem to, wygląda na to, że Safari zapamiętało przekierowanie i nie chce o nim zapomnieć, zamiast tego ciągle próbuje przekierować mnie na nieprawidłowy httpsadres.

Ja już zamknięte Safari, wyczyszczone ~/Library/Caches/com.apple.Safari/i ~/Library/Cookies/HSTS.plistale wciąż wydaje się być pamiętając przekierowanie kiedy ponownie go otworzyć.

Gdzie jeszcze Safari może przechowywać te informacje? Mogę uzyskać dostęp do właściwej strony za pośrednictwem przeglądarki Firefox lub Chrome, więc może to nie być usługa ogólnosystemowa lub jeśli nie jest to usługa, z której korzystają inne przeglądarki.

Niestety, ponieważ panel internetowy jest dostarczany przez urządzenie, nie sądzę, żebym mógł dostosować nagłówki lub skonfigurować przekierowanie z powrotem do poprawnego adresu URL, które wydają się być opcjami oferowanymi w innych podobnych pytaniach, więc naprawdę muszę się dowiedzieć, gdzie to dane są przechowywane, więc mogę je zniszczyć ogniem.

Haravikk
źródło
Zobacz także apple.stackexchange.com/questions/153503/...
Paul D. Waite
Czy próbowałeś usunąć / przenieść na bok ~/Library/Safarifolder i sprawdzić, czy to rozwiąże problem? Jeśli tak, możesz eksperymentować z elementami w folderze, aż znajdziesz plik winowajcy.
ciekawe,
Jak ustawiłeś przekierowanie? Z rozszerzeniem lub czy jest to ustawienie w Safari?
owlswipe
Czy przekierowanie nadal występuje w prywatnym oknie przeglądania?
AllInOne
@AllInOne ciekawy pomysł, ale niestety wciąż dzieje się to podczas prywatnego przeglądania.
Haravikk,

Odpowiedzi:

29

Na podstawie odpowiedzi kwanty :

Nie mogłem używać, launchctl unload /System/Library/LaunchAgents/com.apple.nsurlstoraged.plistponieważ mam włączoną ochronę integralności systemu :

$ launchctl unload /System/Library/LaunchAgents/com.apple.nsurlstoraged.plist
/System/Library/LaunchAgents/com.apple.nsurlstoraged.plist: Operation not permitted while System Integrity Protection is engaged

Byłem jednak w stanie obejść ten problem, wykonując następujące czynności:

  • killall nsurlstoraged(zatrzymuje proces nsurlstoraged użytkownika; faktycznie uruchomiłem sudo killall nsurlstoraged, ale podejrzewam, że nie jest konieczne zatrzymywanie również nsurlstoraged systemu, ponieważ pamięć podręczna znajduje się w folderze biblioteki użytkownika)
  • rm -f ~/Library/Cookies/HSTS.plist (usuwa pamięć podręczną HSTS)
  • launchctl start /System/Library/LaunchAgents/com.apple.nsurlstoraged.plist (restartuje nsurlstoraged)
Grant Heaslip
źródło
Nie mogę głosować wystarczająco za odpowiedzią. Wygląda na to, że przynajmniej w Sierra po prostu usunięcie HSTS.plistpliku nie rozwiąże problemu, ponieważ będzie on nadal odbudowywany. Jednak po zabiciu, nsurlstorageda następnie usunięciu pliku HSTS - załatwiło sprawę!
nvahalik
1
Dziękuję bardzo, głosowałem, ale zrobiłem to w ten sposób. 1. Zamknij Safari 2. Edytuj ~/Library/Cookies/HSTS.plisti usuń wpis witryny, którą chcę na http 3. Uruchom ponownie komputer
Jason S
Tak, ponowne uruchomienie jest wskazówką, którą udzielają wszystkie pozostałe odpowiedzi, ale przy 20 uruchomionych aplikacjach znacznie wygodniej i szybciej jest zrestartować proces nsurlstoraged. Dzięki @nvahalik!
axello
2
Aktualizacja Mojave: polecenie rm -f ~/Library/Cookies/HSTS.plistzostanie zwrócone, Operation not permittedchyba że przyznałeś pełny dostęp do dysku Terminal.app w Preferencjach systemowych => Bezpieczeństwo i prywatność => Prywatność. W przeciwnym razie rozwiązanie działało idealnie! Dzięki!
JoeHanna
@ nvahalik To, co się dzieje, wydaje się jeszcze dziwniejsze niż przebudowywany plik; nawet rm ~/Library/Cookies/HSTS.plist ; touch ~/Library/Cookies/HSTS.plist ; chmod guo-wrx ~/Library/Cookies/HSTS.plistmi nie pomógł, ale pomógł killall nsurlstoraged.
Flash Sheridan
6

Jeśli włączysz menu Develop w preferencjach Safari, możesz wyczyścić stamtąd pamięć podręczną (CMD + ALT + E).

Czy możesz potwierdzić, że otwarcie panelu sterowania urządzenia w prywatnym oknie Safari (lub innej przeglądarce) działa poprawnie?

Filip Jurik
źródło
Niestety wydaje się, że opcja menu rozwijania nie usuwa ~/Library/Caches/com.apple.Safariprzekierowania, podobnie jak zamykanie Safari i ręczne usuwanie, więc przekierowanie musi być przechowywane gdzie indziej. HSTS to funkcja, którą przypadkowo włączyłem, ale już ją usunąłem ~/Library/Cookies/HSTS.plist.
Haravikk,
1
Mogę również potwierdzić, że ta odpowiedź nie rozwiązuje problemu
malhal
Ten zadziałał dla mnie
Matthew Cawley
5

Na podstawie odpowiedzi @ Haravikk: /apple//a/267783/62907

Czy ktoś ma jakieś pomysły, który proces jest odpowiedzialny za plik ~ / Library / Cookies / HSTS.plist?

fs_usage może pomóc:

❯❯❯❯ sudo fs_usage | grep HSTS
16:11:03    HFS_update      /Users/quanta/Library/Cookies/HSTS.plist                                         0.000238   nsurlstorage
16:11:03    HFS_update      /Users/quanta/Library/Cookies/HSTS.plist                                         0.000009   nsurlstorage
16:11:03  open              /Users/quanta/Library/Cookies/HSTS.plist                                         0.016268   nsurlstorage
16:11:03    HFS_update      /Users/quanta/Library/Cookies/HSTS.plist                                         0.000008   nsurlstorage
16:11:03    HFS_update      /Users/quanta/Library/Cookies/HSTS.plist                                         0.000003   nsurlstorage
16:11:03  access            /Users/quanta/Library/Cookies/HSTS.plist                                         0.000011   dbfseventsd
16:11:04  lstat64           /Users/quanta/Library/Cookies/HSTS.plist                                         0.000008   fseventsd
16:11:08    HFS_update      /Users/quanta/Library/Cookies/HSTS.plist                                         0.000006   nsurlstorage
16:11:08    HFS_update      /Users/quanta/Library/Cookies/HSTS.plist                                         0.000002   nsurlstorage
16:11:08  open              /Users/quanta/Library/Cookies/HSTS.plist                                         0.000144   nsurlstorage
16:11:08    HFS_update      /Users/quanta/Library/Cookies/HSTS.plist                                         0.000002   nsurlstorage
16:11:08    HFS_update      /Users/quanta/Library/Cookies/HSTS.plist                                         0.000003   nsurlstorage
16:11:08  access            /Users/quanta/Library/Cookies/HSTS.plist                                         0.000021   dbfseventsd
16:11:09  lstat64           /Users/quanta/Library/Cookies/HSTS.plist                                         0.000042   fseventsd

Więc możemy:

launchctl unload /System/Library/LaunchAgents/com.apple.nsurlstoraged.plist

następnie:

rm -f ~/Library/Cookies/HSTS.plist

i spróbuj ponownie.

kwanty
źródło
Dzięki! To zadziałało dla mnie. Wiele razy usunąłem HSTS.plist (zamykanie / restartowanie Safari przed i po) i zawsze było ono odtwarzane z dokładnie taką samą zawartością jak wcześniej. Najpierw rozładowanie nsurlstoraged, a następnie usunięcie plist i ponowne uruchomienie nsurlstoraged dało mi czysty plist.
lucianf
2
Możesz to poprawić, wspominając, że musisz zamknąć i ponownie uruchomić Safari, aby działało. Zamiast usunąć HSTS.plist właśnie usunąłem problematyczny klucz domeny.
malhal
3

Będziesz mieć dobre wyniki, jeśli użyjesz wiersza poleceń do curlurządzenia, aby upewnić się, że nie wykonuje przekierowania. Safari tak naprawdę nie ma silnika do przepisywania adresów - szczególnie jeśli przejdziesz do przeglądania prywatnego, aby usunąć historię, pliki cookie itp.

Jeśli nie masz pewności, czy wystarczająco wyczyściłeś swoje safari, możesz również przetestować, otwierając preferencje systemowe i tworząc czyste / nowe konto użytkownika na komputerze Mac oraz przetestować witrynę w całkowicie czystej wersji Safari po wylogowaniu się z normalnego użytkownika .

bmike
źródło
Na pewno nie ma przekierowania (funkcja, z którą próbuję się połączyć, wcale nie obsługuje HTTPS, dlatego włączenie HSTS dla całego urządzenia było straszną, straszną pomyłką); Mogę połączyć się dobrze z innymi kontami użytkowników i przeglądarkami, więc jest coś gdzieś na moim głównym koncie, które
buforuje
„Safari tak naprawdę nie ma silnika do przepisywania adresów” - obecnie mam ten sam problem, który występuje w Safari z witryną hostowaną na moim laptopie i zwijaniem się (wraz z Firefox, Chrome i oknem przeglądania prywatnego w tym miejscu w Safari) na tym samym koncie użytkownika ładuje witrynę w porządku. Musi to mieć coś wspólnego z samym Safari.
Paul D. Waite
3

Znalazłem więc obejście problemu, chociaż nie jest to ostateczna odpowiedź na rzeczywiste pytanie, więc nie oznaczę go jako takiego, dopóki nie znajdę więcej informacji.

Okazuje się, że plik ~/Library/Cookies/HSTS.plistrzeczywiście był źródłem problemu, jak podejrzewałem, jednak usunięcie go z konta użytkownika, którego dotyczy problem, nie działa, nawet przy zamkniętym Safari, ponieważ jest odtwarzane po nieznanym czasie, wraz z przestępstwem pozycja, która wymuszała nieprawidłowe przekierowanie.

Więc moje rozwiązanie było następujące:

  1. Upewnij się, że masz przynajmniej jedno inne konto użytkownika na komputerze Mac (jeśli nie, utwórz je).
  2. Wyloguj się z konta użytkownika, którego dotyczy problem.
  3. Zaloguj się do innego konta użytkownika (konto gościa może nie być wystarczające, w zależności od ograniczeń).
  4. Znajdź skróconą nazwę konta użytkownika, którego dotyczy problem; jeśli nie wiesz, najlepszym sposobem na sprawdzenie jest sprawdzenie w Preferencjach systemowych -> Użytkownicy. Zwykle jeśli będzie to pełna nazwa, małe litery i bez spacji, więc jeśli twoje pełne imię to „John Smith”, to skróconą nazwą może być „johnsmith”.
  5. Otwórz okno w terminalu i wpisz su shortname„krótka nazwa” krótką nazwą konta użytkownika, którego dotyczy problem. Naciśnij Enter i po wyświetleniu monitu wprowadź hasło do konta, którego dotyczy problem.
  6. Teraz wpisz następne polecenie rm ~/Library/Cookies/HSTS.plisti naciśnij klawisz Enter, spowoduje to usunięcie pliku pamięci HSTS.
  7. Na koniec wpisz exit, naciśnij Enter i zamknij Terminal.

W tym momencie możesz teraz zalogować się ponownie na konto użytkownika, którego dotyczy problem, a szkodliwe przekierowanie HSTS powinno zniknąć na dobre.

Teraz, mimo że zapewnia to użyteczne obejście, naprawdę chciałbym wiedzieć, dlaczego usunięcie pliku HSTS.plist z mojego konta nie zadziałało; fakt jego odtworzenia oznacza, że ​​jest za to odpowiedzialny proces w tle, co oznacza, że ​​powinno być możliwe usunięcie pliku z konta użytkownika, którego dotyczy problem, poprzez zatrzymanie tego procesu, usunięcie pliku, a następnie ponowne uruchomienie procesu.

Czy ktoś ma jakieś pomysły, który proces jest odpowiedzialny za ~/Library/Cookies/HSTS.plistplik? Kiedy już wiemy, że powinno być możliwe prostsze rozwiązanie problemu.

Haravikk
źródło
2

Oto pomysł!

Mówisz, że nie możesz cofnąć przekierowania, ustawiając serwer tak, aby przekierowywał żądania https z powrotem na http (ponieważ nie masz do tego dostępu administratora).

Ale co jeśli oszukasz safari, aby połączyć się z innym serwerem, który oferuje to przekierowanie zwrotne?

Możesz to ustawić w /etc/hostspliku komputera lokalnego .

Załóżmy na przykład, że bieżące przekierowanie z pamięci podręcznej pochodzi z http://example.comdo https://example.com.

Teraz skonfiguruj lub zidentyfikuj adres URL, którego możesz zażądać na dowolnym serwerze na świecie, który przekierowuje z https z powrotem na http. Powiedzmy, że serwer ma adres https://redirecting.example.com.

Następnie wyszukaj adres IP redirecting.example.com. W Terminalu możesz to zrobić w następujący sposób:

host redirecting.example.com

Otrzymasz wynik mniej więcej taki:

redirecting.example.com has address 69.69.69.69

Teraz otwórz plik / etc / hosts i dodaj nowy wiersz, który kieruje żądania do example.com na adres IP przekierowania.example.com, w następujący sposób:

### point host example.com at the ip address of redirecting.example.com
69.69.69.69 example.com

Zapisz zmiany i wyczyść pamięć podręczną DNS w terminalu w następujący sposób:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder; say DNS cache flushed

Następnie w przeglądarce Safari z prośbą o https://example.comodpowiedź powinno być przekierowanie z powrotem do http://example.com, w którym momencie (kciuki) przekierowanie Safari sprzed 6 miesięcy zostanie zastąpione.

Po zakończeniu usuń wiersz dodany do pliku / etc / hosts i ponownie opróżnij pamięć podręczną DNS.

Wszystko w jednym
źródło
Chociaż jest to dobry pomysł, nie rozwiązuje prawdziwego problemu; Nie szukam obejść, ale raczej chcę wiedzieć, gdzie to przekierowanie jest buforowane, aby Safari nadal go używało, nawet jeśli nie jest już poprawne (serwer nie ma włączonego HSTS, po prostu przez pomyłkę włączyłem go na krótko ). To musi być przechowywane gdzieś, ale nie mogę dowiedzieć się, gdzie.
Haravikk
Nie to nazwałbym obejściem, ponieważ spodziewam się, że rozwiąże to rzeczywisty problem . Działa to tylko wokół faktu, że nie masz kontroli nad urządzeniem. Ale słyszę cię - byłoby miło móc bezpośrednio wyczyścić buforowane ustawienie. Czy przegląd technologii Safari również wykazuje złe zachowanie?
AllInOne
Niestety tak; Nie sądzę, że jest to problem z samym Safari jako takim, ale raczej z pewną usługą macOS, od której tak naprawdę wydaje się, że ~/Library/Cookies/HSTS.plistbył winowajcą, ale usunięcie go z konta, którego dotyczy problem, nie działa (ponieważ jest odtwarzane jakiś czas później, wraz ze złym przekierowaniem). Nie jestem jednak pewien, jaki proces to robi.
Haravikk
2

Po wypróbowaniu wszystkich tych rozwiązań zadziałało dla mnie:

  • Usuń wszystkie instancje domeny z historii Safari
  • Zamknij Safari
  • Kasować ~/Library/Cookies/HSTS.plist
  • Uruchom ponownie
Edward Loveall
źródło
2

Moje dwa centy za nowy system macOS Mojave 10.14 Beta (18A365a)

a) Nie można definitywnie zatrzymać sięnsurlstoraged , uruchamia się ponownie w ciągu 2 sekund, nawet jeśli sudo

b) nie możesz usunąć „HSTS.plist”: jeśli wpiszesz:

sudo rm -f ~/Library/Cookies/HSTS.plist

otrzymujesz: Operacja niedozwolona

c) nawet jeśli spróbujesz:

ls -la ~/Library/Cookies/

otrzymujesz: Operacja niedozwolona

to samo dla

nano ~/Library/Cookies/HSTS.plist 

(pusty plik..)

Więc nie możesz definitywnie uzyskać do niego dostępu . (może SIP?)

d) o dziwo możesz usunąć, jeśli z Findera:

CMD Shift G „~ / Library / Cookies /”

wprowadź opis zdjęcia tutaj

i możesz usunąć myszą:

wprowadź opis zdjęcia tutaj

e) bardziej dziwne: możesz przenieść się na pulpit za pomocą myszy, edytować i umieścić go z powrotem !

(prawdziwy nonsens, GUI ma większą moc niż sudo ..)

ingconti
źródło
2

W Safari, Firefox i Chrome wystarczy otworzyć pasek boczny programisty , wybrać kartę sieciową i wyłączyć cachin g.

W Safari jest to przekreślona tuba, niebieska obok logo kosza na śmieci. Aktywuj to, a stare stałe przekierowanie powinno zostać zignorowane. Safari wyłącza chaching 503 stałych przekierowań

Największą zaletą jest to, że nie musisz bawić się plikami, nie usuniesz wszystkich wpisów HTST i nie stracisz korzyści bezpieczeństwa. Działa również w różnych przeglądarkach.

luckydonald
źródło
Chociaż warto to wiedzieć, czy możesz potwierdzić, czy działa ono jako trwałe rozwiązanie? tzn. jeśli pamięć podręczna zostanie ponownie włączona, czy problem pojawi się ponownie, czy też tymczasowe wyłączenie go opróżni?
Haravikk
1
@Haravikk w moich testach nie powróciłoby do używania stałego przekierowania, gdy zamiast tego można załadować nową stronę. Nawet po zamknięciu okna programowania, jeśli to odpowiada na twoje pytanie
luckydonald
1

Najpierw upewnij się, że serwer nie wysyła nagłówka Strict-Transport-Security.
Możesz to zrobić za pomocą curl -I( -Itylko pobiera nagłówki)

curl -I http://my-http-domain.com

Jeśli serwer wysyła nagłówek Strict-Transport-Security, usunięcie go z przeglądarki nie przyniesie żadnego efektu, ponieważ przy następnym wejściu na stronę zostanie ono ustawione ponownie.

Usuń swoją witrynę z bazy danych Http Secure Transport Security Safari

  1. Zamknij Safari
  2. Edytuj ~/Library/Cookies/HSTS.plist
    Wyszukaj wpis witryny, do której chcesz uzyskać dostęp przez http, usuń go i zapisz plik.
    • Wolę edytować niż usuwać, ponieważ nie ma potrzeby usuwania prawidłowych wpisów.
    • Pliki plist edytuję za pomocą Xcode, ale jeśli nie jest zainstalowany, możesz po prostu użyć edytora tekstu.
  3. Zrestartuj swój komputer.
    • Zamiast ponownego uruchamiania komputera można uruchomić ponownie, nsurlstoragedale może to być związane z SIP, więc ponowne uruchomienie komputera może być prostsze. Patrz odpowiedź Granta i odpowiedź Quanta jest o ponownym włączeniemnsurlstoraged
Jason S.
źródło
1

Stworzyłem skrypt z odpowiedzi Grand Heaslip:

#!/bin/sh

osascript -e 'quit app "Safari"'
sleep 2
killall nsurlstoraged
sleep 2
rm -f ~/Library/Cookies/HSTS.plist
launchctl start /System/Library/LaunchAgents/com.apple.nsurlstoraged.plist

Z wdziękiem kończy safari, zatrzymuje nsurlstoraged, usuwa HSTS.plist i ponownie uruchamia nsurlstoraged. To działało dobrze dla mnie tutaj na macOS 10.13.5

Martin Emrich
źródło
1

Korzystam z Mojave (10.14). Próbowałem metod podanych do tej pory, aby usunąć HSTS.plist. Ponadto musiałem dodać terminal do listy Preferencje systemowe> Bezpieczeństwo i prywatność> Pełny dostęp do dysku, aby wyleczyć objaw „Operacja niedozwolona” przy wyświetlaniu zawartości ~ / Library / Cookies /.

Ale usunięcie pliku i ponowne uruchomienie demona nie działało. Więc spróbowałem ponownie otworzyć Safari, poszedłem do Preferencji, Prywatności, Zarządzaj danymi witryny. Następnie usunąłem wszystkie „pamięć podręczną plików cookie, pamięć lokalna” dla naruszającej nazwy domeny. To rozwiązało mój problem.

Nie mogę teraz powiedzieć, czy usunięcie HSTS było wymagane, czy nie.

Bob Peterson
źródło
Próbowałem tego samego i zrestartowałem się dwa razy, ale tylko dla mnie zadziałał interfejs użytkownika Safari. Dziękuję Ci!
Bart Verkoeijen
-1

Spróbuj tego, następnie przejdź do kroku 1: przejdź do folderu ~ / Library, krok 2: usuń folder Safari z ~ / Library / Application Support, krok 3: usuń poniższe foldery z ~ / Library / Caches, krok 4: następnie usuń ~ / Biblioteka / folder Safari PS: trzymaj safari zamknięte podczas powyższych operacji

Omi Harjani
źródło
1
Odpowiedzi na Ask Different muszą być czymś więcej niż tylko linkiem. Można dołączyć link, ale proszę streść go lub fragmentuj w odpowiedzi. Chodzi o to, aby odpowiedź była samodzielna.
nohillside