И как это связано с авторизацией? Проиндексировали-то содержимое страницы, на которой был код Яндекс.Метрики, а не той, ссылку на которую выслали на мыло с ключом авторизации. Т.е. если по ссылке из письма будет происходить переадресация на другую страницу, то ничего плохого не случится. Более того, если бы пользователь нашёл эту ссылку у себя в профиле, будучи авторизованным по обычной связке логин + пароль, это бы ничего не изменило.
Описанная по ссылке проблема в данном случае не актуальна. robots.txt нужно правильно составлять.
А Вы уверены, что этому человеку нужно изучать C++? На мой взгляд, это не совсем тот язык, с которого следует начинать знакомство с миром программирования.
Стоит отметить, что электронные версии этих книг распространяются автором совершенно бесплатно (см. ссылки тут). Правда, они оформлены как HTML странички.
Если Вам нужно сделать так, чтобы в строке было именно столько слешей, сколько их в исходнике, то используйте heredoc синтаксис. Правда, он несколько неудобен.
Сменить на какой-нибудь такой, в котором подчеркивание будет повыше (возможно, поможет смена размера шритфа). Таким образом, подсветка следующей строки не будет затирать его.
Пользователь вполне может состоять сразу в нескольких группах (и, зачастую, так оно и есть). Так что можно записать пользователя в группу www-data и дать все права на файлы не только владельцу файла, но и группе.
От того, что Вы запишете пользователя и www-data в произвольную группу толку будет не много — при создании файла / папки в качестве группы-владельца будет взята основная группа владельца.
Если скрипт можно просто получить получить в виде строки, то и с переопределением document.write париться не надо. Просто заменяем в строке document.write на имя собственной функции, выполняем и вуаля!
Вы понимаете, что обрезав хеш наполовину, Вы увеличите количество коллизий? Были у Вас 2 различных хеша с совпадающими первыми 64 битами, но совершенно различными остальными битами. И вот Вы взяли и отрезали вторую половину, где и были различия. Получили идентичные хеши.
XOR тоже не много толку дает — коллизия будет в случае, когда первый хеш записан в виде aa...aabb...bb, а второй — bb...bbaa...aa. И это еще цветочки по сравнению с тем, что будет на выходе (128 бит → 64 бита. На лицо уменьшение вариантов).
Вот, о чем я говорил: большинство статей на эту тему написаны в апреле-мае этого года, а на тот момент FormData не был реализован в хроме, из-за чего приходится отсылать сырые двоичные данные и читать их из входного потока (request.raw_post_data). То ли дело полноценный multipart, который идентичен обычной отправке файлов браузером.
Ну и стоит отметить, что такое поведение специфично для инлайновых (вне зависимости от того, являются они таковыми по своей природе (span, b, i, em, strong, etc) или из-за стилей (display:inline)) элементов.
Описанная по ссылке проблема в данном случае не актуальна. robots.txt нужно правильно составлять.