Js очистить кэш браузера
Обновлено: 04.07.2024
Я ищу способ программно очистить кэш браузера. Я делаю это, потому что приложение кэширует конфиденциальные данные, и я хотел бы удалить их, когда вы нажимаете "выйти". Это произойдет либо через сервер, либо через JavaScript. Конечно, использование программного обеспечения на внешнем/общедоступном компьютере по-прежнему не рекомендуется, поскольку есть больше опасностей, таких как регистраторы ключей, которые вы просто не можете победить на программном уровне.
возможно, вы можете просто использовать jQuery для замены "мета-тега", который ссылается на состояние кэша с помощью обработчика событий / кнопки, а затем обновить, легко,
Примечание: это решение опирается на кэш приложений, реализованный как часть спецификации HTML 5. Он также требует настройки сервера для настройки манифеста кэша приложения. Он не описывает метод, с помощью которого можно очистить "традиционный" кэш браузера с помощью клиентского или серверного кода, который является почти невозможно сделать.
здесь не так браузер позволит вам очистить свой кэш. Это было бы огромной проблемой безопасности, если бы это было возможно. Это может быть очень легко злоупотреблять-в ту минуту, когда браузер поддерживает такую "функцию", я удалю ее с моего компьютера.
что ты можете do-это сказать ему, чтобы он не кэшировал вашу страницу, отправив соответствующие заголовки или используя эти мета-теги:
вы также можете рассмотреть возможность отключения автоматическое заполнение полей формы, хотя я боюсь, что есть стандартный способ сделать это (посмотреть здесь).
несмотря на это, я хотел бы отметить, что если вы работаете с конфиденциальными данными, вы должны использовать SSL. Если вы не используете SSL, любой человек с доступом к сети может нюхать сетевой трафик и легко видеть, что видит ваш пользователь.
использование SSL также делает некоторые браузеры не используйте кэширование, если явно не указано. Видеть этот вопрос.
использовать сам html.Есть один трюк, который можно использовать.Хитрость заключается в том, чтобы добавить параметр / строку к имени файла в теге сценария и изменить его при изменении файла.
<script src="https://codengineering.ru/q/myfile.js?version=1.0.0"></script>
браузер интерпретирует всю строку как путь к файлу, хотя что происходит после "?- это параметры. Так что теперь происходит то, что в следующий раз, когда вы обновляете свой файл, просто измените номер в теге скрипта на своем веб-сайте (пример <script src="https://codengineering.ru/q/myfile.js?version=1.0.1"></script> ) и каждый браузер пользователи смотрите файл изменился и возьмите новую копию.
лучшая идея - сделать генерацию JS-файлов с именем + некоторый хэш с версией, если вам нужно очистить кэш, просто создайте новые файлы с новым хэшем, это вызовет браузер для загрузки новых файлов
на Chrome, вы должны быть в состоянии сделать это с помощью расширения бенчмаркинга. Вам нужно запустить chrome со следующими переключателями:
в консоли Chrome теперь вы можете сделать следующее:
Как вы можете сказать из команд выше, он не только очищает кэш браузера, но и очищает кэш DNS и закрывает сетевые подключения. Они отлично подходят, когда вы делаете бенчмаркинг времени загрузки страницы. Очевидно, вы не должны использовать их все, если не необходимо (например, clearCache () должно быть достаточно, если вам нужно очистить только кэш и не заботиться о кэше DNS и подключениях).
расположение.перезагрузка (true); будет трудно перезагрузить текущую страницу, игнорируя кэш.
кэш.удалить() может также использоваться для новых chrome, firefox и opera.
I am looking for a way to programmatically empty the browser cache. I am doing this because the application caches confidential data and I'd like to remove those when you press "log out". This would happen either via server or JavaScript. Of course, using the software on foreign/public computer is still discouraged as there are more dangers like key loggers that you just can't defeat on software level.
91k 118 118 gold badges 336 336 silver badges 499 499 bronze badges Which browsers? You should also look at telling the browser what not to cache from the server vs. trying to erase it. @MechSoftware I want to cache for faster page loads, but I want to clear it after log off. Preferably as good browser support as possible. @rFactor Nobody would use a browser that gives websites control over its cache.12 Answers 12
There's no way a browser will let you clear its cache. It would be a huge security issue if that were possible. This could be very easily abused - the minute a browser supports such a "feature" will be the minute I uninstall it from my computer.
What you can do is to tell it not to cache your page, by sending the appropriate headers or using these meta tags:
You might also want to consider turning off auto-complete on form fields, although I'm afraid there's a standard way to do it (see this question).
Regardless, I would like to point out that if you are working with sensitive data you should be using SSL. If you aren't using SSL, anyone with access to the network can sniff network traffic and easily see what your user is seeing.
Using SSL also makes some browsers not use caching unless explicitly told to. See this question.
79.7k 25 25 gold badges 202 202 silver badges 228 228 bronze badges Why would I clear the cache of my web app to annoy my users? I want to do that to clear traces of cached private data. If I tell the browser not to cache, it has to request megabytes of client-side data every time the page loads, which is neither want I want to do. Please explain how no matter the implementation, this would be a security issue? This could be implemented safely.It's possible, you can simply use jQuery to substitute the 'meta tag' that references the cache status with an event handler / button, and then refresh, easy,
NOTE: This solution relies on the Application Cache that is implemented as part of the HTML 5 spec. It also requires server configuration to set up the App Cache manifest. It does not describe a method by which one can clear the 'traditional' browser cache via client- or server-side code, which is nigh impossible to do.
This method seems to bypass the cache and update the content, but when the page is reloaded, it goes back to the previously cached content.use html itself.There is one trick that can be used.The trick is to append a parameter/string to the file name in the script tag and change it when you file changes.
The browser interprets the whole string as the file path even though what comes after the "?" are parameters. So wat happens now is that next time when you update your file just change the number in the script tag on your website (Example <script src="https://stackoverflow.com/questions/8155064/myfile.js?version=1.0.1"></script> ) and each users browser will see the file has changed and grab a new copy.
I was using this technique for many days. But I noticed today that, the file is still being rendered from cache even after I changed the version part. I was using Chrome. It was showing even after I deleted the file from the server. Anyone have any info why it may not work?The best idea is to make js file generation with name + some hash with version, if you do need to clear cache, just generate new files with new hash, this will trigger browser to load new files
Initially I tried various programmatic approach in my html, JS to clear browser cache. Nothing works on latest Chrome.
Finally, I ended up with .htaccess:
Tested in Chrome, Firefox, Opera
On Chrome, you should be able to do this using the benchmarking extension. You need to start your chrome with the following switches:
In Chrome's console now you can do the following:
As you can tell from above commands, it not only clears the browser cache, but also clears the DNS cache and closes network connections. These are great when you're doing page load time benchmarking. Obviously you don't have to use them all if not needed (e.g. clearCache() should suffice if you need to clear the cache only and don't care about DNS cache and connections).
Here is a single-liner of how you can delete ALL browser network cache using Cache.delete()
Works on Chrome 40+, Firefox 39+, Opera 27+ and Edge.
location.reload(true); will hard reload the current page, ignoring the cache.
Cache.delete() can also be used for new chrome, firefox and opera.
Works on Chrome 40+, Firefox 39+, Opera 27+ and Edge.
While appreciated, this does not clear the browser cache, it seems to cache-bust any links on the given page just by adding params.Imagine the .js files are placed in /my-site/some/path/ui/js/myfile.js
So normally the script tag would look like:
Now change that to:
Now of course that will not work. To make it work you need to add one or a few lines to your .htaccess The important line is: (entire .htaccess at the bottom)
So what this does is, it kind of removes the 1111111111 from the path and links to the correct path.
So now if you make changes you just have to change the number 1111111111 to whatever number you want. And however you include your files you can set that number via a timestamp when the js-file has last been modified. So cache will work normally if the number does not change. If it changes it will serve the new file (YES ALWAYS) because the browser get's a complete new URL and just believes that file is so new he must go get it.
You can use this for CSS , favicons and what ever gets cached. For CSS just use like so
Мы развернули последний код JavaScript, но мы не можем получить последний код JavaScript.
От редакции. Этот вопрос частично дублируется в следующих местах, и ответ на первый из следующих вопросов, вероятно, является лучшим. Этот принятый ответ больше не является идеальным решением.
Это смущает меня: «Мы развернули последний код JavaScript, но мы не смогли получить последний код JavaScript» Я предполагаю, что вы имеете в виду, как заставить клиентские браузеры использовать вашу последнюю версию javascript, а не их кэшированную версию - в этом случае вам нужен ответ Грега. Если вы хотите знать, как это сделать в своем браузере, это ответ Дэвида Джонстона. Обычный подход заключается в том, чтобы прикрепить ?version=xxx файлы к связанным JS-файлам на этапе сборки. Каждая новая сборка будет запрашивать новую версию файла JS. @JuanMendes Это не всегда работает. Этот же шаг предлагается, когда люди сталкиваются с проблемами, пытаясь увидеть последний значок. Это просто не гарантировано работать.Вы можете вызвать window.location.reload (true), чтобы перезагрузить текущую страницу. Он будет игнорировать любые кэшированные элементы и получать новые копии страницы, CSS, изображений, JavaScript и т. Д. С сервера. Это не очищает весь кеш, но имеет эффект очистки кеша для страницы, на которой вы находитесь.
Однако вашей лучшей стратегией является создание версии пути или имени файла, как указано в различных других ответах. Кроме того, см. Revving Filenames: не используйте строку запроса по причинам, которые не следует использовать в ?v=n качестве схемы управления версиями.
Вау, спасибо! Это хорошо работает и для кеша приложений HTML5, загруженного из файла cache.manifest. У меня был старый манифест, который не удалялся из памяти, поэтому один браузер, в котором он был кэширован, просто не отображал новые файлы. Я набрал это в консоли javascript и работал нормально. Спасибо! но с изменением имени файла . разве вы не сохраните все предыдущие версии на месте? в противном случае вы получите много неудачных попыток от поисковых систем и что не читать старые версии (или закладки / связанные изображения) Это то же самое, что пользователь нажимает кнопку обновления? @Manuel Отключит доступ к странице только из кеша того URL, который вы назвали location.reload (true). Он никогда не удаляет исходную страницу из кэша, так как он просто добавляет метку времени к новому запросу, и если на этой странице выполняются другие вызовы, выполняемые асинхронно, эти запросы НЕ будут отключены. Например. Если вы обновите страницу с помощью reload (true), которая загружает некоторый html, и на этой странице есть скрипт, который выполняет второй вызов ajax для отображения большего количества html на той же странице, во втором запросе не будет отключено кэширование.Вы не можете очистить кеш с помощью JavaScript. Распространенным способом является добавление номера редакции или последней обновленной метки времени в файл, например так:
Однако обратите внимание, что многие прокси не будут кэшировать файл, когда у него есть строка запроса Смотрите ответ Кевина Хакансона . Как я могу очистить кеш, когда весь HTML был кэширован? Это не повлияет, даже если номер версии добавлен из-за кэшированного HTML. Помогите Если я не могу очистить элемент кэша, то почему MDN говорит, что я могу? Чего мне не хватает? Я попробовал то, что говорит MDN, но не повезло.Попробуйте изменить src файла JavaScript? Из этого:
Этот метод должен заставить ваш браузер загрузить новую копию файла JS.
это ничего не делает, кроме как быть чем-то другим. это может быть? 12345 или? Кайл Значит, имя файла тоже нужно менять? Или просто путь src, который нужно изменить?Помимо кэширования каждый час или каждую неделю, вы можете кэшировать в соответствии с данными файла.
или даже использовать время модификации файла:
Могу ли я проверить, правильно ли я понимаю? С опцией 1 при изменении файла изменяется хэш контрольной суммы md5, который затем изменяет URL-адрес. Браузер видит новый URL и запускает новую загрузку файла. Полученные данные, добавленные к URL, игнорируются сервером. Если это так, чертовски приятно. Кроме того, интенсивно ли использует MD5 весь файловый процессор? Я подумываю о том, чтобы сделать это для файлов css и js навсегда, но я не хотел бы видеть снижение скорости сервера из-за этого. Использование контрольной суммы - хорошая идея, но это должно быть сделано правильно. Вычисляя его, каждый запрос для каждого файла значительно снизит вашу производительность. Querystring не подходит для кеширования, смотрите другие ответы. Правильное использование - добавить контрольную сумму (часть?) Или номер версии к имени файла и использовать вместо этого это новое имя (вы можете использовать скрипт сборки, чтобы сделать это автоматически при развертывании). Смотри ворчание , рев и усмин .Вы также можете принудительно перезагружать код каждый час, например, в PHP:
@GMsoF - это просто дополнительный параметр get, который используется (в данном случае), чтобы сообщить браузеру, что это «другой» файл. Так что браузер откажется от кэшированной версии и загрузит эту. Это часто используется с «последней датой изменения» файла. Я надеюсь, что это имеет смысл ;-)поместите это в конце вашего шаблона:
пожалуйста, предоставьте некоторые объяснения вашего решения @GabrielEspinoza он перезагружает файлы с помощью javascript, что позволяет обновлять кэши.попробуйте использовать это
Вот фрагмент того, что я использую для своего последнего проекта.
Наш процесс публикации генерирует файл с номером ревизии текущей сборки. Это работает с помощью URL, кодирующего этот файл и использующего его в качестве кеша. В случае отработки отказа, если этот файл не существует, используются год и номер недели, чтобы кэширование продолжало работать, и оно будет обновляться не реже одного раза в неделю.
Кроме того, это обеспечивает очистку кеша при каждой загрузке страницы в среде разработки, поэтому разработчикам не нужно беспокоиться об очистке кеша для любых ресурсов (вызовов javascript, css, ajax и т. Д.).
или вы можете просто прочитать js файл сервером с помощью file_get_contets, а затем добавить в заголовок echo содержимое js
Возможно, «очистка кеша» не так проста, как должна быть. Вместо очистки кеша в моих браузерах я понял, что «касание» файла фактически изменит дату кеширования исходного файла на сервере (проверено на Edge, Chrome и Firefox), и большинство браузеров автоматически загрузят самую свежую свежую копию что на вашем сервере (код, графика и любые мультимедиа тоже). Я предлагаю вам просто скопировать самые последние сценарии на сервере и решить проблему "сделать что-то на ощупь" перед запуском вашей программы, поэтому она изменит дату всех ваших проблемных файлов на самую последнюю дату и время, а затем загрузит свежую копию в ваш браузер:
. остальная часть вашей программы .
Мне потребовалось некоторое время, чтобы решить эту проблему (поскольку многие браузеры по-разному работают с разными командами, но все они проверяют время файлов и сравнивают их с загруженной в браузере копией, если обновление даты и времени выполнят обновление), если вы не может идти по правильному пути, всегда есть другое полезное и лучшее решение. С наилучшими пожеланиями и счастливого кемпинга.
Мне нравится этот подход, но, возможно, я реализую это в неправильной области? Кто-нибудь знает, где добавить это в настройке WordPress? Я добавил его в файл functions.php с прямыми ссылками на файлы JavaScript и CSS, но мне все равно пришлось сделать перезагрузку, чтобы заметить изменения. То, что вам нужно сделать, находится в вашем главном html-каталоге WordPress, отредактируйте ваш index.php для вызова или выполните команду Touch () для файлов, которые вам нужно обновить и загрузить. У меня были проблемы с небольшими фото и js-файлами, которые застряли в кеше. Я пробовал большинство методов, описанных для освобождения из памяти, но лучший способ - загрузить текущий свежий правильный. Вы можете сделать это, просто выполнив «Touch Thing», так как он ничего не изменяет в файле, просто обновляет текущее время и дату, поэтому обманывает ваш браузер, думая, что его другая версия файла и проблема исправлены. Работает в большинстве браузеровУ меня были некоторые проблемы с кодом, предложенным yboussard. Внутренняя J-петля не работает. Вот модифицированный код, который я использую с успехом.
Статья состоит из двух частей: теоретической и практической.
В теоретической части мы кратко рассмотрим карту импортов и более подробно Clear-Site-Data .
В практической части мы поднимем два сервера — один будет запускаться локально и, помимо прочего, обслуживать статические файлы нашего приложения, другой мы развернем на Heroku . Сначала мы запросим данные (включая куки) от серверов, сохраним эти данные в браузере с помощью трех наиболее популярных механизмов (локальное хранилище, индексированная база данных и интерфейс кеширования), затем попробуем очистить их с помощью заголовков Clear-Site-Data . Для разрешения путей импортируемых в приложении модулей мы будем использовать карту импортов.
Исходный код проекта находится здесь.
Ресурсы
О механизмах для хранения данных на стороне клиента, которые мы будем использовать в приложении, я рассказывать не буду. Вот ссылки на отличные ресурсы, посвященные каждому из них:
Инструменты
При разработке приложения мы будем использовать несколько инструментов, основными из которых являются следующие:
Теория
Карта импортов
Карта импортов (imports map) позволяет использовать так называемые голые спецификаторы импорта (bare import specifiers) в инструкциях import и выражениях import() без участия сборщиков типа Webpack или других инструментов для разрешения путей импортируемых модулей во время выполнения кода.
Предположим, что в нашем проекте используются библиотека lodash и утилита very-simple-fetch :
Для того, чтобы импортировать эти модули без помощи "бандлера", необходимо указать полный путь к соответствующим файлам, хранящимся в директории node_modules :
Карта импортов позволяет связать кастомные ключи — названия модулей — с их расположением. Для этого в теге <script> с типом importmap определяется объект с ключом imports и парами ключ / значение, где значение — это путь к модулю, а ключ — синоним (алиас) для этого пути:
После определения карты импортов, у нас появляется возможность импортировать наши модули следующим образом:
Карты импортов также предоставляют много других интересных возможностей. К сожалению, в настоящее время они поддерживаются только Chrome . Если вы пользуетесь другим агентом, при разработке приложения в практической части статьи импортируйте модули напрямую из node_modules .
Clear-Site-Data
Данный заголовок принимает следующие директивы:
Директивы могут указываться как по одной:
так и через запятую:
Последний пример аналогичен следующему:
К сожалению, в настоящее время данный заголовок не поддерживается Safari (ох уж этот современный IE :)).
Вот как это должно работать в теории. Скоро мы выясним, что на практике это работает немного по-другому, а кое-что и вовсе не работает.
Практика
Фронтенд и локальный сервер
Создаем директорию для проекта, переходим в нее, инициализируем проект и устанавливаем зависимости:
Создаем файл server.js для локального сервера и директорию public для статических файлов, а в ней файлы index.html , style.css и script.js :
Не забудьте создать файл .gitignore с node_modules .
Начнем с public/index.html . Создаем контейнер для UI и секцию с кнопками для взаимодействия с локальным сервером:
Обратите внимание на атрибуты data-action кнопок. Это небольшая хитрость позволит нам сильно упростить и сократить код скрипта. А по классам, вы, наверное, догадались, какой CSS-фреймворк мы используем для стилизации.
Добавляем карту импортов для модулей very-simple-fetch и idb :
Честно говоря, поиск нужного файла в директории node_modules — занятие не из приятных. К тому же приходится искать не просто основной файл, но нужную версию файла. Например, ES-модуль idb хранится в директории esm .
Подключаем наш скрипт с типом module :
С вашего позволения файл со стилями style.css я пропущу.
Переходим к public/script.js .
Давайте подумаем, что должен делать наш скрипт.
Вот мои идеи на этот счет:
- записать данные в локальное хранилище
- записать данные в индексированную БД
- записать данные в кеш с помощью Cache API
- получить куки от локального сервера
- при нажатии кнопки отправлять на сервер запрос, в ответ на который сервер будет устанавливать заголовок Clear-Site-Data с соответствующей директивой.
Приступим к реализации ( // -> — означает сигнатуру):
Обратите внимание на то, как мы формируем URL запроса. Мы добавляем к адресу сервера значение атрибута data-action кнопки. Это первая половина хитрости.
Теперь займемся сервером ( server.js ).
Что он должен делать?
Я хочу, чтобы он делал следующее:
Мы передаем клиенту куки вместе с загружаемыми модулями. Получается, что мы делаем это дважды, но это не критично. Поскольку у нас один домен и названия куки совпадают, мы в итоге получим только одно куки.
Обратите внимание на то, как мы извлекаем тип операции — директиву для Clear-Site-Data — из тела запроса. Мы разбиваем строку в массив по символу - и извлекаем второй элемент (элемент по индексу 1). Таким образом, если сервер получил clear-storage , то типом операции (директивой) будет storage .
Также обратите внимание на то, что директива должна быть закавычена, причем кавычки обязательно должны быть двойными ( " ).
Пришло время запустить сервер и убедиться в том, что все работает.
Добавляем в файл package.json команду для запуска сервера для разработки:
Выполняем эту команду в терминале:
Открываем инструменты разработчика, переходим в раздел Application (“Приложение”) и проверяем, что все наши данные успешно сохранены в браузере:
Видим, что данные из локального хранилища, индексированной БД и локального кеша были успешно удалены.
Кажется, что все хорошо, однако нажатие кнопки Reload contexts приводит к возникновению ошибки:
Текст ошибки говорит нам о том, что браузер не может распознать тип операции (тип данных для очистки).
Дело в том, что директива "executionContexts" в настоящее время поддерживается только Samsung Internet , т. е. можно сказать, что не поддерживается. В сети можно найти информацию о том, что данная директива, скорее всего, будет удалена из спецификации.
Дальше интересней: нажатие кнопки Clear all site data также приводит к ошибке:
Хотя должно приводить к очистке данных всех типов.
Здесь мы имеем дело с багом Chrome . Вот все, что мне удалось найти по данному багу. Кажется, в ближайшее время никто не собирается его фиксить.
В Firefox это работает:
Кажется, что эти директивы правильно интерпретируются браузером, т. е. приводят к очистке данных указанного типа.
Но что насчет определения принадлежности данных к источнику ответа перед их очисткой? Для того, чтобы убедиться в том, что удаляются только такие данные необходимо поднять еще один сервер. Для чистоты эксперимента развернем этот сервер на Heroku .
Удаленный сервер
Начнем с самого сервера. Создаем для него директорию, переходим в нее, инициализируем проект и устанавливаем зависимости:
Определяем команду для запуска сервера в package.json :
Создаем файл index.js следующего содержания:
- origin — заголовок Access-Control-Allow-Origin
- credentials — заголовок Access-Control-Allow-Credentials
- allowHeaders — заголовок Access-Control-Allow-Headers
Без этих настроек и еще одной на клиенте мы не сможем получить куки от "удаленного" сервера.
Для того, чтобы иметь возможность разворачивать приложения на Heroku , необходимо создать там аккаунт, а также глобально установить heroku-cli :
Инициализируем репозиторий и добавляем в него файлы приложения:
Создаем проект на Heroku :
Проверяем, что наш проект привязан к Heroku-проекту, и отправляем файлы:
Полную инструкцию по деплою приложения на Heroku можно найти здесь.
Добавляем в public/index.html раздел с кнопками для взаимодействия с удаленным сервером:
И вносим несколько изменений в public/script.js :
В разделе Application находим кешированные данные и куки от heroku:
И это не баг Chrome (или баг не только Chrome ), точно такой же результат мы получаем в Firefox :
Директива * также не удаляет кешированные данные, полученные от heroku:
К сожалению, по этой проблеме информации найти не удалось. Если вдруг вы знаете, в чем дело, пожалуйста, сообщите в комментариях.
Вывод
Итак, что мы имеем в сухом остатке?
Карта импортов в настоящее время поддерживается только Chrome . Будет ли она поддерживаться другими браузерами, и, если будет, когда это произойдет, неизвестно. Поэтому, несмотря на интересные возможности, использовать ее при разработке реальных приложений пока нельзя.
Что касается заголовка Clear-Site-Data , то, в целом, он неплохо справляется со своей задачей, однако тот факт, что он не поддерживается Safari , а также учитывая баг в Chrome и не очень понятное поведение браузеров по очистке кешированных данных, говорить о возможности его использования в продакшне также преждевременно.
Читайте также: