Comments 58
В нашем случае в базе конкурса для каждого фотоальбома хранятся значения счетчиков по каждой сети и суммарный рейтинг. Поэтому после получения данных от социальных сетей, они сравниваются с данными хранимыми в базе сайта и при различии хотя бы одного значения отправляются ajax-ом для обновления.Т.е. любой пользователь, немного владеющий js, может отправить на ваш сервер «обновленные» данные с угодным ему количеством голосов?
На этот случай, в запросе отправляется также проверочный хеш, который собственно и проверяется перед записью в базу.
Что мешает получить кеш со страницы и отправить запрос с ним?
не очень понял вопрос…
Хеш, который вы проверяете перед записью в базу — он отправляется вашим скриптом со страницы голосования. Явоскриптом отправляется. Значит я могу его получить и отправить с ним нужные мне данные.
Он уникален каждую минуту. Генерируется php и передается в js. При формировании хеша используется hh:mm:yyyy, по моему, подзабыл, как-то. А принимающий скрипт формирует свой хеш с текущим временем. Вот такой костыль придумали. Может есть более изящное решение?
в hh:mm:yyyy очепятка, в общем используется время до минуты и дата.
Не знаю как насчет изящнее, но, думаю, получать счетчики от соц. сетей на сервере, а не на клиенте, было бы как минимум надежнее. Т.е. клиент шлет запрос «обновись» серверу, а тот сам снимает показатели счетчиков и обновляет значения в базе. Да, и как себя ведет Ваш «костыль», при смене минуты? Т.е. юзер загрузил страницу (со своим уникальным хэшем, зависящим от времени вплоть до минуты), затем выпил кофе и через пять минут жмякнул like. В таком случае на сервере уже будет генерироваться новый хэш и проверка не пройдет?
Логика такая:
— формируется хеш и присваивается глобальной переменной js прямо на странице в секции script. Что-то вроде этого:
||script||data = {
uniq_string = '<?=хеш?>',
fb_count_in_db = <?=?>,
vk_count_in_db = <?=?>,
tw_count_in_db = <?=?>}||/script||
— по событию ready основной скрипт получает данные от социалок сравнивает их со значениями из бд и при различии хотя бы одного отправляет ajax-ом вместе с uniq_string.
— формируется хеш и присваивается глобальной переменной js прямо на странице в секции script. Что-то вроде этого:
||script||data = {
uniq_string = '<?=хеш?>',
fb_count_in_db = <?=?>,
vk_count_in_db = <?=?>,
tw_count_in_db = <?=?>}||/script||
— по событию ready основной скрипт получает данные от социалок сравнивает их со значениями из бд и при различии хотя бы одного отправляет ajax-ом вместе с uniq_string.
Очень надеюсь, что я все еще не до конца Вас понял. В противном случае выходит, утрируя, что вы любому посетителю высылаете login-форму с заполненным полем пароля (пусть и уникальным и действительным лишь в течение минуты значением) и рассчитываете, что лишь добропорядочный пользователь нажмет кнопку «login». Проблема в том, что Вы получаете данные для формирования рейтинга от социальных сетей через клиента-посредника, проверяя подлинность данных по ключу (хэшу), который сами же только что выдали этому посреднику. Если же я все-таки правильно понял, то думаю, стоит пренебречь «привлекательностью» и все же перенести эту часть логики в укромное место на сервере.
Т.е. клиент шлет запрос «обновись» серверу, а тот сам снимает показатели счетчиков и обновляет значения в базе.
А какое принципиальное отличие от того чтобы сразу клиенту данные отправить?
Если получать на сервере данные то писать их сразу в базу и выводить.
т. е. серверу отправить
В php можно просто использовать curl и опрашивать сервера соцсетей раз в 5 минут по cron'у и записывать ответы в базу. Страница будет загружаться быстрее у пользователей. Если сервер мощный, можно раз в минуту опрашивать.
Если важно отображать результат без задержек — оставьте js код, просто не отправляйте обновлённые данные с клиента на сервер.
Если важно отображать результат без задержек — оставьте js код, просто не отправляйте обновлённые данные с клиента на сервер.
Вот как раз и думали, что могут возникнуть глюки из-за ограничений на частоту обращений к сервису от сервера и на клиенте не всегда будет актуальная информация. Но похоже вы правы и обновление данных в базе нужно curl-ом делать.
Меня пугает ситуация с большим количество фотоальбомов (url-ов). Представьте у вас 10к страниц, если по крону опрашивать сервисы социалок по всем страницам, то у вас получится 30к запросов curl-ом. А если их будет еще больше?
А если организовать что-то вроде списка заданий. Т.е. клиент сообщает серверному скрипту url по которому необходимо обновить данные из социалок, на серваке создается задание и ставится в очередь. Перед добавлением в очередь:
— исключаем образование клонов url-ов
— регуляркой проверяем url на соответсвие с реальными url-ами фотоальбомов
— тем же curl смотрим заголовок на отсутсвие 404 ошибки
Также думаю можно сделать запрет на добавление в очередь не чаще выбранного времени.
По крону запускать скрипт, который:
— получает задания из очереди
— выполняет свое грязное дело
— очищает очередь
Таким образом на клиенте с помощью js всегда актуальные значения счетчиков, а на сервере исключается большое количество обращений к социалкам.
Кто что думает по этому поводу?
А если организовать что-то вроде списка заданий. Т.е. клиент сообщает серверному скрипту url по которому необходимо обновить данные из социалок, на серваке создается задание и ставится в очередь. Перед добавлением в очередь:
— исключаем образование клонов url-ов
— регуляркой проверяем url на соответсвие с реальными url-ами фотоальбомов
— тем же curl смотрим заголовок на отсутсвие 404 ошибки
Также думаю можно сделать запрет на добавление в очередь не чаще выбранного времени.
По крону запускать скрипт, который:
— получает задания из очереди
— выполняет свое грязное дело
— очищает очередь
Таким образом на клиенте с помощью js всегда актуальные значения счетчиков, а на сервере исключается большое количество обращений к социалкам.
Кто что думает по этому поводу?
Он имеет в виду то, что запрос, будь он с хешем или без выполняется на клиентской стороне и посмотрев в том же firebug, какой запрос отправляется, можно отправить его самостоятельно.
Кста у фейсбука можно(и нужно) юрать данные отсюда graph.facebook.com/?ids=http://www.imdb.com/title/tt0117500/
Вообще там много вкусняшек developers.facebook.com/docs/reference/api/, как бы гугл не ругался на закрытость фейсбука
Вообще там много вкусняшек developers.facebook.com/docs/reference/api/, как бы гугл не ругался на закрытость фейсбука
В будущем для многих это будет полезная вещь, а возможно уже сейчас)
это уже сейчас очень полезно! Спасибо!
Как раз встала подобная задача, спасибо. А аналогичные возможности Одноклассников и Моего Мира исследовали?
Поправьте, «безопастный».
А вещь очень нужная, плюсую.
А вещь очень нужная, плюсую.
Статья прекрасна, автор молодец!
«share» подвержен накрутке
точней так — «share» контакта может быть накручен одним аккаунтом
Да это известно. Если url размещенный с помощью share удалить, то счетчик не уменьшается. Соответсвенно если повторно разместить, то счетчик увеличится. Но это не изменило желание заказчика использовать share потому как с его помощью постится не просто ссылка, а анонс, что более наглядно. А сам рейтинг носит заманушный характер. Победителя будет выбирать жюри.
Поправьте в коде «Вконтакте будет искать:» — мне почему-то кажется, что br там не к месту.
А в правилах использования API разве не сказано, что нельзя изменять внешний вид кнопок?
Я не утверждаю, а спрашиваю. Просто, когда тоже нужно было немного стилизовать кнопки, менеджеры сказали что менять нельзя, мол в правилах где-то откопали пункт на этот счет.
Я не утверждаю, а спрашиваю. Просто, когда тоже нужно было немного стилизовать кнопки, менеджеры сказали что менять нельзя, мол в правилах где-то откопали пункт на этот счет.
Вопрос актуальный, как раз эту часть документации мы пропустили. В целом наши кнопки очень похожи на оригинальные. Да кнопки картинки уже встречал и на сравнительно крупных проектах.
Вопрос актуальный, как раз эту часть документации мы пропустили. В целом наши кнопки очень похожи на оригинальные. Да кнопки картинки уже встречал и на сравнительно крупных проектах.
Изначально счетчик в Share ВКонтакте не рассчитан на конкурсы — он считает количество сохранений, а не уникальных пользователей. Для конкурсной основы гораздо лучше и правильнее использовать виджет «Мне Нравится» — он считает уникальных пользователей и его гораздо сложнее накрутить.
Было бы не плохо готовый архивчик с примером, думаю многие были бы благодарны
А для чего они разного размера? Или так задумано?
Спасибо всем за комменты, передумали использовать подобную механику голосования :)
Sign up to leave a comment.
Кастомные социальные кнопки