Como liberar totalmente redirecionamentos em cache do Safari?

27

Eu tenho um dispositivo com um painel de controle baseado na Web e o defino acidentalmente para redirecionar todas as httppáginas https, mesmo que algumas não funcionem https. Embora eu tenha corrigido isso, o Safari parece ter memorizado o redirecionamento e está se recusando a esquecê-lo, tentando constantemente me redirecionar para o httpsendereço inválido .

Eu já fechei o Safari, limpei ~/Library/Caches/com.apple.Safari/e ~/Library/Cookies/HSTS.plistainda parece lembrar o redirecionamento quando o abro.

Onde mais o Safari poderia armazenar essas informações? Posso acessar a página correta via Firefox ou Chrome, portanto, pode não ser um serviço para todo o sistema ou, se não for o que os outros navegadores usam.

Infelizmente, como o painel da web é fornecido por um dispositivo, não acredito que possa ajustar os cabeçalhos ou configurar um redirecionamento de volta para o URL correto, que parecem ser opções oferecidas em outras perguntas semelhantes, então preciso descobrir onde isso os dados estão sendo armazenados para que eu possa destruí-los com fogo.

Haravikk
fonte
Você já tentou lixeira / afastar sua ~/Library/Safaripasta e ver se isso resolve o problema? Nesse caso, você pode experimentar itens dentro da pasta até encontrar o arquivo responsável.
interestinglythere
Como você definiu o redirecionamento? Com uma extensão ou existe uma configuração no Safari para isso?
owlswipe
O redirecionamento ainda acontece com uma janela de navegação privada?
AllInOne
@AllInOne ideia interessante, mas infelizmente ainda acontece na navegação privada.
Haravikk

Respostas:

29

Com base na resposta de quanta :

Não pude usar launchctl unload /System/Library/LaunchAgents/com.apple.nsurlstoraged.plistporque tenho o System Integrity Protection ativado:

$ 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

No entanto, fui capaz de contornar isso, fazendo o seguinte:

  • killall nsurlstoraged(interrompe o processo nsurlstoraged do usuário; na verdade sudo killall nsurlstoraged, eu executei , mas desconfio que não seja necessário interromper o nsurlstoraged do sistema também, pois o cache está na pasta Biblioteca do usuário)
  • rm -f ~/Library/Cookies/HSTS.plist (exclui o cache do HSTS)
  • launchctl start /System/Library/LaunchAgents/com.apple.nsurlstoraged.plist (reinicia nsurlstoraged)
Grant Heaslip
fonte
Não posso votar suficientemente nesta resposta. Parece que, pelo menos no Sierra, a simples remoção do HSTS.plistarquivo não corrigirá o problema, pois continuará sendo reconstruído. No entanto, depois de matar nsurlstoragede depois remover o arquivo HSTS, isso funcionou!
N
11
Muito obrigado, votado, mas eu fiz assim. 1. Feche o Safari 2. Edite ~/Library/Cookies/HSTS.pliste remova a entrada do site que eu quero no http 3. Reinicie o computador
Jason S
Sim, reiniciar é o conselho que todas as outras respostas dão a você, mas com 20 aplicativos abertos, é muito mais conveniente e rápido reiniciar o processo armazenado no nsurl. Obrigado @nvahalik!
axello
2
Atualização do Mojave: o comando rm -f ~/Library/Cookies/HSTS.plistretornará, a Operation not permittedmenos que você tenha concedido acesso total ao disco ao Terminal.app em Preferências do sistema => Segurança e privacidade => Privacidade. Caso contrário, a solução funcionou perfeitamente! Obrigado!
joehanna 4/03
@ nvahalik O que está acontecendo parece ainda mais estranho do que o arquivo sendo reconstruído; nem rm ~/Library/Cookies/HSTS.plist ; touch ~/Library/Cookies/HSTS.plist ; chmod guo-wrx ~/Library/Cookies/HSTS.plistme ajudou, mas ajudou killall nsurlstoraged.
Flash Sheridan
6

Se você ativar o menu Desenvolver nas preferências do Safari, poderá limpar o cache a partir daí (CMD + ALT + E).

Você pode confirmar se a abertura do painel de controle do dispositivo na janela Privada do Safari (ou em outro navegador da web) funciona corretamente?

