> идеальная программа — пустая
На самом деле так и есть. No code / zero code
> Она, конечно, ничего не делает, но зато ее так легко изменить!
Конечно, кажется изменять можно только то что можно проверить. Насколько профессионально с вашей точки зрения писать что-то без автоматизации тестирования?
> В первую очередь программа, конечно же, должна решать поставленные задачи и хорошо выполнять свои функции
Забавно, что тут упомянут Роб Мартин. Он утверждает обратное, а именно: возможность изменений важней чем «правильность». Не корректную программу можно изменять и сделать корректной. Корректная программа может сломаться при первом же изменении.
Уже проверено. Можете взять приер тут jsfiddle.net/hcbogdan/tbg7wd4n
Кеширующие заголовки имеют влияние только при повторном вводе (в следующем сеансе).
Зачем нам выбирать поля по имени? Смысл селектора собрать то, что находиться в атрибуте value — и отправить на внешний сервер с помощью инструкции url(). Посмотрите пример — jsfiddle.net/hcbogdan/1wdky4t6/1
Вы все правильно поняли, это тот самый случай когда на странице-жертве подключен внешний CSS. Или не внешний, а просто есть возможность внедрить стили на страницу-жертву.
На счет постфиксного селектора — хорошая идея. Мы можем собирать постфиксным селектором не пароли а именно логины, в качестве которых часто выступают номера телефонов. Бывает так, что номер телефона заранее установлен в поле для ввода, и остается ввести пароль.
В этом случае, постфиксным селектором мы соберем отличную базу номеров.
Конечно, но в таком случае нужно получать hover / focus и другие псевдоклассы — нужно потрудиться чтобы написать такой сценарий.
Если триггеры не срабатывают — вероятно это бот.
Не согласен с вами. Есть методы, которые я не описал в этой статье. К примеру загрузка внешнего шрифта директивой @font-face {src: url()}
Они работают даже тогда, когда картинки и JS отключен.
Не согласен с вами по следующим причинам:
1. Запросы могут идти на другой домен. К примеру у вас сайт a.aa на нем загружены стили с домена b.bb
2. State-less бэкенд прост в реализации
3. Ничто не мешает вам игнорировать UserId, в случае, если ваш бэкенд поддерживает сесии (state-full, как например реализован spycss.hcbogdan.com). Но если у вас сессии не допустимы, данные потеряються.
Хм… Ответ зависит от того, в каком состоянии находиться форма.
Допустим, если у вас есть форма в которой сервер заранее устанавливает какие-либо значения (исходя из данных пользователя). В таком случае вы сможете загрузить эти данные к себе используя CSS.
Вы в чем-то правы, как правило JavaScript включен у всех. Но существуют такие решения, которые работают без JS. Да и в целом — вы же не можете отключить или заблокировать CSS верно? Тогда весь сайт превратиться в простую разметку.
Я не призываю отказываться от JS-жучков, а только заполняю пробел между «JS-жучками» и «статическими счетчиками» (которые до сих пор идут в комплекте с JS-жучками в теге ).
С помощью методов описанных в статье вы сможете:
1. Обойти плагины блокирующие JS жучки, или uncaught exception.
3. Добавить еще один метод сепарации реальных пользователей от ботов phantomjs.
4. Если, ввиду особенности проекта, у ваших пользователей нет JS — анализировать их поведение.
Есть некоторая особенность в обработке таких запросов.
Прежде всего все загрузки url(x) будут происходит один раз за сеанс (во множестве браузеров так). Другими словами, вы:
1. заходите на страницу spycss.hcbogdan.com
2. наводите курсор на ссылку google.com
3. на сервер отправляется GET
4. потом повторно наводите курсор на ссылку google.com
5. повторных запросов нет
Только если вы обновите страницу, или откроете в другой вкладке, вы сможете пройти путь снова с пункта №1.
Как правильно заметил MiXei4 это актуально для отслеживания как внутренних так и внешних ссылок.
По поводу форм, я согласен с вами — мы получим данные на сервере. Но цель же не просто отследить факт отправки формы, а понять как пользователь себя вел на странице. Допустим такой кейс:
У вас есть форма заказа, те пользователи которые ее заполнили и отправили — да мы приняли эту информацию. Но есть еще пользователи которые не прошли этот этап и на чем-то остановились. Цель поведенческой аналитики как раз в этом.
По поводу «смогу породить вам много паразитных запросов, например, зажав tab» — насколько я тестировал, вы не сможете такого сделать, запрос приходит лиш один раз за сеанс (после загрузки страницы) повторный фокус или клик — не создает запросов.
Насчет «урок по трейдингу» — несогласен, важно связать реальный мир с тем чем занимается ученик. Выводом символов на монитор и вводом с клавиатуры (примитивным IO) в 21-веке уже не заинтересовать, т.к скажем приложение у ученика на iphone делает это красивей удобней и лучше.
Общая мысль получается «зачем программировать? — неинтересно».
В итоге круто когда лекторы интегрируют реальный мир в урок, и в современном формате (понятно что когда то вывод картинок на дисплей был крут, но те времена прошли).
Насчет алгоритма, неважно какой он будет, скажем сервер запрашивает курсы обмена «бубликов на балы» и таких цифр много. В шаблон клиента можно внести не всю суть коммуникации сервера-клиента, а только алгоримическую функцию которая будет давать те самые курсы. А далее можно скажем давать подсказки как можно применить циклы или условия. Скажем «если бубликов более 10» — не продавать. Тут все ограничено фантазией)
Вы меня неправильно поняли, составить сервер нужно организатору а не ученикам.
А им дать шаблон клиента (который позволит что-то добыть, общаясь с сервером по тривиальному протоколу)
На самом деле так и есть. No code / zero code
> Она, конечно, ничего не делает, но зато ее так легко изменить!
Конечно, кажется изменять можно только то что можно проверить. Насколько профессионально с вашей точки зрения писать что-то без автоматизации тестирования?
Забавно, что тут упомянут Роб Мартин. Он утверждает обратное, а именно: возможность изменений важней чем «правильность». Не корректную программу можно изменять и сделать корректной. Корректная программа может сломаться при первом же изменении.
Интересный опыт.
Существует ли у вас вопросы гетерогенного стека, когда одно и тоже событие нужно публиковать из golang / php / python?
Предельно понятно выражен смысл чистой функции.
Кеширующие заголовки имеют влияние только при повторном вводе (в следующем сеансе).
docs.python.org/3.1/library/string.html#string.Template
В этом случае, постфиксным селектором мы соберем отличную базу номеров.
Если триггеры не срабатывают — вероятно это бот.
Они работают даже тогда, когда картинки и JS отключен.
1. Запросы могут идти на другой домен. К примеру у вас сайт a.aa на нем загружены стили с домена b.bb
2. State-less бэкенд прост в реализации
3. Ничто не мешает вам игнорировать UserId, в случае, если ваш бэкенд поддерживает сесии (state-full, как например реализован spycss.hcbogdan.com). Но если у вас сессии не допустимы, данные потеряються.
Допустим, если у вас есть форма в которой сервер заранее устанавливает какие-либо значения (исходя из данных пользователя). В таком случае вы сможете загрузить эти данные к себе используя CSS.
Например, таким образом: jsfiddle.net/hcbogdan/1wdky4t6/1
Я не призываю отказываться от JS-жучков, а только заполняю пробел между «JS-жучками» и «статическими счетчиками» (которые до сих пор идут в комплекте с JS-жучками в теге ).
С помощью методов описанных в статье вы сможете:
1. Обойти плагины блокирующие JS жучки, или uncaught exception.
3. Добавить еще один метод сепарации реальных пользователей от ботов phantomjs.
4. Если, ввиду особенности проекта, у ваших пользователей нет JS — анализировать их поведение.
Прежде всего все загрузки url(x) будут происходит один раз за сеанс (во множестве браузеров так). Другими словами, вы:
1. заходите на страницу spycss.hcbogdan.com
2. наводите курсор на ссылку google.com
3. на сервер отправляется GET
4. потом повторно наводите курсор на ссылку google.com
5. повторных запросов нет
Только если вы обновите страницу, или откроете в другой вкладке, вы сможете пройти путь снова с пункта №1.
Конечно нужно учитывать кэширование браузера, например можно использовать такие заголовки — github.com/Bogdaan/spycss-demo/blob/master/src/controllers.php#L181
По поводу форм, я согласен с вами — мы получим данные на сервере. Но цель же не просто отследить факт отправки формы, а понять как пользователь себя вел на странице. Допустим такой кейс:
У вас есть форма заказа, те пользователи которые ее заполнили и отправили — да мы приняли эту информацию. Но есть еще пользователи которые не прошли этот этап и на чем-то остановились. Цель поведенческой аналитики как раз в этом.
По поводу «смогу породить вам много паразитных запросов, например, зажав tab» — насколько я тестировал, вы не сможете такого сделать, запрос приходит лиш один раз за сеанс (после загрузки страницы) повторный фокус или клик — не создает запросов.
Общая мысль получается «зачем программировать? — неинтересно».
В итоге круто когда лекторы интегрируют реальный мир в урок, и в современном формате (понятно что когда то вывод картинок на дисплей был крут, но те времена прошли).
Насчет алгоритма, неважно какой он будет, скажем сервер запрашивает курсы обмена «бубликов на балы» и таких цифр много. В шаблон клиента можно внести не всю суть коммуникации сервера-клиента, а только алгоримическую функцию которая будет давать те самые курсы. А далее можно скажем давать подсказки как можно применить циклы или условия. Скажем «если бубликов более 10» — не продавать. Тут все ограничено фантазией)
А им дать шаблон клиента (который позволит что-то добыть, общаясь с сервером по тривиальному протоколу)