В случае с вложенными функциями (Nested Functions) для решения «проблемы смены контекста» лучше всего использовать стрелочные функции ведь это одна из причин существования стрелочных функций.
В случае с функциями обратного вызова (Method as callback) и особенно React-компонентами есть один очень интересный способ решения (правда он «ESNEXT candidate stage-3») — указание метода класса через поле экземпляра класса (instance class field) и стрелочной функции как в решении с Nested Functions:
class Service {
constructor(){
this.token = "token";
}
doSomething: () => console.log(this.token)
}
// Равносильно:
class Service {
constructor(){
this.token = "token";
this.doSomething = () => console.log(this.token);
}
}
// Или:
function Service() {
this.token = "token";
this.doSomething = () => console.log(this.token);
}
Ну строить защиту базируясь на неосведомленности юзеров, так себе защита.
Однако от этого не уйти — любая защита базируется на отсутствии инструментов и достаточных знаний.
Я могу написать маленький js сниппет, который нужно просто скопировать в F12-DevTools консоль.
Можете, от этого нельзя защититься или по крайней мере сложно. Но опять таки у вас есть инструмент (DevTools) и знания, с помощью которых вы делаете инструмент для остальных, избавляющий их от необходимости знаний. В конечном итоге всё-равно есть инструмент (js сниппет).
А ещё ни что не мешает вам добавить в js сниппет XSS, о котором не будут знать потенциальные пользователи вашего сниппета в виду отсутствия знаний связанных с программированием.
Наверное именно по этому у того же Facebook'а в консоли выводят предупреждение (которое тоже является своего рода защитой):
Остановитесь! Эта функция браузера предназначена для разработчиков. Если кто-то сказал вам скопировать и вставить что-то здесь, чтобы включить функцию Facebook или «взломать» чей-то аккаунт, это мошенники. Выполнив эти действия, вы предоставите им доступ к своему аккаунту Facebook.
Подробнее на www.facebook.com/selfxss.
Браузер априори не очень хороший клиент для доставки DRM информации.
Не хуже любого другого, да возможно больше векторов атаки, но DRM так же как и любая защита не идеальна и вполне обходима, даже если используется какой-то другой клиент (не браузер) — главное наличие знаний.
Поддерживает любой язык, главное чтобы в шрифте имелся набор необходимых символов. Этот метод никак не завязан на язык он работает только с символами, его задача просто поменять их начертания местами и зная такую таблицу перестановки вернуть новый текст и шрифт с её учётом.
«Специалист» в данном контексте был использован как обобщение категории имеющей инструмент и умеющей им пользоваться. Возможно слово было подобрано не сильно подходящее, ведь такой же пример как вы привели можно привести и по поводу взломщиков. Умение взять болгарку и просто распилить засовы — это уровень любого у кого есть эта самая болгарка.
Однако если ты умеешь читать CSS и знаешь о медиа-запросах в нём — это уже некие специальные/специфичные знания. Такими же специфичными знаниями в случае со взломщиком будет знание расположения засовов или любые другие знания, которые могут позволить так или иначе открыть дверь. Расчёт же обычно делают скорее на обычного пользователя.
В чём я не прав? К стати ниже уже указали, что эта защита связана конкретно с тем, чтобы не дать доступ к сообщению после определённого временного интервала (ну и до подтверждения доступа), однако до истечения этого интервала считается, что получатель по умолчанию доверенное лицо.
Любой, кто владеет кнопкой PrtSc, а это почти все, сможет сохранить себе сообщение навсегда, как бы Google не старался.
Но всё-таки выше уже указали, что задача скорее защитить от получения информации после определённого срока, а до его истечения никакой защиты не предусматривается. Это как временная ссылка, доступная в течении 15 минут: в этот временной промежуток по ней может пройти кто угодно и сколько угодно раз, но вот после истечения временного промежутка перейти по ней невозможно.
Так тут речь идёт о пластиковой двери которая закрывается просто табличкой «не входить» а не о стальной двери с замками для взлома которой нужно приложить некислые усилия.
Даже в данном случае для «взлома» нужно приложить «некислые усилия», ведь в первую очередь расчёт на то, что «обычный пользователь» не знает и не умеет пользоваться такими инструментами как DevTools. А от умеющих ими пользоваться расчёт на закон DMCA.
Так, что пример был верен:
можно вскрыть замок на входной двери, но мы ведь квартирную дверь запираем, тем не менее.
Взломщики/специалисты тем и отличаются от обычных граждан/пользователей, что осведомлены о методах обхода защиты в виде железной двери и уж тем более замка. И соответственно для них любая такая «железная дверь» сравнима с «пластиковой дверью и табличкой „не входить“».
Возможно защита действительно слаба или недостаточна, но это защита. И не будем забывать, что у любой защиты есть свои минусы и узкие места, которые рано или поздно будут известны неопределённому кругу лиц. Это просто такая же истина как для программиста то, что нельзя устранить 100% багов: рано или поздно всплывут новые причём в непредсказуемых условиях.
Не бывает идеального решения — бывает достаточное решение.
Насчёт привязки тройки к телефону: такая возможность была в 2016 году, ясно дело не очевидно (уже даже не припомню действия). Сейчас же можно сказать по большей части привязку заменили сервисом «Мобильный билет».
А еще есть актививация денег — то есть закинуть кое как денег на тройку можно, но пользоваться ими нельзя, надо ехать до метро.
А на этот счёт я скажу так: всё зависит от способа и инструмента зачисления денег на карту тройка.
Если вы пополняете «Кошелёк» тройки или конкретные билеты через мобильное приложение (партнёров), то действительно необходимо «Активировать» (по сути записать валидные данные на тройку) с помощью жёлтого терминала, которые установлены только в метро.
Но опять таки существует и официальное приложение (От ВТБ Банк Москвы, на их инфраструктуре держится система карты тройка), при пополнении через которое «Активация» терминалом не требуется (приложение записывает валидные данные).
Могу посоветовать обратить внимание на событие `response`:
page.on('response', response => {
// Skip http bad statuses.
if (!response.ok()) return;
const headers = response.headers();
// Skip any content that type not application/octet-stream
if (headers['Content-Type'] !== 'application/octet-stream') return;
const buffer = await response.buffer();
// Do what you want
});
await page.goto('https://example.com/some.file');
Вместо вызова `response.buffer()` можно ещё использовать `response.text()`, если работа идёт с текстовыми файлами.
P.S. этот код полностью исполняется в контексте Nodejs
Вот так habrahabr.ru/post/seo-optimizaciya-stati — не очень хорошо. Лучше, что бы робот сразу видел, что это страница, а не каталог. Т.е. вида habrahabr.ru/post/seo-optimizaciya-stati.html
Это никак не влияет ни на один фактор, поисковым системам всё-равно есть у страницы расширение или нет и это подтверждается официально. Информацию о типе ресурса поисковые роботы получают из HTTP заголовка Content-Type, если он не указан по умолчанию считается text/plain.
Но что--то мне подсказывает что это очень затратная операция и он делает это не для всего инетернет.
Ну там всё по уму сделано, чтобы минимизировать затраты во первых ускорены во много раз часы т.е. Date.now() через 1 реальную секунду будет отличаться в несколько раз больше чем на секунду. А ещё функция Math.random() возвращает заранее просчитанные дискретные значения. Вообщем там всё сделано, чтобы минимизировать затраты.
Так что используется это для всех страниц, а в плане рейтинга есть другие причины: т.к. страница при загрузке без рендера на клиенте содержит мало теоретически полезной для пользователя информации, то и весовой рейтинг получает меньше и это скорее недоработка.
Ну это не главное на самом деле, просто ветка пошла с того, что если добавить «дополнительные критерии», то React с JSX выпадет из рейтинга. Под этими «дополнительными критериями» подразумевалось в том числе и SEO. Так вот это сильно ошибочное утверждение т.к. есть опять таки тот же riot.js и как я указывал несколько выше NextJS, позволяющие делать универсальные приложения одинаково работающие как на клиенте, так и на сервере. Да даже без них есть ряд сервисов кеширующих клиентский рендер (на базе Chrome).
В мире SEO больше нет поддержки Ajax. Это от Google. Преимуществ нет.
Кто вам такую чушь сказал? Google как начал использовать робота основанного на Chrome так и использует, да некоторые фишки он не поддерживает т.к. на данный момент основан на Chrome 43. Но вся остальная поддержка JS и выливающихся остаётся.
А потом fetch запросы на клиенте упрощают жизнь в первую и непосредственную очередь для пользователей, а не роботов. А для роботов и пользователей без JS мы сами отрисовываем страницу.
React отрабатывает как на сервере так и на клиенте. Если клиент не поддерживает JS, нет проблем т.к. рендер дублируется на сервере. Если клиент поддерживает JS, при внутренних переходах он получает не всю страницу отрендеренную на сервере страницу, а только данные для рендера и уже клиент сам отрисовывает страницу, тем самым в том числе уменьшая объём передаваемых данных. Если кратко — это один и тот же код на React.
React с JSX не вывалится. Ведь главная проблема JS фреймворков в плане SEO была именно из-за того, что поисковые боты их не могли индексировать т.к. они рендерятся на клиенте (для этого нужен JS и немного иная логика робота), но у крупных поисковиков уже умеют как пару лет, а у остальных получаем индексирование с серверным рендерингом. В мире React для этого есть хороший фреймворк NextJS.
Правда ввиду невозможности наследования прозрачного цвета (тот же цвет, но с альфа каналом в нуле) и особенностей обработки градиентов в некоторых браузерах может получиться эффект перехода любого цвета в прозрачный чёрный.
Лично мне совершенно неясно, почему домены верхнего уровня выданы по одной штуке на государство — при том, что государства различаются по размеру ну очень сильно.
Почему же по одной штуке? Возможно это будет открытием, но у РФ 3 национальных домена .su, .ru и.рф под управлением Координационного центра национального домена сети Интернет (по сути гос. компания).
На мой взгляд, город с населением в миллион человек имеет такое же право на домен верхнего уровня, как и мелкое государство. В таком случае организации, ведущие деятельность в Москве, регистрировали бы домены в зоне верхнего уровня «msk»;
Очередное открытие: существуют домены верхнего уровня .moscow и.москва под управлением Фонда содействия развитию технологий и инфраструктуры Интернета. Другой пример .nyc у Нью-Йорка.
А чем больше доменов — тем ниже уровень монополизации в сфере регистрации доменов
А вам не достаточно 1572 домена верхнего уровня? По поводу регистраторов это уже никак не связано с количеством доменов верхнего уровня: регистраторы не равно администраторы, они лишь посредники.
Так же обращаю внимание, что ICANN работает с разными компаниями, так национальные домены разных стран управляются государственными компаниями соответствующих стран. Более того вообще говоря зарегистрировать домен верхнего уровня может любая компания, но если сможет доказать, что это действительно очень нужно. Например, Яндекс в прошлом году добились регистрации домена верхнего уровня (.yandex) для собственных нужд. И собственно Яндекс не единственные как-нибудь посмотрите вот этот список: https://www.iana.org/domains/root/db
Интеграция с системой умного дома будет, вообще у Яндекса в этом году достаточно сюрпризов и проектов о которых они ничего не говорят во всяком случае пока не говорят.
В случае с функциями обратного вызова (Method as callback) и особенно React-компонентами есть один очень интересный способ решения (правда он «ESNEXT candidate stage-3») — указание метода класса через поле экземпляра класса (instance class field) и стрелочной функции как в решении с Nested Functions:
Однако от этого не уйти — любая защита базируется на отсутствии инструментов и достаточных знаний.
Можете, от этого нельзя защититься или по крайней мере сложно. Но опять таки у вас есть инструмент (DevTools) и знания, с помощью которых вы делаете инструмент для остальных, избавляющий их от необходимости знаний. В конечном итоге всё-равно есть инструмент (js сниппет).
А ещё ни что не мешает вам добавить в js сниппет XSS, о котором не будут знать потенциальные пользователи вашего сниппета в виду отсутствия знаний связанных с программированием.
Наверное именно по этому у того же Facebook'а в консоли выводят предупреждение (которое тоже является своего рода защитой):
Не хуже любого другого, да возможно больше векторов атаки, но DRM так же как и любая защита не идеальна и вполне обходима, даже если используется какой-то другой клиент (не браузер) — главное наличие знаний.
Однако если ты умеешь читать CSS и знаешь о медиа-запросах в нём — это уже некие специальные/специфичные знания. Такими же специфичными знаниями в случае со взломщиком будет знание расположения засовов или любые другие знания, которые могут позволить так или иначе открыть дверь. Расчёт же обычно делают скорее на обычного пользователя.
Использовать подобный метод: https://mess.now.sh/.
Правда это не избавляет от:
Но всё-таки выше уже указали, что задача скорее защитить от получения информации после определённого срока, а до его истечения никакой защиты не предусматривается. Это как временная ссылка, доступная в течении 15 минут: в этот временной промежуток по ней может пройти кто угодно и сколько угодно раз, но вот после истечения временного промежутка перейти по ней невозможно.
Даже в данном случае для «взлома» нужно приложить «некислые усилия», ведь в первую очередь расчёт на то, что «обычный пользователь» не знает и не умеет пользоваться такими инструментами как DevTools. А от умеющих ими пользоваться расчёт на закон DMCA.
Так, что пример был верен:
Взломщики/специалисты тем и отличаются от обычных граждан/пользователей, что осведомлены о методах обхода защиты в виде железной двери и уж тем более замка. И соответственно для них любая такая «железная дверь» сравнима с «пластиковой дверью и табличкой „не входить“».
Возможно защита действительно слаба или недостаточна, но это защита. И не будем забывать, что у любой защиты есть свои минусы и узкие места, которые рано или поздно будут известны неопределённому кругу лиц. Это просто такая же истина как для программиста то, что нельзя устранить 100% багов: рано или поздно всплывут новые причём в непредсказуемых условиях.
Не бывает идеального решения — бывает достаточное решение.
А на этот счёт я скажу так: всё зависит от способа и инструмента зачисления денег на карту тройка.
Если вы пополняете «Кошелёк» тройки или конкретные билеты через мобильное приложение (партнёров), то действительно необходимо «Активировать» (по сути записать валидные данные на тройку) с помощью жёлтого терминала, которые установлены только в метро.
Но опять таки существует и официальное приложение (От ВТБ Банк Москвы, на их инфраструктуре держится система карты тройка), при пополнении через которое «Активация» терминалом не требуется (приложение записывает валидные данные).
Вместо вызова `response.buffer()` можно ещё использовать `response.text()`, если работа идёт с текстовыми файлами.
P.S. этот код полностью исполняется в контексте Nodejs
Это никак не влияет ни на один фактор, поисковым системам всё-равно есть у страницы расширение или нет и это подтверждается официально. Информацию о типе ресурса поисковые роботы получают из HTTP заголовка Content-Type, если он не указан по умолчанию считается text/plain.
Так что используется это для всех страниц, а в плане рейтинга есть другие причины: т.к. страница при загрузке без рендера на клиенте содержит мало теоретически полезной для пользователя информации, то и весовой рейтинг получает меньше и это скорее недоработка.
Ну это не главное на самом деле, просто ветка пошла с того, что если добавить «дополнительные критерии», то React с JSX выпадет из рейтинга. Под этими «дополнительными критериями» подразумевалось в том числе и SEO. Так вот это сильно ошибочное утверждение т.к. есть опять таки тот же riot.js и как я указывал несколько выше NextJS, позволяющие делать универсальные приложения одинаково работающие как на клиенте, так и на сервере. Да даже без них есть ряд сервисов кеширующих клиентский рендер (на базе Chrome).
Кто вам такую чушь сказал? Google как начал использовать робота основанного на Chrome так и использует, да некоторые фишки он не поддерживает т.к. на данный момент основан на Chrome 43. Но вся остальная поддержка JS и выливающихся остаётся.
А потом fetch запросы на клиенте упрощают жизнь в первую и непосредственную очередь для пользователей, а не роботов. А для роботов и пользователей без JS мы сами отрисовываем страницу.
React отрабатывает как на сервере так и на клиенте. Если клиент не поддерживает JS, нет проблем т.к. рендер дублируется на сервере. Если клиент поддерживает JS, при внутренних переходах он получает не всю страницу отрендеренную на сервере страницу, а только данные для рендера и уже клиент сам отрисовывает страницу, тем самым в том числе уменьшая объём передаваемых данных. Если кратко — это один и тот же код на React.
Правда ввиду невозможности наследования прозрачного цвета (тот же цвет, но с альфа каналом в нуле) и особенностей обработки градиентов в некоторых браузерах может получиться эффект перехода любого цвета в прозрачный чёрный.
Почему же по одной штуке? Возможно это будет открытием, но у РФ 3 национальных домена .su, .ru и.рф под управлением Координационного центра национального домена сети Интернет (по сути гос. компания).
Очередное открытие: существуют домены верхнего уровня .moscow и.москва под управлением Фонда содействия развитию технологий и инфраструктуры Интернета. Другой пример .nyc у Нью-Йорка.
А вам не достаточно 1572 домена верхнего уровня? По поводу регистраторов это уже никак не связано с количеством доменов верхнего уровня: регистраторы не равно администраторы, они лишь посредники.
Так же обращаю внимание, что ICANN работает с разными компаниями, так национальные домены разных стран управляются государственными компаниями соответствующих стран. Более того вообще говоря зарегистрировать домен верхнего уровня может любая компания, но если сможет доказать, что это действительно очень нужно. Например, Яндекс в прошлом году добились регистрации домена верхнего уровня (.yandex) для собственных нужд. И собственно Яндекс не единственные как-нибудь посмотрите вот этот список: https://www.iana.org/domains/root/db