Filip Jurik
fonte
Infelizmente, a opção do menu de desenvolvimento não parece limpar o redirecionamento, nem fechar o Safari e excluir manualmente, ~/Library/Caches/com.apple.Safariportanto o redirecionamento deve estar sendo armazenado em outro lugar. O HSTS foi o recurso que habilitei acidentalmente, mas já excluí ~/Library/Cookies/HSTS.plist.
Haravikk 17/02
11
Eu também posso confirmar esta resposta não corrigi-lo
malhal
Este trabalhou para mim
Matthew Cawley
5

Com base na resposta de @ Haravikk: /apple//a/267783/62907

Alguém tem alguma idéia de qual processo é responsável pelo arquivo ~ / Library / Cookies / HSTS.plist?

fs_usage pode ajudar:

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

Então nós podemos:

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

então:

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

e tente novamente.

quanta
fonte
Obrigado! Isso funcionou para mim. Eu apaguei o HSTS.plist várias vezes (fechando / reiniciando o Safari antes e depois) e ele estava sempre sendo recriado com exatamente o mesmo conteúdo de antes. Descarregar o nsurlstoraged primeiro, depois excluir o plist e reiniciar o nsurlstoraged me deu um plist limpo.
lucianf
2
Você pode melhorar isso mencionando que precisa sair e reiniciar o Safari para que ele funcione. Além disso, em vez de excluir o HSTS.plist, acabei de excluir a chave do domínio do problema.
malhal
3

Você terá bons resultados se usar a linha de comando curldo dispositivo para garantir que ele não esteja fazendo o redirecionamento. O Safari realmente não tem um mecanismo para reescrever endereços - especialmente se você fizer uma navegação privada para remover histórico, cookies, etc.

Se você não tiver certeza de que limpou o seu safari o suficiente, também pode testar abrindo as preferências do sistema e criando uma conta de usuário nova / limpa no Mac e testando o site em uma versão totalmente limpa do Safari depois de sair do seu usuário normal .

bmike
fonte
Definitivamente, não há redirecionamento (o recurso ao qual estou tentando conectar não suporta HTTPS, razão pela qual ativar o HSTS para todo o dispositivo foi um erro terrível, terrível); Posso conectar-me perfeitamente a partir de outras contas de usuário e navegadores, para que haja algo armazenado em algum lugar da minha conta principal que esteja armazenando em cache isso :(
Haravikk
“O Safari realmente não tem um mecanismo para reescrever endereços” - atualmente, tenho o mesmo problema no Safari com um site hospedado no meu laptop e ondulação (junto com o Firefox, Chrome e uma janela de Navegação Privada) Safari) na mesma conta de usuário carrega o site muito bem. Portanto, deve haver algo a ver com o próprio Safari.
Paul D. Waite
3

Portanto, encontrei uma solução alternativa para o problema, embora essa não seja uma resposta definitiva para a pergunta real, portanto não a marcarei como tal até encontrar mais informações.

Acontece que o arquivo ~/Library/Cookies/HSTS.plistera realmente a fonte do problema, como eu suspeitava, mas excluí-lo da conta de usuário afetada não funciona, mesmo com o Safari fechado, pois é recriado após um período desconhecido, completo com a ofensa entrada que estava forçando o redirecionamento inválido.

Então, minha solução foi a seguinte:

  1. Verifique se você possui pelo menos uma outra conta de usuário no seu Mac (caso contrário, crie uma).
  2. Logout da conta de usuário afetada.
  3. Faça login em uma conta de usuário diferente (uma conta de convidado pode não ser suficiente, dependendo das restrições).
  4. Descubra o nome abreviado da sua conta de usuário afetada; se você não souber, a melhor maneira de verificar é procurar em Preferências do Sistema -> Usuários. Normalmente, se for o nome completo, com letras minúsculas e sem espaços, por isso, se o nome completo for "John Smith", o nome abreviado poderá ser "johnsmith".
  5. Abra uma janela no Terminal, digite su shortnamesubstituindo "shortname" pelo nome abreviado da conta de usuário afetada. Pressione Enter e, quando solicitado, digite a senha da conta afetada.
  6. Agora digite o próximo comando rm ~/Library/Cookies/HSTS.pliste pressione Enter, isso excluirá o arquivo de armazenamento HSTS.
  7. Por fim exit, digite Enter e feche o Terminal.

