Все верно. Читайте политики безопасности касательно кроссдомена. Но вы так же правы, вариант есть. Вам просто нужно найти на фейсбуке xss, причем на том же домене, который отгружает фрейм комментариев (или уровня выше, но тогда нужно будет ещё повозится) и внедрить свой код, которым вы уже сделаете инсайд стилей.
Соответственно если у юзера найдена метка (и она есть в базе) - юзер не уникален. Если нарушена одна из проверок пересылки параметров/данных/валидности токенов - по возможности показываем баннер/делаем клик, но деньги не списываем и логируем накрутку. Если у юзера не найдена метка и ошибок в процессе показа баннера нет то пытаемся найти его в базе по IP, если находим - вешаем ему обратно все метки (кошмар, я знаю, пользователи за nat, бла бла бла, но это последняя грань защиты, что без неё делать я не знаю).
В данный момент:
- проверяется факт загрузки всех файлов обеспечивающих показ баннера
- проверяется время между отображением баннера и переходом по нему, время загрузки баннера
- каждый юзер получает при первом обращении метку на сутки и заносится в базу, метка эта раскладывается юзеру в куку, в локал, глобал, sql и dom стораджи, в etag
- проверяется отсутствие хедеров HTTP_VIA, HTTP_CLIENT_IP, HTTP_X_REAL_IP, HTTP_X_FORWARDED_FOR
- НЕ проверяется резолвинг айпишника так как это долго
- в фрейме, котором отображается баннер сверяются top.location в скрипте с HTTP_REFERER в php (малополезно так как для https > http не пашет)
- в конце осуществления показа баннера юзеру выдается шифрованный по ключу массив данных показа в виде токена, соответственно каждый токен уникален (в пределах погршности) и является одноразовым способом кликнуть. Тобеж не эмулировав показ клик не сделать.
- при клике все данные зашифрованные в токене снова достаются и повторно сверяются
Задача именно понять принципы работы движка и построения графики. Не кидайте ссылки на готовые движки, кидайте ссылки на маны о том КАК работают движки и как разработать свой с нуля.
Круто, поставил в вашем примере вместо 10 ректов 10000. Никаких тормозов! Нет, я понимал конечно что на канвасе быстрее, но чтобы так… В общем и целом я и так планировал написать следующий вариант именно на канвасе, теперь уже точно. Но есть ли вариант решения на html? Уж больно интересно на сколько возможно заоптимизировать мой подход.
У меня вроде как не массовая рассылка. + этот хедер обычно пора ставить когда гугл жалуется (error 550-5.7.1) на лавину писем с моего айпи. А гугл не жалуется никак…
Увы безрезультатно — все равно в спаме.
Вот текст ошибки гугла: Why is this message in Spam? It's similar to messages that were detected by our spam filters.
Но хоть ты тресни, я не знаю что в тексте ему не нравится.
Юзеры письма в спам не могли отправлять так как я вообще только тестировать начал отправку.
Я хз где вы это смотрели но у домена bannerd.ru с которого я посылаю писмьа записи вот такие: spf2.0/mfrom,pra a mx ip4:94.242.7.157 ~all v=spf1 a mx ip4:94.242.7.157 ~all
spf запись говорит о том что домен в поле from письма разрешает мейлсерверу, указанному в spf посылать письма отс воего имени
Я много читал по поводу того, какой должен быть указан PTR — все пишут что именно мейлсервера а не домена в поле from так как мейл сервер может посылать почту с многих доменов. Ему делегируется это право с помощью MX записи в dns домена. Так что дело не в этом + я проверял это уже =)
У меня организована примерно такая же система, sid храниться по возможности в domStorage, localStorage, sessionStorage, openDatabase, cookie, e-tag. Но все это можно почистить без особых проблем.
Спасибо, но разве это получаются third part куки? Вроде как я для своего сайта их вешаю. Если да — то я от кук вообще откажусь в таком случае так как рано или поздно все баннеры начнут их подрезать.
