Jump to content

aplayer

Актив

  • Регистрация

  • В сети

Посмотреть профиль Find content

Posts posted by aplayer

    наверн кто-то хотел написать пост и не отправил его.

    Из новых функций что-то.

    Вроде еще была такая фишка как сначала можно написать пост, а потом зарегистрироваться. Может оттуда ноги растут.

    заметил такую нехорошую вещь.

    У гугла в имени пользователя ящика можно ставить любое количество точек между буквами, но письмо будет приходить только на один ящик.

    Например

    u.ser@gmail.com

    us.er@gmail.com

    u.s.e.r@gmail.com

    use.r@gmail.com

    если выслать письмо на любой из этих ящиков, то оно придет на user@gmail.com

    Этот способ позволяет спамеру не регистрировать новый ящик для того чтобы зарегистрировать множество аккаунтов на вашем форуме. Все письма активации будут сливаться в один ящик.

    Если в списке пользователей вы видите вот такие адреса

    1046435466_.png.e6e4934e1abb3380c0eb1611829deba5.png

    можете смело отправлять их бан.

    У других почтовиков действуют похожие правила на адреса ящиков. Всякие черточки кавычки итп тоже могу образовывать халявные псевдонимы ящиков без регистрации и смс.

     

     

     

    ·

    Edited by aplayer

    Я сейчас в раздумьях.

    Когда платежная система высылает уведомление о платеже надо сразу выдавать ей код 200. Проверено на личном опыте. Скрипту приемнику не стоит производить дальнейшую обработку платежа.

    И тут напрашивается два варианта.

    1. Сбросить уведомление в базу и а дальше его крон обработает. Но тут есть недостатки. Платеж будет обработан только в определенный промежуток времени. При отсутствии покупателей крон будет работать впустую. При избытке покупателей ему придется обрабатывать очень много входных данных, тоесть надо озаботиться о пакетной обработке.

    Например если промежуток простоя крона пришло 100 покупателей, то за одну итерацию обрабатывать только 10.

    2. При каждом уведомлении скрипт-приемник вызывает обработчик не дожидаясь завершения работы обработчика. При такой схеме крон не нужен и обработка будет проходить только когда требуется. В этой схеме приемник не ждет завершения обработки и выдает код 200 даже если обработчик завис.

    Кто нибудь может рассказать о подводных камнях этих способов или предложить другую схему?

    1 час назад, Desti сказал:

    У юмани такого вроде официально нет (не видел в доках), но они пишут, что будут слать, пока не получат 200. Я проверку сделал на дубль уведомления и один раз поймал такой.

    в обычных кнопках они высылают три уведомления пока не получат 200 второе через 10 минут третье через час. Дальше сам думай почему не отдаешь им 200.

    IPS движок тяжелый и твой скрипт если использует классы движка может думать слишком долго, либо хостер может техработы замутить, а у яндекса таймаут наверно секунд 5 всего. Повторные тоже ловил пару раз, и судя по всему оба по таймауту, тоесть скрипт отработал штатно и вернул код 200, но яндекс не дождался. Сейчас подумываю переделать на такую схему: сбрасывать уведомления в бд и выдавать 200 сразу, а дальше пусть крон разбирается.

    У киви где-то прочитал там и вовсе 2 секунды таймаут ожидания 200го кода. В ТП яндекса задавал вопрос о таймауте, не смогли ответить, не поняли вопроса.

    15 минут назад, Bayg сказал:

    Ты взялся за разработку? Складчина?

    Тут такая ситуация. Я предпочитаю не использовать системы с открытым исходным кодом. Поэтому мои разработки я никому не передам.

    Лично я немного в шоке от их системы.

    Особо в их АПИ меня убил вот этот пункт

    https://developer.qiwi.com/ru/p2p-payments/#notification

    2085550731_.png.c79df305340bd5e7ec9ef2a5f90cd00b.png

    Платежные системы так не должны работать. Особенно обратные уведомления о платеже.

    Сейчас репу чешу как бы организовать бизнес логику чтобы не продать один товар дважды, а может трижды, никто не знает сколько раз придет уведомление.

    12 часов назад, andros0789 сказал:

    Automation Rules)) решает все проблемы)

    если речь идет о плагинах, то у него по любому будут проблемы при обновлениях движка.

    Лучше всего когда функционал поддерживается из коробки

    В phpbb очень хорошо реализованы маски прав доступа.

    То-есть я могу создать группу которая понизит пользователя в правах или наоборот повысит. Могу одному конкретному пользователю назначать права. Можно назначать отдельным пользователям права на отдельные форумы.

    В ips как таковой системы прав доступа не существует. Дополнительные группы могут права только расширять, но не понижать.

    Автоцензор phpbb рендерит посты при просмотре темы. То-есть если пользователь написал непристойное слово сокращенно и завуалированно, то после добавления в автоцензор при просмотре темы это слово будет подвергнуто цензуре.

    В ips цензура работает только при публикации поста. Это значит надо внести слово в автоцензор, а потом отредактировать пост.

    С дисками возникает много нюансов.

    Например SSD или HDD

    На виртуальном сервере или хостинге SSD это пустой звук. Потому-что там на одном физическом диске сидит черт знает сколько клиентов и каждый тащит его на себя. Тут вам дают всего лишь кусочек диска и скорость доступа для вас не максимальна.

    На выделенном не виртуальном сервер весь диск полностью ваш и вы можете иметь сколь угодно физических дисков. Тут уже все зависит от того насколько вы его нагружаете. Но не исключено, что отдельный SSD вполне без проблем подойдет для любых нужд.

    Но Redis все же наверняка выигрывает даже перед M2 дисками. Насколько я знаю еще нет устройств хранения быстрее оперативной памяти.

    Я давненько заметил. Если сайт на шаред хостинге, то вас оттуда погонят при любой жалобе. Да и как клиент вы для них никто. Им проще избавиться от сторублевого, чем иметь проблем на миллионы.

    А вот у серверов там какая-то другая юридическая модель при котрой хостеру вообще пофиг чем вы там занимаетесь. Это примерно как продавцу ножей абсолютно не важно что вы с ним будете делать. Резать хлеб или людей ему вообще без разницы.

    Я считаю что сам движок туговат.

    Я проводил эксперименты. На пустом сервере создавал тестовый форум и прогонял его через гугл и яндекс тестировщики. Везде оно и то же. Сайт медленный, надо оптимизировать итп.

    Хорошая скорость только у phpbb и джумлы 10летней давности. У которых ничего скриптового и CSS не более 100 строк. Сейчас все эти фронтенды скриптами напичканы по самое не балуй. CSS сотни тысяч классов.

    Самый простой пример это знаменитый рутрекер. Движок середины 2000 годов. Убогий дизайн. Ни скриптов ни интерактивных элементов. Миллионы посетителей в сутки. Сайт полностью рендерится за доли секунды через любой самый убогий прокси-сервер. Переведи движок на IPS и у них сервер сразу ляжет.

     

    Такая мошенническая схема работает обычно на взломанных аккаунтах в соцсетях. После чего ваши родственники, и люди которым мы доверяем начинают просить у нас денег.

    Но у кого хватило ума взламывать акки на мафии? Вконтакт уже сдулся чтоли?

    ipb323 

    Я тогда не понимаю про какие записи ты говоришь.

    Ни у форумов ни у блогов ни у страниц я не нашел этого параметра.

    У всех у них есть различные иконки, картинки, но в REST я этого параметра не вижу.