Comment puis-je vider complètement les redirections mises en cache depuis Safari?

27

J'ai un appareil avec un panneau de configuration basé sur le Web et je l'ai accidentellement configuré pour rediriger toutes les httppages vers https, même si certaines ne fonctionnent pas https. Bien que j'aie depuis corrigé cela, Safari semble avoir mémorisé la redirection et refuse de l'oublier, essayant plutôt de me rediriger constamment vers l' httpsadresse invalide .

J'ai déjà fermé Safari, effacé ~/Library/Caches/com.apple.Safari/et ~/Library/Cookies/HSTS.plistmais il semble toujours se souvenir de la redirection lorsque je le rouvre.

Où Safari pourrait-il stocker ces informations ailleurs? Je peux accéder à la bonne page via Firefox ou Chrome, donc ce n'est peut-être pas un service à l'échelle du système, ou si ce n'est pas celui que les autres navigateurs utilisent.

Malheureusement, parce que le panneau Web est fourni par un appareil, je ne pense pas pouvoir ajuster les en-têtes ou configurer une redirection vers l'URL correcte, qui semblent être des options proposées dans d'autres questions similaires, j'ai donc vraiment besoin de savoir où cela les données sont stockées afin que je puisse les détruire avec le feu.

safari url macos

— Haravikk
source

Voir aussi apple.stackexchange.com/questions/153503/…

— Paul D. Waite

Avez-vous essayé de supprimer / déplacer votre ~/Library/Safaridossier et de voir si cela résout le problème? Si c'est le cas, vous pouvez expérimenter avec des éléments dans le dossier jusqu'à ce que vous trouviez le fichier coupable.

— intéressant de noter que

Comment avez-vous défini la redirection? Avec une extension ou existe-t-il un paramètre dans Safari pour cela?

— owlswipe

La redirection se produit-elle toujours avec une fenêtre de navigation privée?

— AllInOne

@AllInOne idée intéressante, mais malheureusement, cela se produit toujours sous navigation privée.

— Haravikk

29

Basé sur la réponse de quanta :

Je n'ai pas pu l'utiliser launchctl unload /System/Library/LaunchAgents/com.apple.nsurlstoraged.plistcar j'ai activé la protection de l'intégrité du système :

$ 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

Cependant, j'ai pu contourner ce problème en procédant comme suit:

