Можно сделать по-разному
1) Видео (как на сайте)
2) Анимированный gif
3) Последовательно картинок или спрайты типа www.murlyka.com/wp-content/uploads/2011/03/2011-03...
4) Флеш (да да, еще жив)
5) 3Д моделирование (сложно, но можно) three.js
Александр: Вам необходимо работать именно во фрейме?
Может быть просто выводить вашу информацию в ..., а те кто его себе поставят пусть уже в своих стилях изменяют его вид как хотят.
Вам могут передать ссылку на что угодно, но вы же подключаете эту ссылку как таблицу стилей, к себе не загружаете, не исполняете на своем сервере. Я лично не вижу тут дыры в безопасности.
Вот ваша потенциальная уязвимость:
То есть внедрение javascript в ваш фрейм.
Но чем это грозит? Тем что javascript исполнится в браузере посетителя? Так этот скрипт могли подключить и без вашего виджета.
LoonTiG: Сначала вместо цикла foreach сделайте var_dump($images); и по результатам будет видно.
Если у вас прямо так вот и написано - то я вижу два закрывающих тэга и только один открывающий.
stcmd04236: Если все точки маршрута объединить в круг - будет очень большой круг и в его пределах можно будет очень сильно отклоняться от маршрута.
Я думаю сверять же надо не прям в реальном времени каждую секунду.
Если выбрать расстояние между контрольными точками, например, километр и сверять расстояния раз в 5-10 минут то можно уложиться.
Дополнительно можно попробовать "откладывать" заведомо дальние точки, то есть прикинуть максимальную скорость перемещения 300 км/ч (с запасом) то часть точек можно на ближайший час просто исключить из рассмотрения.
Марк Иваныч: Можно сделать обсуфкацию, шифр или хэш и фиксацию неверных данных переданных серверу. Как только переданы неверные данные - IP в бан (или IP + user_agent). Или просто с этих IP перестать принимать "топовые" результаты.
Марк Иваныч: Почему же, как раз ваш вариант. Сервер выдает id, random_seed, на основе которого строится ваш случайный игровой процесс, обратно на сервер передается запись движений и кликов мыши. Сервер исходя из выданного random_seed может смоделировать процесс и проверить корректность кликов. Но часто шкурка выделки не стоит, достаточно какого-нибудь хэша или шифрования и обфускации кода.
Dmitry: Тут как мне кажется фишка в том что "все работало, ничего не трогали". Или что-то менялось?
Если ничего не менялось - то надо смотреть железо, файловую систему, может быть что-то менялось на бекенде.
Dmitry: Перестает отвечать как - не соединяется, соединяется но молчит, соединяется но тормозит с ответом. По 80 и 443 порту поведение аналогичное? Есть ли что-то в error_log по этому поводу? Два подряд релоада приводят к такому же поведению? Нет ли чего странного в это время в top типа wait 100%.
Dmitry: Всегда считал что релоад должен "бесшовно" проходить. Попробуйте обратиться к разработчику. Я как-то давно обращался - отвечал оперативно и по делу. Думаю если поведение нетипичное - его должен заинтересовать ваш случай.
Kartoshka D: Обычно это или char (8 бит) или int (16 бит).
Можно, конечно, использовать столько, сколько нужно.
Все это особо актуально в ассемблере и микроконтроллерах, когда памяти мало и нужна простота хранения и проверки.
При таком способе хранения очень легко проверяются права - n AND 0x04 будет >0 (true) если право WRITE_ARTICLES присутствует.
Ну или например есть поле в БД типа char/int и нужно в нем сохранять права.
Чисто как вариант - распознавать на сервисе типа антигейта, а с пользователей взять небольшой взнос на это дело, должны понять, можно по желанию.
Самому решить проблему наверняка можно, возможно только времени отнимет, если схема сложная или часто меняется.
Глубоко в технологией recapcha v2 не знаком, по-этому что-то конкретное по решению посоветовать не могу.