Nesse ponto, agora você pode fazer login novamente na conta de usuário afetada e o redirecionamento HSTS ofensivo deve ter desaparecido definitivamente.

Agora, embora isso ofereça uma solução utilizável, eu realmente gostaria de saber por que a exclusão do arquivo HSTS.plist da minha conta afetada não funcionou; o fato de ser recriado significa que algum processo em segundo plano é responsável por isso, o que significa que deve ser possível excluir o arquivo da conta de usuário afetada simplesmente parando esse processo, excluindo o arquivo e reiniciando o processo.

Alguém tem alguma idéia de qual processo é responsável pelo ~/Library/Cookies/HSTS.plistarquivo? Uma vez que sabemos que deve ser possível dar uma correção mais simples ao problema.

Haravikk
fonte
2

Aqui está uma ideia!

Você diz que não pode desfazer o redirecionamento configurando o servidor para redirecionar solicitações https novamente para http (pois você não tem acesso de administrador para fazer isso).

Mas e se você enganar o safari para conectar-se a um servidor diferente que ofereça esse redirecionamento reverso?

Você pode configurá-lo no /etc/hostsarquivo da sua máquina local .

Por exemplo, digamos que o redirecionamento em cache atual seja de http://example.compara https://example.com.

Agora configure ou identifique um URL que você pode solicitar em qualquer servidor no mundo que redirecione de https para http. Digamos que o servidor tenha o endereço de https://redirecting.example.com.

Em seguida, procure o endereço IP de redirecting.example.com. No Terminal, você pode fazer assim:

host redirecting.example.com

Você obtém um resultado mais ou menos assim:

redirecting.example.com has address 69.69.69.69

Agora abra seu arquivo / etc / hosts e adicione uma nova linha que aponte solicitações para example.com para o endereço IP de redirecionamento.exemplo.com, da seguinte maneira:

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

Salve as alterações e limpe o cache do DNS no terminal da seguinte maneira:

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

Em seguida, no Safari, faça um pedido para que https://example.coma resposta seja redirecionada de volta para http://example.com, momento em que (o dedo cruzado), seu redirecionamento do Safari de 6 meses atrás será substituído.

Quando terminar, remova a linha que você adicionou ao seu arquivo / etc / hosts e limpe seu cache DNS novamente.

Tudo em um
fonte
Embora seja uma boa idéia, não resolve o problema real; Não estou procurando soluções alternativas, mas quero saber onde esse redirecionamento está sendo armazenado em cache, para que o Safari continue a usá-lo mesmo que não seja mais válido (o servidor não tem o HSTS ativado, eu simplesmente o habilitei brevemente por engano ) Ele deve ser armazenado em algum lugar, mas não consigo descobrir onde.
Haravikk
Não é isso que eu chamaria de solução alternativa, pois espero que resolva o problema real . Isso apenas contorna o fato de você não ter controle do dispositivo. Mas eu ouvi você - seria bom poder limpar a configuração em cache diretamente. O Safari Technology Preview também exibe o mau comportamento?
AllInOne
Infelizmente sim; Eu não acho que seja um problema com o próprio Safari como tal, mas com alguns serviços do macOS dos quais ele depende, pois de fato parece que ~/Library/Cookies/HSTS.plistfoi o culpado, mas excluí-lo da conta afetada não funciona (pois é recriado algum tempo depois, completo com redirecionamento incorreto). Não tenho certeza de qual processo está fazendo isso.
Haravikk
2

Depois de tentar todas essas soluções, o que funcionou para mim foi:

  • Remova todas as instâncias do domínio do histórico do Safari
  • Sair do Safari
  • Excluir ~/Library/Cookies/HSTS.plist
  • Reiniciar
Edward Loveall
fonte
2

Meus dois centavos para o novo macOS Mojave 10.14 Beta (18A365a)

a) Você não pode parar definitivamente nsurlstoraged, ele é reiniciado em 2 segundos, mesmo que o sudo

b) você não pode excluir "HSTS.plist": se você digitar:

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

você recebe: Operação não permitida

c) mesmo se você tentar:

ls -la ~/Library/Cookies/

você recebe: Operação não permitida

o mesmo para

nano ~/Library/Cookies/HSTS.plist 

(Arquivo vazio..)

Então você não pode acessá- lo definitivamente . (talvez SIP?)

d) estranhamente você pode excluir se do Finder:

