expires, max-age
По умолчанию, если куки не имеют ни одного из этих параметров, то они удалятся при закрытии браузера. Такие куки называются сессионными («session cookies»).
Чтобы помочь куки «пережить» закрытие браузера, мы можем установить значение опций или .
expires=Tue, 19 Jan 2038 03:14:07 GMT
Дата истечения срока действия куки, когда браузер удалит его автоматически.
Дата должна быть точно в этом формате, во временной зоне GMT. Мы можем использовать , чтобы получить правильную дату. Например, мы можем установить срок действия куки на 1 день.
Если мы установим в прошедшую дату, то куки будет удалено.
max-age=3600
Альтернатива , определяет срок действия куки в секундах с текущего момента.
Если задан ноль или отрицательное значение, то куки будет удалено:
Способы задания значений cookie
Способ задания значений cookie зависит того, как эти значения будут использоваться и какие имеются серверные ресурсы. Можно манипулировать временем жизни выставленных cookie и устанавливать подмножества URL (Universal Resource Locator), в которых заданные значения действительны. Есть несколько способов задания, наиболее часто используются три — через META-таги языка HTML, JavaScript и CGI-скрипты. Любым способом можно задавать как одно, так и несколько значений сразу. Сразу хочу предупредить — не забывайте об ограничениях по объему и количеству значений cookie, а также параметре domain, так как помимо основного доменного имени узла часто бывает несколько алиасов (alias).
1. Задание cookie с помощью META-тагов
Простейший способ выставить cookie — использовать соответствующий META-таг в контейнере <HEAD>…</HEAD> любого статического HTML документа. В общем случае это выглядит следующим образом:
<META HTTP-EQUIV=»Set-Cookie» CONTENT=»NAME=value; EXPIRES=date; DOMAIN=domain_name; PATH=path; SECURE»>
Такой способ задания cookie, на мой взгляд, наиболее интересен для создателей маленьких домашних страничек, когда нет возможности писать свои собственные CGI-скрипты. А если есть поддержка SSI(Server Side Include) или PHP/Fi, то можно делать интерактивные страницы вообще без использования внешних CGI-скриптов. При наличии SSI на узле создание интерактивности с использованием механизма cookie становится просто удовольствием.
Функция чтения значения cookie
Возвращает установленное значение или пустую строку, если cookie не существует.
// name - имя считываемого cookie
function getCookie(name) {
var prefix = name + "="
var cookieStartIndex = document.cookie.indexOf(prefix)
if (cookieStartIndex == -1)
return null
var cookieEndIndex = document.cookie.indexOf(";", cookieStartIndex + prefix.length)
if (cookieEndIndex == -1)
cookieEndIndex = document.cookie.length
return unescape(document.cookie.substring(cookieStartIndex + prefix.length, cookieEndIndex))
}
Отслеживание и частные данные
Куки связаны с определённым доменом. Если он совпадает с доменом страницы, на которой вы находитесь, то их называют «куками первого лица» (first-party cookies). Если это другой домен, их называют «сторонними куками» (third-party cookies). Куки первого лица отсылаются только на тот сервер, который их создал. Однако, страница может содержать изображения или другие компоненты (например, рекламные баннеры), хранящиеся на других серверах. Куки, посылаемые через такие компоненты, используются, главным образом, в рекламных целях или для отслеживания информации в сети. В качестве примера можно рассмотреть типы файлов cookie, используемые Google. Большинство браузеров по умолчанию разрешают использование сторонних куков, но есть расширения, позволяющие их блокировать (например, Privacy Badger от EFF).
Если вы не сообщите об использовании сторонних куков, а пользователь обнаружит их самостоятельно, то доверие к вам может пошатнуться. Чтобы избежать этого, лучше предоставлять соответствующую информацию. В некоторых странах использование куков регламентируется законодательством. Прочитать об этом можно, например, в Википедии в разделе cookie statement (создание куков).
Для запрета на отслеживание со стороны приложения, или межсайтового отслеживания, можно использовать заголовок , хотя технических или законодательных требований на этот счёт нет. Подробнее об этом рассказывается в разделе заголовок .
Правила по использованию куков в Евросоюзе (ЕС) определены в Директиве 2009/136/EC Европарламента (Directive 2009/136/EC), вступившей в действие 25 мая 2011. Это не закон, как таковой, а рекомендация странам-членам ЕС принять законы, соответствующие её требованиям. В каждой стране на этот счёт могут быть свои законы.
Согласно этой директиве для хранения или извлечения информации с компьютера пользователя требуется проинформировать его и получить соответствующее разрешение. С момента её появления многие сайты добавили баннеры, информирующие пользователя об использовании куков.
Подробнее об этом можно прочитать в соответствующем разделе Википедии (). За наиболее полной и точной информацией обращайтесь к законодательствам конкретных стран.
Более радикальный подход к кукам представляют собой куки-зомби, или «вечные» куки, которые восстанавливаются после удаления, и полное удаление которых умышленно затруднено. Они используют прикладные интерфейсы веб-хранилищ (Web storage API), Flash Local Shared Objects и другие методы собственного воссоздания в случае, если обнаружено их отсутствие.
- Evercookie by Samy Kamkar
- Zombie cookies on Wikipedia
Преимущества и недостатки доменов .com
Региональные доменные зоны, скажем, зона .ru, подойдет для сайта, целевой аудиторией которого являются исключительно пользователи рунета, однако, если вы хотите, чтобы сайт легко распознавался любым человеком, вне зависимости от того, где он находится в географическом плане, имеет смысл отдать предпочтение домену .com.
Кроме того, для русскоязычных пользователей есть возможность зарегистрировать имя сайта, написанное кириллицей, например, «авто.com».
Однако из-за того, что данная доменная зона открыта для регистрации не одно десятилетие, выбрать короткое, понятное и простое имя для сайта в ней в настоящий момент весьма затруднительно. Например, все возможные трехбуквенные варианты имен в зоне .com были зарегистрированы еще в далеком 2000 году, а четырехбуквенные – в 2007 году. На сегодняшний день единственный вариант получить такой домен – это купить его «с рук», причем по весьма значительной стоимости.
Дополнительные сведения
Одновременно можно задавать несколько значений cookie.
В случае, если cookie принимает новое значение при имеющемся уже в браузере cookie с совпадающими параметрами NAME, domain и path, то старое значение заменяется новым. В остальных случаях новые значения cookie добавляются к старым.
Использование expires не гарантирует сохранность cookie в течение заданного периода времени, поскольку клиент (браузер) может удалить запись из-за нехватки выделенного места или каких-либо других причин.
Клиент (браузер) имеет следующие ограничения для cookies:
- всего может храниться до 300 значений cookies
- каждый cookie не может превышать 4Кбайт
- с одного сервера или домена может храниться до 20 значений cookie
Если ограничение 300 или 20 превышается, то удаляется первая по времени запись. При превышении лимита объема в 4Кбайт корректность значения cookie страдает — отрезается кусок записи (с начала этой записи) равный превышению объема.
В случае кэширования документов, например, proxy-сервером, поле Set-cookie HTTP заголовка никогда не кэшируется.
Если proxy-сервер принимает ответ, содержащий поле Set-cookie в заголовке, предполагается, что поле доходит до клиента вне зависимости от кода возврата 304 (Not Modified) или 200 (OK). Соответственно, если клиентский запрос содержит в заголовке Cookie, то он должен дойти до сервера, даже если жестко установлен параметр If-modified-since.
Период восстановления домена
Статус в Whois:
Redemption Period (для доменов .NET, .COM, .NAME),
Pending Delete Restorable (для доменов .INFO, .ORG)
Период длится: 30 дней
Этот этап есть только у доменов в международных зонах. Даже когда домен уже удалён из личного кабинета пользователя и из базы регистратора (но не из реестра!), его всё ещё можно восстановить — за дополнительную плату. Если вы не успели продлить домен вовремя или решили не продлевать его, но затем передумали, напишите в службу поддержки вашего регистратора.
Отметим, что стоимость продления на этом этапе, как правило, в несколько раз больше начальной цены домена — такие правила устанавливают реестры доменных зон. Поэтому о продлении выгоднее задуматься на втором этапе.
Security & implementation concerns
This mechanism provides a great way to share information across domains, however it’s important to note that the model does not provide any security beyond what’s present from normal client-side cookies, and sensitive user data should never be stored via xdomain-cookies (which is true for all client-side cookies as well)
Additionally, since the script/iframe communicate via postMessage it does create a small level of chatter on that channel, which can sometimes cause issues if other scripts are listening/responding on postMessage events. The xdomain-cookie library enforces a pre-known data structure and namespacing for the postMessage calls, assuring that it only acts when messaged by the library directly.
Период удаления из реестра
Статус в Whois: Pending Delete
Для доменов в зонах в зонах .RU, .РФ, .SU этот этап четвёртый, для международных доменов — пятый. Домен автоматически удаляется из реестра, вернуть себе его уже нельзя.
Период длится: 1-5 дней для международных зон
Домены в зонах .RU, .SU, .РФ удаляют на следующий день после того, как закончится преимущественный период продления:
1. дата удаления публикуется в Whois-сервисе, в поле «free-date»;
2. если дата free-date попадает на выходной, праздничный или первый рабочий день, то удаление домена переносят на следующий рабочий день.
Напомним: пока освобождающийся домен не попал в списки на удаление, вы можете подать заявку на его регистрацию и попытаться вернуть себе. Однако на этом этапе у вас уже не будет преимуществ перед другими желающими арендовать домен и, возможно, вас опередят.
Обработка большого количества трафика
Согласно спецификациям DNS, корневые домены всегда должны указывать на IP-адрес. Но чтобы использовать CDN, вам необходимо указать на своем сайте домен CDN, а не IP-адрес. Теоретически вы можете сопоставить свой домен как с IP-адресом, используя запись типа A, так и с доменом CDN с помощью записи CNAME. Но есть еще одно правило DNS, говорящее о том, что запись CNAME не может сосуществовать с другими типами ресурсных записей. То есть при добавлении обеих A-запись, указывающая на IP-адрес, будет проигнорирована.
Если вас немного сбили с толку все технические термины, упомянутые выше, краткая версия такова: из-за специфики работы DNS-запросов вы не можете указать имя хоста без www на домен CDN. Это приведет к неожиданным ошибкам и будет препятствовать нормальной работе вашего сайта.
Если же вы выберете имя хоста с www в качестве предпочтительной версии, у вас не возникнет проблем с соблюдением правил DNS. Вам просто нужно создать запись CNAME для имени хоста c www, сопоставив ее с выбранной вами CDN. Также добавьте запись A для вашего корневого домена, указывающую на IP-адрес сайта.
Также стоит упомянуть, что некоторые провайдеры DNS (Cloudflare, DNS Made Easy, DNSSimple и другие) ввели обходные пути для преодоления ограничений DNS. Но использование обходных путей ограничит ваш выбор провайдеров DNS и вы при этом можете усложнить жизнь пользователей из-за перенаправления на удаленный узел CDN.
CSS:
.cookie_notice {
display: none;
position: fixed;
z-index: 9999999;
bottom: 0;
left: 0;
right: 0;
text-align: center;
font-size: 15px;
font-family: Verdana, sans-serif;
color: #FFF;
background: #337AB7;
padding: 10px 20px;
border-top: 4px solid #BFE2FF;
}
/* Оформление кнопок */
.cookie_btn {
display: inline-block;
margin: 10px 6px 4px 6px;
text-decoration: none;
position: relative;
font-size: 13px;
padding: 4px 12px;
color: #FFF;
font-weight: bold;
text-transform: uppercase;
background: #337AB7;
border: 2px solid #BFE2FF;
}
.cookie_btn:hover {
color: #FFF;
}
.cookie_btn:after,
.cookie_btn:before {
position: absolute;
height: 2px;
left: 50%;
background: #FFF;
bottom: -6px;
content: «»;
transition: all 280ms ease-in-out;
width: 0;
}
.cookie_btn:before {
top: -6px;
}
.cookie_btn:hover:after,
.cookie_btn:hover:before {
width: 100%;
left: 0;
}
|
1 |
.cookie_notice { displaynone; positionfixed; z-index9999999; bottom; left; right; text-aligncenter; font-size15px; font-familyVerdana,sans-serif; color#FFF; background#337AB7; padding10px20px; border-top4pxsolid#BFE2FF; } .cookie_btn { displayinline-block; margin10px6px4px6px; text-decorationnone; positionrelative; font-size13px; padding4px12px; color#FFF; font-weightbold; text-transformuppercase; background#337AB7; border2pxsolid#BFE2FF; } .cookie_btn:hover { color#FFF; } .cookie_btn:before { positionabsolute; height2px; left50%; background#FFF; bottom-6px; content»»; transitionall280msease-in-out; width; } .cookie_btn:before { top-6px; } .cookie_btn:hover:before { width100%; left; } |
Что такое куки файлы?
Cookies – это текстовые файлы с информацией о действиях пользователя на различных сайтах, которые автоматически сохраняются в одной из папок его интернет-браузера после того, как он согласится их принять. Хранимые в них данные помогают браузеру распознать сайт при повторном посещении и выполнить определенные действия, например, в виде автоматической авторизации.
Благодаря файлам куки веб-браузер на компьютере или мобильном устройстве обменивается с сервером сайта персональной информацией пользователя. В них могут содержаться самые разные сведения, включая пользовательский логин и пароль, данные о его местоположении, часовом поясе, выбранной теме дизайна интерфейса сайта, языке, валюте и т.д.
Также в cookies сохраняется информация о добавленных пользователем товарах в корзину, избранное, желания или другие подобные разделы. Наконец, эти файлы очень полезны для отслеживания статистики посещений сайтов, так как они помогают идентифицировать их посетителей. Они фиксируют IP-адрес посетителя, дату и время посещения сайта, используемую им версию операционной системы и интернет-браузера, а еще считывают клики и переходы.
Приложение: GDPR
Эта тема вообще не связана с JavaScript, но следует её иметь в виду при установке куки.
В Европе существует законодательство под названием GDPR, которое устанавливает для сайтов ряд правил, обеспечивающих конфиденциальность пользователей. И одним из таких правил является требование явного разрешения от пользователя на использование отслеживающих куки.
Обратите внимание, это относится только к куки, используемым для отслеживания/идентификации/авторизации. То есть, если мы установим куки, которые просто сохраняют некоторую информацию, но не отслеживают и не идентифицируют пользователя, то мы свободны от этого правила
То есть, если мы установим куки, которые просто сохраняют некоторую информацию, но не отслеживают и не идентифицируют пользователя, то мы свободны от этого правила.
Но если мы собираемся установить куки с информацией об аутентификации или с идентификатором отслеживания, то пользователь должен явно разрешить это.
Есть два основных варианта как сайты следуют GDPR. Вы наверняка уже видели их в сети:
-
Если сайт хочет установить куки для отслеживания только для авторизованных пользователей.
То в регистрационной форме должен быть установлен флажок «принять политику конфиденциальности» (которая определяет, как используются куки), пользователь должен установить его, и только тогда сайт сможет использовать авторизационные куки.
-
Если сайт хочет установить куки для отслеживания всем пользователям.
Чтобы сделать это законно, сайт показывает модальное окно для пользователей, которые зашли в первый раз, и требует от них согласие на использование куки. Затем сайт может установить такие куки и показать пользователю содержимое страницы. Хотя это создаёт неудобства для новых посетителей – никому не нравится наблюдать модальные окна вместо контента. Но GDPR в данной ситуации требует явного согласия пользователя.
GDPR касается не только куки, но и других вопросов, связанных с конфиденциальностью, которые выходят за рамки материала этой главы.
Какую информацию хранят cookie
Сегодня cookie-файлы хранят в браузере практически любую информацию о сайте. Например, сохраняются авторизационные данные аккаунта в социальной сети, поэтому посетителю не нужно каждый раз вводить логин и пароль. Также для ускорения работы подгружаются дополнительные элементы сайтов: шрифты, цвета, история поиска и выбранные формы (например регион или язык).
Все это упрощает жизнь как рекламодателям, так и пользователям. Первые могут легко взаимодействовать с целевой аудиторией, а вторые комфортно серфить и быстро оформлять заказы.
Однако не стоит путать cookie-файлы с кэшем и данными автозаполнения. Кэш – еще один способ, которым пользуются разработчики при оптимизации сайтов. И если cookie – текстовый документ с некой информацией, то в кэше сохраняются «тяжелые данные»: изображения, анимированные фрагменты и так далее. Соответственно, кэш может весить очень много, поэтому его нужно постоянно очищать. Данные автозаполнения – сохраняемый текст, вводимый в формы (электронная почта, логин, номер телефона или пароль). Они также выводятся и очищаются отдельно от cookie.
«Непростые» запросы
Мы можем использовать любой HTTP-метод: не только , но и , и другие.
Некоторое время назад никто не мог даже предположить, что веб-страница способна делать такие запросы. Так что могут существовать веб-сервисы, которые рассматривают нестандартный метод как сигнал: «Это не браузер». Они могут учитывать это при проверке прав доступа.
Поэтому, чтобы избежать недопониманий, браузер не делает «непростые» запросы (которые нельзя было сделать в прошлом) сразу. Перед этим он посылает предварительный запрос, спрашивая разрешения.
Предварительный запрос использует метод , у него нет тела, но есть два заголовка:
- содержит HTTP-метод «непростого» запроса.
- предоставляет разделённый запятыми список его «непростых» HTTP-заголовков.
Если сервер согласен принимать такие запросы, то он должен ответить без тела, со статусом 200 и с заголовками:
- должен содержать разрешённые методы.
- должен содержать список разрешённых заголовков.
- Кроме того, заголовок может указывать количество секунд, на которое нужно кешировать разрешения. Так что браузеру не придётся посылать предзапрос для последующих запросов, удовлетворяющих данным разрешениям.
Этот запрос не является простым по трём причинам (достаточно одной):
- Метод
- не один из: , , .
- Содержит «непростой» заголовок .
Перед тем, как послать такой запрос, браузер самостоятельно генерирует и посылает предзапрос, который выглядит следующим образом:
- Метод: .
- Путь – точно такой же, как в основном запросе: .
- Особые заголовки:
- – источник.
- – запрашиваемый метод.
- – разделённый запятыми список «непростых» заголовков запроса.
Сервер должен ответить со статусом 200 и заголовками:
- .
Это разрешит будущую коммуникацию, в противном случае возникает ошибка.
Если сервер ожидает в будущем другие методы и заголовки, то он может в ответе перечислить их все сразу, разрешить заранее, например:
Теперь, когда браузер видит, что есть в , а – в списке , он посылает наш основной запрос.
Кроме того, ответ на предзапрос кешируется на время, указанное в заголовке (86400 секунд, один день), так что последующие запросы не вызовут предзапрос. Они будут отосланы сразу при условии, что соответствуют закешированным разрешениям.
Если предзапрос успешен, браузер делает основной запрос. Алгоритм здесь такой же, что и для простых запросов.
Основной запрос имеет заголовок (потому что он идёт на другой источник):
Сервер не должен забывать о добавлении к ответу на основной запрос. Успешный предзапрос не освобождает от этого:
После этого JavaScript может прочитать ответ сервера.
Предзапрос осуществляется «за кулисами», невидимо для JavaScript.
JavaScript получает только ответ на основной запрос или ошибку, если со стороны сервера нет разрешения.
So… why not just use cookies??
Cookies are the go-to method for tracking user information in a web client. First-party cookies (cookies set on the current domain you are browsing) allow tracking for data on a single domain or subdomains, so they will not work across top-level domains. 3rd part cookies (cookies set on a domain other than the one you are browsing) would work in this context to allow us to share and persist the cookie across domains, however they are associated heavily with advertisers and many users have 3rd-party cookies disabled in their browser, or they get blocked/deleted by plugins and programs that are designed to stop advertising. Based on recent research, as many as 40% of 3rd-party cookies are never set due to content/privacy settings, or deleted by ad-block and anti-spyware programs!
As an alternative solution we also considered using a combination of client/server side identification with ID fingerprint factors such as IP address, user agent, device, etc — but this method leaves too much room for error. As browsers upgrade user agents change, IP addresses for multiple machines on a network can appear to be the same when run through a proxy and change as they move networks, etc — we needed a reliable way to identify a user 100% of the time across networks with tolerance for the previous factors. Additionally, we wanted the solution to be completely client side -as a third party script provider, when our client’s traffic increases so do the number of responses for our tracking script, and we didn’t want to rely on scaling a complicated server-side solution.
Introduction
Cookies позволяют идентифицировать пользователя и в дальнейшем выполнять запросы от имени данного пользователя.
Поэтому их безопасность очень важна. Ранее для сессионных уже был добавлен параметр , который защищает доступ к из и тем самым препятствует перехвату с помощью -уязвимостей.
Но все же оставалась возможность сделать запрос с другого домена к сайту (), на котором авторизован пользователь, с передачей посредством встраивания скрипта или вызова изображения, например:
Для того, чтобы запретить передачу при таких кроссдоменных запросах, был введен параметр , который может принимать следующие значения (первые два запрещают кроссдоменную передачу):
До недавнего времени браузеры не обрабатывали данный параметр и считали, что он по умолчанию установлен как .
Но в феврале Chrome стал обрабатывать параметр , и, если параметр не установлен, то значение по умолчанию выставлять , а не , как было до версии 80.
Конечно же, об изменениях было известно заранее (еще в сентябре 2019) и 79 версия уже включала в себя поддержку обработки данного параметра, но она по умолчанию была отключена.
С выходом 80 у некоторых сайтов, которые пользовались возможностью кроссдоменной передачи , появились проблемы с работоспособностью в данном браузере.
После выхода 80 было решено на время откатить функционал проверки , т.к. не все сайты успели вовремя среагировать на изменения, но позже его опять вернут.
Как появились cookies и почему они так называются?
Технология cookies-файлов была изобретена в 1994 году одним из сотрудников компании Netscape Communications, в то время она создавала ПО для электронной коммерции. Он придумал использовать текстовые файлы для размещения данных о покупках пользователей, которые хранились бы на их компьютерах, а затем автоматически отправлялись на сервер при каждом посещении сайта. В 1994 году технология cookie появилась в интернет-браузере Mosaic Netscape, а год спустя ею был оснащен знаменитый Internet Explorer.
Что касается истории возникновения названия этих файлов, то здесь выделяют несколько версий:
- Наиболее распространенная версия утверждает, что технология получила название от термина magic cookie, обозначающего пакеты данных, которыми обмениваются между собой программы.
- Еще одна версия гласит, что куки-файлы названы так по мотивам сказки братьев Гримм «Гензель и Гретель». В ней дети смогли вернуться домой из леса, благодаря разбросанным ими по пути хлебным крошкам.
- Наконец, по третьей версии разработчик этой технологии оставил в ней скрытую «пасхалку», которая приводила к периодическим сбоям в работе системы и при этом на рабочих мониторах появлялось сообщение «Gimme a cookie». Для возвращения системы в рабочее состояние нужно было ввести слово cookie, что дало технологии такое устоявшееся название.
Как правильно с точки зрения SEO
Что же лучше — доменное имя с www или без? На самом деле с точки зрения SEO не имеет значения, какой вариант вы выберете, и это подтвердил Джон Мюллер в Twitter. Это вопрос брендинга и технических возможностей — мы рассмотрим оба момента далее.
Если вы сделаете свой сайт доступным как через www, так и без www, важно сообщить поисковым системам, какой из вариантов доменного имени предпочтителен. В противном случае поисковики будут рассматривать версии с www и без www как отдельные сайты, они оба проиндексируются — и вам придется решать проблему дублирования контента
Существует несколько способов указания предпочитаемого (канонического) доменного имени для Google. Наиболее распространенное решение — настроить 301 редирект на стороне сервера. Тогда каждый раз, когда сервер получает запрос на неканонический домен, он автоматически перенаправляет пользователей на канонический. Если ваша предпочтительная версия — www.example.com и пользователи вводят example.com/page01, они в конечном итоге увидят в адресной строке браузера www.example.com/page01.
Если по какой-то причине у вас нет технических средств для настройки 301 редиректа, вы можете добавить тег <link> с атрибутом rel=»canonical» в HTML-код всех страниц с нежелательной версией. Только учтите, что этот метод не так надежен, как редирект 301. Google рассматривает канонические ссылки как рекомендации, а не инструкции, и в результате обе версии сайта могут быть проиндексированы.
Если добавление тегов rel=»canonical» для вас в любом случае лучше, вот как это можно реализовать. Для названия сайта www.example.com добавьте в HTML-код https://example.com/page01 следующую строку:
В WordPress 2.9 и выше теги rel=»canonical» будут добавляться на все страницы сайта автоматически, поэтому вам даже не придется ничего делать самостоятельно. Теги будут указывать на версии сайта с www или без www в зависимости от того, какой вы указали в качестве адреса WordPress (URL) в общих настройках WordPress.
С точки зрения пользователя разница в том, что при использовании тега rel=»canonical» вместо 301 редиректа URL в адресной строке браузера и истории не меняется. Таким образом, пользователь, пытающийся получить доступ к example.com, увидит именно этот URL в адресной строке, даже если www.example.com является вашей канонической версией.
В Яндексе настроить переадресацию можно с помощью 301 редиректа или канонического адреса, а также используя метатег refresh. Чтобы ускорить передачу поисковому роботу информации о предпочитаемой версии, воспользуйтесь инструментом «Переезд сайта». Для этого нужно зайти в Яндекс.Вебмастер и поставить либо убрать галочку возле «Добавить WWW».
Этот метод позволит учитывать старые внешние ссылки и оригинальные тексты на новом варианте сайта вне зависимости от того, выберете вы вариант с www или без. Смена произойдет в течение нескольких недель.
Решив, какое доменное имя использовать, и указав предпочитаемую версию как каноническую с помощью любого из описанных методов, важно последовательно использовать выбранный вами вариант URL. Если вы решили оставить www, убедитесь, что все URL-адреса в файле Sitemap и внутренние ссылки содержат этот префикс
По возможности постарайтесь сделать так, чтобы ваши обратные ссылки также включали www — хотя предполагается, что и редирект 301, и атрибут rel=»canonical» пропускают ссылочный вес, некоторая его часть может быть утеряна по пути. В свою очередь, поисковые системы оценят такую последовательность и вознаградят вас улучшенными позициями.
Борьба с cookies и аналитика
Apple уже достаточно давно ведёт борьбу с cookies. На данный момент у пользователей Safari в зависимости от настроек информация может сохраняться от 1 (3rd-party) до 7 (1-st party) дней. А данные в localStorage хранятся на протяжении 7 дней. Этого катастрофически мало.
Представим, что клиент увидел рекламное объявление 1 января. Оно его заинтересовало, и он решил перейти на веб-сайт через браузер Safari
Там клиент просмотрел несколько товаров и добавил два из них в корзину, однако покупку решил отложить. 3 января он вернулся через прямой заход (не важно, запомнил название сайта, перешёл через закладку или просто не закрывал страницу) и совершил покупку.
И эту покупку Google Analytics свяжет не со сработавшей рекламной кампанией, а с прямым трафиком.
В отчётах это будет выглядеть так, как будто ни с того ни с сего появился клиент и даже без добавления товара в корзину совершил покупку. Такая ситуация обесценит сработавшее рекламное объявление и не позволит сделать правильные выводы.
Ещё одним печальным последствием отказа от cookies будет увеличение доли прямого трафика, ухудшение качества ремаркетинга и look-alike аудиторий. Увеличение доли прямого трафика прямо связано с ростом числа новых пользователей, так как теряется первоначальный источник, откуда пришёл клиент. В аудитории ремаркетинга пользователи будут попадать всего на 1 день для Safari и на X дней для Google Chrome (в зависимости от того, что решат в Google). Look-alike аудитории также испортятся, ведь их размер заметно снизится в связи с уменьшением времени жизни пользователей исходных данных.
Google не настолько торопится озаботиться конфиденциальностью пользователей, поэтому в Google Chrome для рекламодателей ещё всё не так плохо. Файлы cookies и объекты localStorage могут жить по несколько лет. Однако в начале 2020 года представители Google заявили, что они также собираются отказаться от сторонних файлов cookie. Скорее всего, когда-нибудь в Chrome также уменьшится время жизни 1-st и 3-d party cookies и localStorage.
Чтобы посмотреть, какую часть данных потеряет ваш веб-сайт, можно зайти в Google Analytics и сравнить долю новых пользователей в браузере Safari с остальными браузерами. Разница и будет процентом потерянных данных.
httpOnly
Эта настройка не имеет ничего общего с JavaScript, но мы должны упомянуть её для полноты изложения.
Веб-сервер использует заголовок для установки куки. И он может установить настройку .
Эта настройка запрещает любой доступ к куки из JavaScript. Мы не можем видеть такое куки или манипулировать им с помощью .
Эта настройка используется в качестве меры предосторожности от определённых атак, когда хакер внедряет свой собственный JavaScript-код в страницу и ждёт, когда пользователь посетит её. Это вообще не должно быть возможным, хакер не должен быть в состоянии внедрить свой код на ваш сайт, но могут быть ошибки, которые позволят хакеру сделать это
Обычно, если такое происходит, и пользователь заходит на страницу с JavaScript-кодом хакера, то этот код выполняется и получает доступ к , и тем самым к куки пользователя, которые содержат аутентификационную информацию. Это плохо.
Но если куки имеет настройку , то не видит его, поэтому такое куки защищено.
Итого
предоставляет доступ к куки
- операция записи изменяет только то куки, которое было указано.
- имя и значение куки должны быть закодированы.
- одно куки вмещает до 4kb данных, разрешается более 20 куки на сайт (зависит от браузера).
Настройки куки:
- , по умолчанию устанавливается текущий путь, делает куки видимым только по указанному пути и ниже.
- , по умолчанию куки видно только на текущем домене, если явно указан домен, то куки видно и на поддоменах.
- или устанавливает дату истечения срока действия, без них куки умрёт при закрытии браузера.
- делает куки доступным только при использовании HTTPS.
- запрещает браузеру отправлять куки с запросами, поступающими извне, помогает предотвратить XSRF-атаки.
Дополнительно:
- Сторонние куки могут быть запрещены браузером, например Safari делает это по умолчанию.
- Установка отслеживающих куки пользователям из стран ЕС требует их явного согласия на это в соответствии с законодательством GDPR.
