Mam urządzenie z internetowym panelem sterowania i przypadkowo ustawiłem przekierowanie wszystkich http
stron 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 https
adres.
Ja już zamknięte Safari, wyczyszczone ~/Library/Caches/com.apple.Safari/
i ~/Library/Cookies/HSTS.plist
ale 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.
~/Library/Safari
folder i sprawdzić, czy to rozwiąże problem? Jeśli tak, możesz eksperymentować z elementami w folderze, aż znajdziesz plik winowajcy.Odpowiedzi:
Na podstawie odpowiedzi kwanty :
Nie mogłem używać,
launchctl unload /System/Library/LaunchAgents/com.apple.nsurlstoraged.plist
ponieważ mam włączoną ochronę integralności systemu :Byłem jednak w stanie obejść ten problem, wykonując następujące czynności:
killall nsurlstoraged
(zatrzymuje proces nsurlstoraged użytkownika; faktycznie uruchomiłemsudo 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)źródło
HSTS.plist
pliku nie rozwiąże problemu, ponieważ będzie on nadal odbudowywany. Jednak po zabiciu,nsurlstoraged
a następnie usunięciu pliku HSTS - załatwiło sprawę!~/Library/Cookies/HSTS.plist
i usuń wpis witryny, którą chcę na http 3. Uruchom ponownie komputerrm -f ~/Library/Cookies/HSTS.plist
zostanie zwrócone,Operation not permitted
chyba ż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!rm ~/Library/Cookies/HSTS.plist ; touch ~/Library/Cookies/HSTS.plist ; chmod guo-wrx ~/Library/Cookies/HSTS.plist
mi nie pomógł, ale pomógłkillall nsurlstoraged
.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?
źródło
~/Library/Caches/com.apple.Safari
przekierowania, 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
.Na podstawie odpowiedzi @ Haravikk: /apple//a/267783/62907
fs_usage może pomóc:
Więc możemy:
następnie:
i spróbuj ponownie.
źródło
Będziesz mieć dobre wyniki, jeśli użyjesz wiersza poleceń do
curl
urzą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 .
źródło
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.plist
rzeczywiś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:
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.rm ~/Library/Cookies/HSTS.plist
i naciśnij klawisz Enter, spowoduje to usunięcie pliku pamięci HSTS.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.plist
plik? Kiedy już wiemy, że powinno być możliwe prostsze rozwiązanie problemu.źródło
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/hosts
pliku komputera lokalnego .Załóżmy na przykład, że bieżące przekierowanie z pamięci podręcznej pochodzi z
http://example.com
dohttps://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:Otrzymasz wynik mniej więcej taki:
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:
Zapisz zmiany i wyczyść pamięć podręczną DNS w terminalu w następujący sposób:
Następnie w przeglądarce Safari z prośbą o
https://example.com
odpowiedź powinno być przekierowanie z powrotem dohttp://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.
źródło
~/Library/Cookies/HSTS.plist
był 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.Po wypróbowaniu wszystkich tych rozwiązań zadziałało dla mnie:
~/Library/Cookies/HSTS.plist
źródło
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 sudob) nie możesz usunąć „HSTS.plist”: jeśli wpiszesz:
otrzymujesz: Operacja niedozwolona
c) nawet jeśli spróbujesz:
otrzymujesz: Operacja niedozwolona
to samo dla
(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 /”
i możesz usunąć myszą:
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 ..)
źródło
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.
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.
źródło
Najpierw upewnij się, że serwer nie wysyła nagłówka Strict-Transport-Security.
Możesz to zrobić za pomocą
curl -I
(-I
tylko pobiera nagłówki)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
~/Library/Cookies/HSTS.plist
Wyszukaj wpis witryny, do której chcesz uzyskać dostęp przez http, usuń go i zapisz plik.
nsurlstoraged
ale 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
źródło
Stworzyłem skrypt z odpowiedzi Grand Heaslip:
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
źródło
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.
źródło
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
źródło