killall nsurlstoraged(arrête le processus nsurlstoraged de votre utilisateur; j'ai en fait exécuté sudo killall nsurlstoraged, mais je soupçonne qu'il n'est pas nécessaire d'arrêter également nsurlstoraged du système, car le cache se trouve dans le dossier Bibliothèque de l'utilisateur)
rm -f ~/Library/Cookies/HSTS.plist (supprime le cache HSTS)
launchctl start /System/Library/LaunchAgents/com.apple.nsurlstoraged.plist (redémarre nsurlstoraged)

— Grant Heaslip
source

Je ne peux pas assez voter pour cette réponse. Il semble qu'au moins sur Sierra, la simple suppression du HSTS.plistfichier ne résoudra pas le problème car il continuera d'être reconstruit. Cependant, après avoir tué nsurlstoragedet puis supprimer le fichier qui HSTS a fait l'affaire!

— nvahalik

1

Merci beaucoup, voté positivement, mais je l'ai fait comme ça. 1. Fermez Safari 2. Modifiez ~/Library/Cookies/HSTS.plistet supprimez l'entrée pour le site que je veux sur http 3. Redémarrez l'ordinateur

— Jason S

Oui, le redémarrage est le conseil que toutes les autres réponses vous donnent, mais avec 20 applications ouvertes, il est beaucoup plus pratique et plus rapide de redémarrer le processus nsurlstoraged. Merci @nvahalik!

— axello

2

Mise à jour de Mojave: la commande rm -f ~/Library/Cookies/HSTS.plistreviendra Operation not permittedsauf si vous avez accordé un accès complet au disque à Terminal.app dans les Préférences Système => Sécurité et confidentialité => Confidentialité. Sinon, la solution a parfaitement fonctionné! Merci!

— joehanna

@ nvahalik Ce qui se passe semble encore plus étrange que le fichier en cours de reconstruction; ne rm ~/Library/Cookies/HSTS.plist ; touch ~/Library/Cookies/HSTS.plist ; chmod guo-wrx ~/Library/Cookies/HSTS.plistm'a même pas aidé, mais l'a killall nsurlstoragedfait.

— Flash Sheridan

6

Si vous activez le menu Développer dans les préférences de Safari, vous pouvez vider le cache à partir de là (CMD + ALT + E).

Pouvez-vous confirmer que l'ouverture du panneau de configuration de l'appareil dans la fenêtre privée de Safari (ou un navigateur Web différent) fonctionne correctement?

— Filip Jurik
source

Malheureusement, l'option de menu de développement ne semble pas effacer la redirection, ni la fermeture de Safari ni la suppression manuelle, de ~/Library/Caches/com.apple.Safarisorte que la redirection doit être stockée ailleurs. HSTS était la fonctionnalité que j'avais accidentellement activée mais que j'ai déjà supprimée ~/Library/Cookies/HSTS.plist.

— Haravikk

1

Je peux également confirmer que cette réponse ne le résout pas

— malhal

Celui-ci a fonctionné pour moi

— Matthew Cawley

5

Basé sur la réponse de @ Haravikk: /apple//a/267783/62907

Quelqu'un a une idée du processus responsable du fichier ~ / Library / Cookies / HSTS.plist?

fs_usage peut aider:

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

Afin que nous puissions:

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

ensuite:

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

et essayez à nouveau.

— quanta
source

Merci! Cela a fonctionné pour moi. J'ai supprimé HSTS.plist plusieurs fois (fermeture / redémarrage de Safari avant et après) et il était toujours recréé avec exactement le même contenu qu'auparavant. Décharger nsurlstoraged d'abord, puis supprimer la liste et redémarrer nsurlstoraged m'a donné une liste claire.

— lucianf

2

Vous pouvez améliorer cela en mentionnant que vous devez quitter et relancer Safari pour que cela fonctionne. Aussi, plutôt que de supprimer le HSTS.plist, je viens de supprimer la clé de domaine problématique.

— malhal

3

Vous obtiendrez de bons résultats si vous utilisez la ligne de commande vers curll'appareil pour vous assurer qu'il ne fait pas la redirection. Safari n'a pas vraiment de moteur pour réécrire les adresses - surtout si vous passez en navigation privée pour supprimer tout historique, cookies, etc ...

Si vous n'êtes pas sûr d'avoir suffisamment nettoyé votre safari, vous pouvez également tester en ouvrant les préférences système et en créant un compte utilisateur propre / nouveau sur le Mac et tester le site sur une version totalement propre de Safari après vous être déconnecté de votre utilisateur normal .

— bmike
source

Il n'y a certainement pas de redirection (la fonctionnalité à laquelle j'essaie de me connecter ne prend pas du tout en charge HTTPS, c'est pourquoi l'activation de HSTS pour l'ensemble de l'appareil a été une terrible, terrible erreur); Je peux me connecter très bien à partir d'autres comptes d'utilisateurs et navigateurs, donc il y a quelque chose stocké quelque part sur mon compte principal qui met cela en cache :(

— Haravikk

"Safari n'a pas vraiment de moteur pour réécrire les adresses" - J'ai actuellement le même problème sur Safari avec un site Web hébergé sur mon ordinateur portable, et curl (avec Firefox, Chrome et une fenêtre de navigation privée juste là dans Safari) sur le même compte utilisateur charge très bien le site. Cela doit donc être lié à Safari lui-même.

— Paul D. Waite

3

J'ai donc trouvé une solution de contournement au problème, bien que ce ne soit pas une réponse définitive à la question réelle, donc je ne le marquerai pas comme tel jusqu'à ce que je puisse trouver plus d'informations.

Il s'avère que le fichier ~/Library/Cookies/HSTS.plistétait en effet la source du problème comme je le soupçonnais, mais le supprimer du compte utilisateur affecté ne fonctionne pas, même avec Safari fermé, car il est recréé après un laps de temps inconnu, avec l'infraction entrée qui forçait la redirection non valide.

Ma solution était donc la suivante:

Assurez-vous d'avoir au moins un autre compte utilisateur sur votre Mac (sinon, créez-en un).
Déconnectez-vous du compte utilisateur concerné.
Connectez-vous à un autre compte utilisateur (un compte invité peut ne pas être suffisant, selon les restrictions).
Découvrez le nom abrégé de votre compte d'utilisateur affecté; si vous ne le savez pas, la meilleure façon de vérifier est de regarder sous Préférences Système -> Utilisateurs. Habituellement, si sera le nom complet, en minuscules et sans espaces, donc si votre nom complet est "John Smith", le nom court peut être "johnsmith".
Ouvrez une fenêtre dans Terminal, tapez en su shortnameremplaçant "nom abrégé" par le nom abrégé du compte d'utilisateur affecté. Appuyez sur Entrée et, lorsque vous y êtes invité, entrez le mot de passe du compte concerné.
Tapez maintenant la commande suivante rm ~/Library/Cookies/HSTS.plistet appuyez sur Entrée, cela supprimera le fichier de stockage HSTS.
Enfin, tapez exit, appuyez sur Entrée et fermez Terminal.

À ce stade, vous pouvez maintenant vous reconnecter au compte utilisateur concerné et la redirection HSTS incriminée devrait être définitivement supprimée.

Maintenant, bien que cela fournisse une solution de contournement utilisable, j'aimerais vraiment savoir pourquoi la suppression du fichier HSTS.plist de mon compte affecté n'a pas fonctionné; le fait qu'il soit recréé signifie qu'un processus d'arrière-plan en est responsable, ce qui signifie qu'il devrait être possible de supprimer le fichier du compte d'utilisateur affecté en arrêtant simplement ce processus, en supprimant le fichier, puis en relançant le processus.

Quelqu'un a-t-il des idées sur le processus responsable du ~/Library/Cookies/HSTS.plistfichier? Une fois que nous savons qu'il devrait être possible de donner une solution plus simple au problème.

— Haravikk
source

2

Voici une idée!

Vous dites que vous ne pouvez pas annuler la redirection en configurant le serveur pour rediriger les requêtes https vers http (car vous n'avez pas d'accès administrateur pour le faire).

Mais que faire si vous trompez Safari pour vous connecter à un autre serveur qui offre cette redirection inverse?

Vous pouvez configurer cela dans le /etc/hostsfichier de votre machine locale .

Par exemple, supposons que la redirection en cache actuelle soit de http://example.comà https://example.com.

Maintenant, configurez ou identifiez une URL que vous pouvez demander sur n'importe quel serveur dans le monde qui redirige de https vers http. Disons que le serveur a l'adresse de https://redirecting.example.com.

Recherchez ensuite l'adresse IP de redirecting.example.com. Dans Terminal, vous pouvez faire ceci:

host redirecting.example.com

Vous obtenez un résultat quelque chose comme ceci:

redirecting.example.com has address 69.69.69.69

Ouvrez maintenant votre fichier / etc / hosts et ajoutez une nouvelle ligne qui pointe les requêtes pour example.com à l'adresse IP de redirecting.example.com, comme ceci:

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

Enregistrez vos modifications et videz votre cache DNS dans le terminal comme ceci:

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

Ensuite, dans Safari, faites une demande de https://example.comréponse qui doit être une redirection vers http://example.comlaquelle, (doigts croisés) votre redirection Safari d'il y a 6 mois sera écrasée.

Une fois terminé, supprimez la ligne que vous avez ajoutée à votre fichier / etc / hosts et videz à nouveau votre cache DNS.

— Tout en un
source

Bien que ce soit une bonne idée, cela ne résout pas le vrai problème; Je ne cherche pas de solutions de contournement, mais je veux plutôt savoir où cette redirection est mise en cache de sorte que Safari continue de l'utiliser même si elle n'est plus valide (le serveur n'a pas activé HSTS, je l'ai simplement activé brièvement par erreur ). Il doit être stocké quelque part, mais je ne sais pas où.

— Haravikk

Ce n'est pas ce que j'appellerais une solution de contournement, car je pense que cela résoudra le problème réel . Cela ne fonctionne que par le fait que vous n'avez pas le contrôle de l'appareil. Mais je vous entends - ce serait bien de pouvoir effacer directement le paramètre mis en cache. Est-ce que Safari Technology Preview présente également le mauvais comportement?

— AllInOne

Malheureusement oui; Je ne pense pas que ce soit un problème avec Safari lui-même, mais plutôt un service macOS dont il dépend, car il semble en effet que ~/Library/Cookies/HSTS.plistc'était le coupable, mais le supprimer du compte affecté ne fonctionne pas (car il est recréé quelque temps plus tard, complet avec mauvaise redirection). Je ne sais pas quel processus le fait cependant.

— Haravikk

2

Après avoir essayé toutes ces solutions, ce qui a fonctionné pour moi a été:

Supprimer toutes les instances du domaine de l'historique de Safari
Quittez Safari
Supprimer ~/Library/Cookies/HSTS.plist
Redémarrer

— Edward Loveall
source

2

Mes deux cents pour le nouveau macOS Mojave 10.14 Beta (18A365a)

a) Vous ne pouvez pas vous arrêter définitivement nsurlstoraged, il se relance en 2 secondes, même si sudo

