Як я можу повністю стерти кешовані перенаправлення із Safari?

У мене є пристрій із веб-панеллю керування, і випадково встановив його для переадресації всіх httpсторінок https, хоча деякі з них не працюють https. Хоча я з цього часу виправляв це, схоже, Safari запам'ятав переспрямування і відмовляється його забути, натомість постійно намагається перенаправити мене на недійсну httpsадресу.

Я вже закрив Safari, очищається ~/Library/Caches/com.apple.Safari/і , ~/Library/Cookies/HSTS.plistале вона по- , як і раніше здається, згадуючи редирект , коли я знову відкрити його.

Де ще Safari може зберігати цю інформацію? Я можу отримати доступ до правильної сторінки через Firefox або Chrome, тому це може бути не сервісом на всій системі, або якщо це не той, який використовують інші браузери.

На жаль, оскільки веб-панель надається пристроєм, я не вірю, що я можу налаштувати заголовки або встановити переадресацію назад до правильної URL-адреси, що, здається, є варіантами, запропонованими в інших подібних питаннях, тому мені дійсно потрібно з’ясувати, де це дані зберігаються, тому я можу знищити їх вогнем.

Виходячи з відповіді квантів :

Мені не вдалося скористатися, launchctl unload /System/Library/LaunchAgents/com.apple.nsurlstoraged.plistоскільки ввімкнено захист цілісності системи :

$ 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

Однак мені вдалося обійти це, зробивши наступне:

• killall nsurlstoraged(зупиняє процес nsurlstoraged вашого користувача; я фактично запускався sudo killall nsurlstoraged, але підозрюю, що не потрібно також зупиняти nsurlstoraged системи, оскільки кеш знаходиться в папці Бібліотека користувача)
• rm -f ~/Library/Cookies/HSTS.plist (видаляє кеш HSTS)
• launchctl start /System/Library/LaunchAgents/com.apple.nsurlstoraged.plist (перезапускає nsurlstoraged)

Якщо ввімкнути меню "Розвиток" у налаштуваннях Safari, ви можете очистити кеш звідти (CMD + ALT + E).

Чи можете ви підтвердити, що відкриття панелі управління пристрою в приватному вікні Safari (або іншому веб-браузері) працює правильно?

На основі відповіді @ Haravikk: /apple//a/267783/62907

У когось є ідеї, який процес відповідає за файл ~ / Бібліотека / Файли cookie / HSTS.plist?

fs_usage може допомогти:

❯❯❯❯ 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

Отже, ми можемо:

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

потім:

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

і спробуйте ще раз.

У вас будуть хороші результати, якщо ви використовуєте командний рядок на curlпристрої, щоб переконатися, що він не робить перенаправлення. У Safari насправді немає механізму переписувати адреси, особливо якщо ви переходите до приватного веб-перегляду, щоб видалити історію, файли cookie тощо ...

Якщо ви не впевнені, що достатньо очистили сафарі, можете також протестувати, відкривши системні налаштування та створивши чистий / новий обліковий запис користувача на Mac і протестувавши сайт на абсолютно чистій версії Safari після виходу зі свого звичайного користувача .

Тому я знайшов вирішення проблеми, хоча це не остаточна відповідь на власне питання, тому я не буду відзначати його як таке, поки не зможу знайти більше інформації.

Виявляється, що файл ~/Library/Cookies/HSTS.plistсправді був джерелом проблеми, як я підозрював, однак видалення його з ураженого облікового запису користувача не працює, навіть із закритим Safari, оскільки він відтворений через невідомий час, укупі з порушенням запис, який примушував недійсне переспрямування.

Тож моє рішення було наступним:

1. Переконайтеся, що у вас на комп’ютері принаймні один обліковий запис користувача (якщо ні, створіть його).
2. Вихід із облікового запису постраждалого користувача.
3. Увійти в інший обліковий запис користувача (обліковий запис гостя може бути недостатним, залежно від обмежень).
4. Дізнайтеся коротке ім’я вашого облікового запису користувача; якщо ви не знаєте, то найкращий спосіб перевірити це заглянути у розділі Налаштування системи -> Користувачі. Зазвичай, якщо це буде повне ім'я, нижній регістр і без пробілів, тож якщо ваше повне ім’я "Джон Сміт", тоді коротке ім'я може бути "джонсмітом".
5. Відкрийте вікно у терміналі, введіть su shortnameзаміну "короткого імені" на коротке ім'я облікового запису користувача, який впливає. Натисніть клавішу Enter і, коли буде запропоновано, введіть пароль для цього облікового запису.
6. Тепер введіть наступну команду rm ~/Library/Cookies/HSTS.plistі натисніть клавішу Enter, це видалить файл зберігання HSTS.
7. Нарешті наберіть exit, натисніть клавішу Enter та закрийте Термінал.

На цьому етапі ви можете знову увійти до облікового запису користувача, і перенаправлення HSTS, яке порушило право, має бути загублено назавжди.

Тепер, хоча це забезпечує корисний спосіб вирішення проблеми, я хотів би знати, чому видалення файлу HSTS.plist із мого облікового запису не вдалося; той факт, що він відтворений, означає, що за нього відповідає деякий фоновий процес, а це означає, що слід видалити файл із облікового запису користувача, просто зупинивши цей процес, видаливши файл, а потім повторно запустивши процес.

У когось є ідеї, який процес відповідає за ~/Library/Cookies/HSTS.plistфайл? Як тільки ми дізнаємось, що слід дати можливість простішого виправлення проблеми.

Ось ідея!

Ви кажете, що не можете скасувати переадресацію, встановивши сервер перенаправляти https-запити назад на http (оскільки у вас немає доступу адміністратора для цього).