CMD Shift G "~ / Biblioteca / Cookies /"

insira a descrição da imagem aqui

e você pode excluir com o mouse:

insira a descrição da imagem aqui

e) mais estranho: você pode ir para a área de trabalho usando o mouse, editar e recolocá-lo !

(um verdadeiro absurdo, a GUI é mais poderosa que o sudo ..)

ingconti
fonte
2

No Safari, Firefox e Chrome também, tudo o que você precisa fazer é abrir a barra lateral do desenvolvedor , selecionar a guia rede e desativar o cache .

No Safari, é uma coisa de tubo riscado, o azul ao lado do logotipo da lixeira. Ative isso e o redirecionamento permanente antigo deve ser ignorado. Desativação do Safari chaching 503 redirecionamentos permanentes

O maior benefício é que você não precisa mexer nos arquivos, não excluirá todas as entradas HTST e perderá os benefícios de segurança. Também funciona em navegadores.

luckydonald
fonte
Embora isso seja muito útil, você pode confirmar se funciona como uma solução permanente? ou seja, se o cache for reativado, o problema ressurgirá ou a desativação temporária dele será liberada?
Haravikk
11
@ Haravikk nos meus testes, não voltaria a usar o redirecionamento permanente quando uma nova página pudesse ser carregada. Mesmo depois de fechar a janela de desenvolvimento, se isso responder à sua pergunta
luckydonald
1

Primeiro, verifique se o servidor não está enviando o cabeçalho Strict-Transport-Security
Você pode fazer isso com curl -I( -Iapenas obtém os cabeçalhos)

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

Se o servidor estiver enviando o cabeçalho Strict-Transport-Security, removê-lo do navegador não terá efeito, pois na próxima vez que você acessar o site, ele será definido novamente.

Remova seu site do banco de dados Http Secure Transport Security do Safari

  1. Fechar o Safari
  2. Editar ~/Library/Cookies/HSTS.plist
    Pesquise a entrada do site que você deseja acessar via http, remova-a e salve o arquivo.
    • Prefiro editar em vez de remover, pois não há necessidade de remover entradas válidas.
    • Eu edito arquivos plist usando o Xcode, mas se não estiver instalado, você pode simplesmente usar um editor de texto.
  3. Reinicie o seu computador.
    • Em vez de reiniciar o computador, você pode reiniciar, nsurlstoragedmas isso pode estar envolvido devido ao SIP, portanto, a reinicialização do computador pode ser mais simples. Veja a resposta de Grant e resposta da Quanta sobre reinícionsurlstoraged
Jason S
fonte
1

Eu escrevi um roteiro com a resposta 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

Ele finaliza normalmente o safari, para nsurlstoraged, remove o HSTS.plist e inicia o nsurlstoraged novamente. Isso funcionou bem para mim aqui no macOS 10.13.5

Martin Emrich
fonte
1

Estou usando o Mojave (10.14). Eu tentei os métodos fornecidos até agora para remover o HSTS.plist. Além disso, eu precisava adicionar o Terminal à lista Preferências do sistema> Segurança e privacidade> Acesso total ao disco para curar o sintoma "Operação não permitida" ao listar o conteúdo de ~ / Library / Cookies /.

Porém, remover o arquivo e reiniciar o daemon não funcionou. Então, tentei abrir o Safari novamente, fui para Preferências, Privacidade, Gerenciar dados do site. Em seguida, removi todos os "cookies de cache, armazenamento local" do nome de domínio incorreto. Isso resolveu meu problema.

Não posso dizer agora se a remoção do HSTS foi necessária ou não.

Bob Peterson
fonte
Tentei o mesmo e reinicializei duas vezes, mas apenas a interface do Safari funcionou para mim também. Obrigado!
Bart Verkoeijen
-1

Tente isso, vá para a Etapa 1: Vá para a pasta ~ / Library, Etapa 2: Exclua a pasta Safari de ~ / Library / Application Support, Etapa 3: Exclua as pastas abaixo de ~ / Library / Caches, Etapa 4: depois exclua ~ / Pasta Library / Safari PS: mantenha o safari fechado durante as operações acima

Omi Harjani
fonte
11
As respostas no Ask Different precisam ser mais do que apenas um link. Não há problema em incluir um link, mas faça um resumo ou trecho da resposta. A idéia é tornar a resposta independente.
Nohillside