В приведенном коде авторизации вы используете Implicit flow. Иными словами это локальная авторизация приложения. Access_token который вы получили, хранится у вас в браузере и сервер или кто угодно еще не имеют к нему доступа. При попытке повторной авторизации вы инициируете создание ЕЩЕ одного токена.
Так как у вас в статье нет ни какой подробной информации о последующем доступе к странице пользователя, уверен, что дальше базовых прав, которые вы дали токену при его создании, вы не получите. Это основной принцип OAuth.
Не вводите людей в заблуждение. HTTPS это тот же HTTP, но работающий внутри шифрованного канала SSL и TLS. Все параметры, передаваемые через query string так же шифруются. Для реализации TLS используется расширение SNI, позволяющее передавать имя хоста в открытом виде, для решения проблемы с ip и сертификатами.
Но! передавать чувствительные данные через query string чревато тем, что они могут оседать в логах сервера, и все!
На сколько мне известно, основное отличие FastCGI от CGI в том, что первый держит пул процессов и направляет данные запроса на обработку. Во втором процесс запускается при каждом запросе, что существенно снижает производительность. И первый вместо STDIN использует сокеты.
В остальном если отличия и есть, то они минимальны.
Когда первый раз увидел цены, очень скептически отнесся. Но попробовал. Теперь активно использую. Техподдержка отвечает не дольше 5 минут, что считаю осень быстрым откликом.
Сбоев не было. Все комфортно.
Из субъективных минусов – устаревший вид панели управления ресурсами.
Любая капча начинается с инициализации на целевой странице. Затем отдается картинка. Потом следует запрос, верифицирующий переданное значение капчи и параметра ее инициализирующее. В зависимости от сложности капчи она либо скармливается подпрограмме OCR и получается ее расшифрованное значение, либо отдается антигейту и подобным. Других вариантов нет.
На SlimmerJS вы точно так же получите картинку капчи и придете к тому же выбору: «а что же делать дальше?»
Рекоммендую при парсинге просто не допускать ее появления, укладываясь в «разрешенные» (антиспам) лимиты. Они либо вычисляются имперически, либо читаются на специализированных ресурсах.
Я с вами согласен, но хочу добавить, что все зависит от ситуации, потому что когда надо получать данные с множества сайтов делая по 10000 запросов единовременно, SlimmerJS, как и PhantomJS потребляют слишком много ресурсов. Для одного потока конечно нормально. А на счет изменений в верстке, DOM структура так же легко может измениться. Мне PhantomJS нравится и я его использовал регулярно. Так что могу с уверенностью сказать, что все зависит от задачи, но 95% случаев решается оптимальнее на Perl
Так как у вас в статье нет ни какой подробной информации о последующем доступе к странице пользователя, уверен, что дальше базовых прав, которые вы дали токену при его создании, вы не получите. Это основной принцип OAuth.
OAuth для авторизации сторонних приложений и авторизацию/разлогин самого сайта.
Фактически сайт ВК это такое же приложение и вы разлогинитесь в нем, вместо своего.
Чтобы сделать разлогин для токена вам нужно использовать методы API с указанием токена, если такие там предусмотрены.
Но! передавать чувствительные данные через query string чревато тем, что они могут оседать в логах сервера, и все!
В остальном если отличия и есть, то они минимальны.
В добавок CGI это уже прошлый век.
Сбоев не было. Все комфортно.
Из субъективных минусов – устаревший вид панели управления ресурсами.
На SlimmerJS вы точно так же получите картинку капчи и придете к тому же выбору: «а что же делать дальше?»
Рекоммендую при парсинге просто не допускать ее появления, укладываясь в «разрешенные» (антиспам) лимиты. Они либо вычисляются имперически, либо читаются на специализированных ресурсах.
Речь вообще про ШАБЛОННЫЕ интернет-магазины и СТРУКТУРИРОВАННЫЕ данные