Але що робити, якщо ви обдурите сафарі підключення до іншого сервера, який пропонує це зворотне переспрямування?

Ви можете встановити це у /etc/hostsфайлі локальної машини .

Наприклад, скажімо, що поточне кешоване переспрямування переходить від http://example.comдо https://example.com.

Тепер налаштуйте або визначте URL-адресу, який ви можете запитувати на будь-якому сервері в світі, який перенаправляє з https назад на http. Скажімо, що сервер має адресу https://redirecting.example.com.

Потім знайдіть IP-адресу redirecting.example.com. У Терміналі ви можете зробити так:

host redirecting.example.com

Ви отримуєте такий результат:

redirecting.example.com has address 69.69.69.69

Тепер відкрийте файл / etc / hosts та додайте новий рядок, який вказує запити для example.com на ip адресу redirecting.example.com, як-от так:

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

Збережіть зміни та очистіть кеш DNS у терміналі так:

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

Тоді в Safari зробити запит https://example.comна відповідь слід перенаправленням назад http://example.com, в який момент (перехрещеними пальцями) ваше перенаправлення Safari від 6 місяців тому буде перезаписане.

По завершенні видаліть рядок, який ви додали до файлу / etc / hosts, і знову очистіть кеш DNS.

Перепробувавши всі ці рішення, для мене працювало:

• Видаліть усі екземпляри домену з історії Safari
• Киньте сафарі
• Видалити ~/Library/Cookies/HSTS.plist
• Перезапустити

Мої два центи на новий macOS Mojave 10.14 Beta (18A365a)

а) Ви не можете остаточно зупинитисьnsurlstoraged , він заново запускається за 2 секунди, навіть якщо судо

б) ви не можете видалити "HSTS.plist": якщо ви введете:

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

Ви отримуєте: Операція заборонена

в) навіть якщо ви спробуєте:

ls -la ~/Library/Cookies/

Ви отримуєте: Операція заборонена

те саме для

nano ~/Library/Cookies/HSTS.plist 

(порожній файл ..)

Таким чином, ви не можете точно отримати доступ до нього. (можливо, SIP?)

г) дивним чином ви можете видалити, якщо з Finder:

CMD Shift G "~ / Бібліотека / Файли cookie /"

і ви можете видалити за допомогою миші:

д) ще дивніше: ви можете перейти на робочий стіл за допомогою миші, відредагувати та розмістити його назад !

(справжня дурниця, графічний інтерфейс є потужнішим, ніж судо.)

У Safari, Firefox та Chrome також потрібно лише відкрити бічну панель розробника , вибрати вкладку мережі та відключити кеш-пам'ять g.

У Safari це перекреслена трубка, синя поруч із логотипом сміттєвого сміття. Активуйте це, і старе постійне переспрямування слід ігнорувати.

Найбільша перевага полягає в тому, що вам не доведеться возитися з файлами, ви не будете видаляти всі записи HTST і втрачаєте переваги безпеки. Також він працює у веб-переглядачах.

Спочатку переконайтеся, що сервер не надсилає заголовок Strict-Transport-Security.
Це можна зробити за допомогою curl -I( -Iпросто отримує заголовки)

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

Якщо сервер надсилає заголовок Strict-Transport-Security, видалення його з браузера не матиме ефекту, оскільки наступного разу, коли ви перейдете на сайт, він буде встановлений знову.

Видаліть свій сайт із бази даних безпечної транспортної безпеки Safari

1. Закрийте Safari
2. Відредагуйте ~/Library/Cookies/HSTS.plist
   пошук запису для веб-сайту, до якого ви хочете отримати доступ, через http та видаліть його та збережіть файл.
   • Я вважаю за краще редагувати, а не видаляти, оскільки не потрібно видаляти дійсні записи.
   • Я редагую файли плістів за допомогою Xcode, але якщо він не встановлений, ви можете просто скористатися текстовим редактором.
3. Перезавантажте комп'ютер.
   • Замість перезавантаження комп'ютера ви можете перезапустити, nsurlstoragedале це може бути задіяно завдяки SIP, тому перезавантаження комп'ютера може бути простішим. Знайомства відповідь Гранта і відповідь Quanta в про перезапускnsurlstoraged

Я зробив сценарій з відповіді 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

Він витончено закінчує сафарі, зупиняє nsurlstoraged, видаляє HSTS.plist і починає nsurlstoraged знову. Це працювало для мене чудово на macOS 10.13.5

Я використовую Mojave (10.14). Я спробував методи, видані до цих пір, щоб видалити HSTS.plist. Крім того, мені потрібно було додати термінал до системних налаштувань> Безпека та конфіденційність> Повний список доступу до диска, щоб вилікувати симптом "Операція заборонена" при переліку вмісту ~ / Бібліотека / Файли cookie /.

Але видалити файл та перезапустити демон не вийшло. Тому я спробував відкрити Safari знову, перейшов до Налаштування, конфіденційності, Керування даними веб-сайтів Потім я видалив усі "кеш-файли, локальне зберігання" для доменного імені, яке порушує право. Це вирішило мою проблему.

Зараз не можу сказати, чи потрібно було видалити HSTS чи ні.

Спробуйте це, перейдіть до кроку 1: Перейдіть до папки ~ / Бібліотека, крок 2: Видаліть папку Safari з ~ / Бібліотека / Підтримка програм, Крок 3: Видаліть папки нижче з ~ / Бібліотека / Кеші, Крок 4: потім Видаліть ~ / Папка "Бібліотека / Safari PS": Зберігайте сафарі закритим під час вищезазначених операцій