b) vous ne pouvez pas supprimer "HSTS.plist": si vous tapez:

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

vous obtenez: opération non autorisée

c) même si vous essayez:

ls -la ~/Library/Cookies/

vous obtenez: opération non autorisée

pareil pour

nano ~/Library/Cookies/HSTS.plist

(fichier vide..)

Vous ne pouvez donc pas y accéder définitivement . (peut-être SIP?)

d) étrangement, vous pouvez supprimer si du Finder:

CMD Shift G "~ / Bibliothèque / Cookies /"

entrez la description de l'image ici

et vous pouvez supprimer avec la souris:

e) plus étrange: vous pouvez passer au bureau à l'aide de la souris, le modifier et le replacer !

(un vrai non-sens, l'interface graphique est plus puissante que sudo ..)

— ingconti
source

2

Dans Safari, Firefox et Chrome également, il vous suffit d'ouvrir la barre latérale développeur , de sélectionner l'onglet réseau et de désactiver la mise en cache .

Dans Safari, c'est un tube barré, le bleu à côté du logo de la poubelle. Activez-le et l'ancienne redirection permanente doit être ignorée.

Le plus grand avantage est que vous n'avez pas à jouer avec les fichiers, vous ne supprimerez pas toutes les entrées HTST et perdrez les avantages de sécurité. Cela fonctionne également sur tous les navigateurs.

— luckydonald
source

Bien que cela soit très utile à savoir, pouvez-vous s'il vous plaît confirmer si cela fonctionne comme une solution permanente? c'est-à-dire que si le cache est réactivé, le problème réapparaîtra-t-il ou le désactiver temporairement le videra-t-il?

— Haravikk

1

@Haravikk dans mes tests, il ne reviendrait pas à utiliser la redirection permanente lorsqu'une nouvelle page pourrait être chargée à la place. Même après avoir fermé la fenêtre de développement, si cela répond à votre question

— luckydonald

1

Assurez-vous d'abord que le serveur n'envoie pas l'en -tête Strict-Transport-Security.
Vous pouvez le faire avec curl -I( -Iobtient simplement les en-têtes)

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

Si le serveur envoie l'en-tête Strict-Transport-Security, le supprimer de votre navigateur n'aura aucun effet, car la prochaine fois que vous accéderez au site, il sera à nouveau défini.

Supprimer votre site de la base de données Http Secure Transport Security de Safari

Fermer Safari
Modifier ~/Library/Cookies/HSTS.plist
Recherchez l'entrée du site auquel vous souhaitez accéder via http, supprimez-le et enregistrez le fichier.
- Je préfère modifier plutôt que supprimer car il n'est pas nécessaire de supprimer les entrées valides.
- Je modifie les fichiers plist en utilisant Xcode, mais s'il n'est pas installé, vous pouvez simplement utiliser un éditeur de texte.
Redémarrez votre ordinateur.
- Au lieu de redémarrer votre ordinateur, vous pouvez redémarrer nsurlstoragedmais cela peut être impliqué en raison de SIP, donc un redémarrage de l'ordinateur peut être plus simple. Voir la réponse de Grant et la réponse de Quanta au sujet de remise en marchensurlstoraged

— Jason S
source

1

J'ai fait un script à partir de la réponse de 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

Il termine normalement le safari, arrête nsurlstoraged, supprime le fichier HSTS.plist et redémarre nsurlstoraged. Cela a bien fonctionné pour moi ici sur macOS 10.13.5

— Martin Emrich
source

1

J'utilise Mojave (10.14). J'ai essayé les méthodes données jusqu'à présent pour supprimer HSTS.plist. De plus, j'avais besoin d'ajouter Terminal à la liste Préférences Système> Sécurité et confidentialité> Accès complet au disque pour remédier au symptôme "Opération non autorisée" lors de la liste du contenu de ~ / Library / Cookies /.

Mais, la suppression du fichier et le redémarrage du démon n'ont pas fonctionné. J'ai donc essayé d'ouvrir Safari à nouveau, je suis allé dans Préférences, Confidentialité, Gérer les données du site Web. Ensuite, j'ai supprimé tous les «cookies de cache, stockage local» pour le nom de domaine incriminé. Cela a résolu mon problème.

Je ne peux pas dire maintenant si la suppression de HSTS était nécessaire ou non.

— Bob Peterson
source

J'ai essayé la même chose et redémarré deux fois, mais l'utilisation de l'interface utilisateur de Safari a également fonctionné pour moi. Merci!

— Bart Verkoeijen

-1

Essayez ceci, puis passez à l'étape 1: allez dans le dossier ~ / Library, étape 2: supprimez le dossier Safari de ~ / Library / Application Support, étape 3: supprimez les dossiers ci-dessous de ~ / Library / Caches, étape 4: puis supprimez ~ / Bibliothèque / dossier Safari PS: Gardez safari fermé pendant les opérations ci-dessus

— Omi Harjani
source

1

Les réponses à Ask Different doivent être plus qu'un simple lien. Il est correct d'inclure un lien, mais veuillez le résumer ou l'extraire dans la réponse. L'idée est de rendre la réponse autonome.

— nohillside