¿Cómo puedo eliminar completamente los redirects almacenados en caching de Safari?

Tengo un dispositivo con un panel de control basado en la web y lo configuré accidentalmente para networkingirigir todas las páginas http a https , aunque algunas no funcionan en https . Aunque desde entonces he corregido esto, Safari parece haber memorizado el redirect y se niega a olvidarlo, en su lugar, constantemente intenta networkingirigirme a la dirección https no válida.

Ya cerré Safari, ~/Library/Caches/com.apple.Safari/ y ~/Library/Cookies/HSTS.plist pero aún parece estar recordando el redirect cuando lo vuelvo a abrir.

¿Dónde más podría save Safari esta información? Puedo acceder a la página correcta a través de Firefox o Chrome, por lo que puede que no sea un service de todo el sistema, o si es que no es uno que usan otros browseres.

Lamentablemente, dado que el panel web lo proporciona un dispositivo, no creo que pueda ajustar los encabezados o configurar un redirect de return a la URL correcta, que parecen ser opciones ofrecidas en otras preguntas similares, así que realmente necesito saber dónde está esto. los datos se almacenan para poder destruirlos con fuego.

  • ¿Cómo puedo hipervincular 'text' dentro de una nota en la aplicación macOS Notes?
  • ¿Hay alguna manera de hacer que Mavericks monte las URL de AFP de la manera antigua, montando el punto compartido, y no la carpeta adjunta?
  • Haz que las URL en files de text plano se conviertan en enlaces
  • Cambie automáticamente la fuente de input al inglés al ingresar a Spotlight, escribir URL en Safari, etc.
  • Usando Javascript | Applescript para hacer clic en el button en Safari
  • Reemplazar variables específicas en text seleccionado mediante script
  • ¿Hay alguna manera de bloquear ciertos sitios, por ejemplo, MacKeeper?
  • itms-service no viene como hyperlink en el correo electrónico
  • 8 Solutions collect form web for “¿Cómo puedo eliminar completamente los redirects almacenados en caching de Safari?”

    Basado en la respuesta de quanta :

    No pude usar launchctl unload /System/Library/LaunchAgents/com.apple.nsurlstoraged.plist porque tengo habilitada la Protección de Integridad del Sistema :

     $ 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 

    Sin embargo, pude solucionarlo haciendo lo siguiente:

    • killall nsurlstoraged (detiene el process nsurlstoraged de tu usuario; en realidad ejecuté sus sudo killall nsurlstoraged , pero sospecho que no es necesario detener también el nsurlstoraged del sistema, ya que el caching está en la carpeta Library del usuario)
    • rm -f ~/Library/Cookies/HSTS.plist (elimina el caching HSTS)
    • launchctl start /System/Library/LaunchAgents/com.apple.nsurlstoraged.plist (reinicia nsurlstoraged)

    Si habilita el menu Desarrollar en las preferences de Safari, puede borrar el caching desde allí (CMD + ALT + E).

    ¿Puedes confirmar que la apertura del panel de control del dispositivo en la window privada de Safari (o en otro browser web) funciona correctamente?

    Tendrás buenos resultados si usas la línea de command para curl el dispositivo y asegurarte de que no está haciendo la networkingirección. Safari en realidad no tiene un motor para reescribir las direcciones, especialmente si va a la navigation privada para eliminar el historial, las cookies, etc.

    Si no está seguro de haber limpiado su safari lo suficiente, también puede probar abriendo las preferences del sistema y creando una nueva count de usuario limpia en la Mac y probando el sitio en una versión totalmente limpia de Safari después de desconectarse de su usuario normal. .

    Así que encontré una solución al problema, aunque esta no es una respuesta definitiva a la pregunta real, así que no la marcaré como tal hasta que pueda encontrar más información.

    Resulta que el file ~/Library/Cookies/HSTS.plist fue de hecho el origen del problema como sospechaba, sin embargo, eliminarlo de la count de usuario afectada no funciona, incluso con Safari cerrado, ya que se recrea después de un cantidad desconocida de time, completa con la input ofensiva que estaba forzando la networkingirección no válida.

    Entonces mi solución fue la siguiente:

    1. Asegúrese de tener al less otra count de usuario en su Mac (si no, cree una).
    2. Salir de la count de usuario afectada.
    3. Inicie session en una count de usuario diferente (una count de invitado puede no ser suficiente, dependiendo de las restricciones).
    4. Descubra el nombre corto de su count de usuario afectada; si no sabe, la mejor manera de verificarlo es search en Preferences del Sistema -> Usuarios. Por lo general, si será el nombre completo, con mayúsculas y sin espacios, de modo que si su nombre completo es "John Smith", entonces el nombre abreviado puede ser "johnsmith".
    5. Abra una window en Terminal, escriba su shortname reemplazando "shortname" con el nombre corto de la count de usuario afectada. Haga clic en Entrar y, cuando se le solicite, ingrese la contraseña de la count afectada.
    6. Ahora escriba el siguiente command rm ~/Library/Cookies/HSTS.plist y rm ~/Library/Cookies/HSTS.plist enter, esto eliminará el file de almacenamiento HSTS.
    7. Finalmente escriba exit , presione enter y cierre Terminal.

    En este punto, ahora puede volver a iniciar session en la count de usuario afectada y el redirect HSTS ofensivo debería desaparecer definitivamente.

    Ahora, aunque esto proporciona una solución utilizable, realmente me gustaría saber por qué no funcionaba eliminar el file HSTS.plist de mi count afectada; el hecho de que se vuelva a crear significa que hay un process en segundo plano responsable de ello, lo que significa que debería ser posible eliminar el file de la count de usuario afectada simplemente deteniendo ese process, eliminando el file y luego reiniciando el process.

    ¿Alguien tiene alguna idea de qué process es responsable del file ~/Library/Cookies/HSTS.plist ? Una vez que sabemos que debería ser posible dar una solución más simple al problema.

    Basado en la respuesta de @ Haravikk: https://apple.stackexchange.com/a/267783/62907

    ¿Alguien tiene alguna idea de qué process es responsable del file ~ / Library / Cookies / HSTS.plist?

    fs_usage puede ayudar:

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

    Para que podamos:

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

    entonces:

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

    e intenta de nuevo.

    ¡Aquí hay una idea!

    Usted dice que no puede deshacer la networkingirección configurando el server para networkingirigir las requestes https a http (ya que no tiene acceso de administrador para hacerlo).

    Pero, ¿y si engañas a safari para que se conecte a un server diferente que ofrezca este redirect inverso?

    Puede configurarlo en el /etc/hosts su máquina local.

    Por ejemplo, digamos que el redirect actual en caching es de http://example.com a https://example.com .

    Ahora configure o identifique una url que puede solicitar en cualquier server del mundo que networkingirija de https a http. Digamos que el server tiene la dirección de https://networkingirecting.example.com .

    Luego busque la dirección IP de networkingirecting.example.com . En Terminal puedes hacer esto:

     host networkingirecting.example.com 

    Obtienes un resultado como este:

     networkingirecting.example.com has address 69.69.69.69 

    Ahora abra su file / etc / hosts y agregue una nueva línea que apunte las requestes de example.com en la dirección IP de networkingirecting.example.com, de esta manera:

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

    Guarde sus cambios y borre su caching de DNS en la terminal de la siguiente manera:

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

    Luego, en Safari, realice una request para https://example.com la respuesta debería ser un redirect a http://example.com , en cuyo punto (dedos cruzados) se sobrescribirá su redirect de Safari de hace 6 meses.

    Cuando termine, elimine la línea que agregó a su file / etc / hosts y vacíe su caching DNS nuevamente.

    Después de probar todas estas soluciones, lo que funcionó para mí fue:

    • Eliminar todas las instancias del dominio de la historia de Safari
    • Salir de Safari
    • Eliminar ~/Library/Cookies/HSTS.plist
    • Reiniciar

    Pruebe esto, vaya al Paso 1: vaya a la carpeta ~ / Library, Paso 2: elimine la carpeta Safari de ~ / Library / Application Support, Paso 3: elimine las carpetas siguientes de ~ / Library / Caches, Step 4: luego Delete ~ / Carpeta de la biblioteca / Safari PD: Mantener el safari cerrado durante las operaciones anteriores

    Loving Apple Products like poisoning (iPhone, iPad, iMac, Macbook, iWatch).