Вы о чём? Пользователь быстро поймёт, что у него shadow ban (а он это понять может легко, например, зайдя анонимно или с проверочного мульта). И как только он узнал, что так на сайте можно сделать, эта тактика против него перестанет работать окончательно.
Борьба с нежелательными регистрациями пользователей - это всегда компромисс между надёжностью защиты и неудобствами для пользователя.
Самое простое решение - перенести проблему множественной регистрации на тех, кто умеет с этим бороться лучше: на сотовых операторов (авторизация требует телефона и кода из SMS) или соцсети. Конечно, это не суперзащита, но заводить новый номер телефона или аккаунт в соцсети после каждого бана заметно сложнее, чем новую почту.
Можно заранее банить сети TOR и даже просто сети известных датацентров. Некоторые сайты так и делают. Да, это тоже не суперзащита, но опять же - сузит манёвренность нарушителя.
Можно сделать ограничения на начальном этапе. Например, первые три дня или первые 15 сообщений пользователь видит лишь часть разделов авторизованной области сайта, лимитирован в числе отправляемых сообщений в сутки итд. Усложнит регистрацию мультов - их придётся "прогревать", а за это время их можно будет обнаруживать и банить.
Ну а вообще если это вопрос общетеоретического характера, то можно давать общие советы, а если борьба с конкретным пользователем, то советы могут быть более целенаправленны. И, конечно, зависит от специфики сайта. То, что годится для форума, может не очень пригодиться для доски объявлений или сайта онлайн-курсов.
AshBlade, в таком случае будет дешевле взять виртуалку и на ней поднять свой докер, чем переплачивать за managed cloud и ещё тратить кучу времени на разбирательства как он работает.
LAG_LAGbI4, например, Thunderbird. Но там тоже, разумеется, бывают сложности, Например, если закончилось место на диске, можно получить повторную синхронизацию всех гигабайт ящика, что не очень быстро. А большие письма с приличной html-разметкой могут вызвать жуткое вытекание памяти, правда, это обычно экзотика и вряд ли случится на парактике (из моего опыта: таблица на ~1000 строк привела вытеканию более 6 Гб памяти, после чего пришёл OOM killer и убил thunderbird; аутлук при этом не очень быстро, но всё же успешно это рендерит и показывает).
С разработкой Thunderbird сейчас есть сложности, так как Mozilla от его финансирования отказалась. Будем надеяться, что он будет жить, тем более что протоколы и стандарты в почте довольно стабильны и не очень часто меняются.
Зачем так сложно? Есть функция os.system, которая делает как раз то, что нужно.
Изначальная попытка была неудачной, потому что исполняемого программного файла с именем "net start MySQL80" (да-да, именно так, с пробелами) не сущетвует.
Однажды ехали мы по улице, пересекающий проспект. И там что-то повредилось в светофоре, две его секции, смотрящие в два разных направления, вывернулись так, что показывали противоположные показания нашему направлению. Но естественно это не вызвало проблем, ибо водители прекрсно понимали, какой из светофоров показывает правильное. А что бы сделал автопилот?
Я тогда задумался о том, что если введут реальное автопилотирование автомобилей, то оно не будет полагаться на обычные светофоры, знаки и разметку в силу их машинно-распознаваемого несовершенства. Ну как в той картинке с Mapilary, который распознал знак стоянке в букве P синего знака населённого пункта. Вместо этого будут какие-то другие средства: NFC-метки, специальные QR-коды, радиодатчики, глобальные идентификаторы улиц и направлений, криптография с доверительными отношениями правильным ключа для авторизованного сообщения верной инфы. Ну, погромисты поймуть, я думаю.
А все эти приколы, когда дорожный знак распознаётся с рекламного щита или светофор с рисунка на детской площадке - это ж хрень какая-то.
Что касается упомянутого отбойника, если автопилот его "видит", то может оперативно принять решение о необходимости остановки безальтернативно "нейросетевому" мнению о дорожной ситуации. Как это бы сделал и настоящий водитель. Собственно, в нейросети должны быть отработаны и такие ситуации и она должна уметь их избегать. Хотя тут же возникла мысль: а нет ли у автопилота слепых пятен, в которые можно завести "невидимое" препятствие? Типа отбойника на правильной высоте, например.
У меня был Samsung A6 2018 года. В принципе, производитель выпустил на него два обновления мажорной версии Android, и он бы меня вполне устраивал. Но не нравилось две вещи. Во-первыйх, очень мало по нынешним временам встроенной памяти - сейчас очень много приложений и игрушек считает, что занять на телефоне гигабайты это норм. Во-вторых, через 2 года использования что-то случилось с камерой и она начала половину кадра снимать очень размыто. Поэтому купил примерно такой же модели, но свежего года. Тот проработал 4 года (и в принципе ещё работает), а этот я рассчитываю проживёт не меньше.
Также у меня есть старый планшет Galaxy Tab 2014 года со стилусом. У него сломано гнездо для сим-карты, поэтому он вынужденно превратился в Wi-Fi only. Я недавно достал его, прошил сборкой LineageOS с Android 10 и он вполне себе работает. Не очень быстро грузится и по отзывам у сборки бывают проблемы с внезапной перезагрузкой устройства, но в целом вполне работоспособный, и даже стилус работает нормально.
Тынай Бакасов, потому что при нажатии inline-кнопки никакого сообщения от лица пользователя не отправляется. А при обычной кнопке - отправляется (и в истории сообщений это видно).
igor 9577, сборки типа "9in1" не оригинальны, сборка чего-либо из них - это лотерея. Фиг его знает, что и как там сделал "пересборщик". Надо искать именно оригинальные образы от Microsoft.
Берём ассиметричное шифрование. Держим приватный ключ на сервере, а публичный зашиваем в программу. Ключ представляет из себя шифрованный приватным ключом текст, содержащий инфу о лицензии. Например, json с полями "номер лицензии", "срок протухания". При запуске проверять срок протухания и сравнивать с текущим временем. В принципе, пользователь может переводить часики, но это сильно неудобно. Особенно если программа представляет возможность работы по сети и коммуникации с другими людьми (а по описанию похоже на то, что так и есть).
Можно в лицензию записывать характеристики системы, на которой запущено приложение. А также все ограничения. Поменять их пользователь всё равно не сможет: даже если ему удастся выдрать открытый ключ, при изменении содержимого лицензии он не сможет её зашифровать приватным ключом).
Можно выдавать короткоживущие лицензии, которые обновлять по сети время от времени. При этом можно сделать примерно как в jwt, где есть долгоживущий refresh token и относительно недолго живущий access token.
Да чего уж там, можно просто при запуске приложения обращаться на сервер за криптографически валидным ответом (шифруем открытым ключём запрос и только по валидному ответу запускаем программу).
Можно вынести функционал проверки лицензии в launcher, который будет запускать основную программу только после проверки, что она не изменилась на диске, передавая ей какие-то правильные параметры, криптографически связанные, например, с регулярно изменяемым содержимым какого-нить файла. И дальше развивать идею: сделать "античит", который будет проверять, что программу не пытаются ломать.
В общем, можно очень много навертеть при больщом желании...
Но часто не нужно никакой сильно сложной и замороченной проверки. Софт немассового применения - тем более для бизнеса - обычно покупают вместе с поддержкой. Особенно критичный, простой которого крайне нежелателен. Ну потому что фиг его знает как он будет глючить. А если заглючит - то не будет миллиона комментариев на хабре и stackoverflow о том, как это решать. Чаще всего достаточно просто проверки зашифрованной лицензии, можно даже запрос на сервер не делать (тем более во многих сурьёхных фирмах сторонний софт "in-house" запускают в коонтуре без доступа в интернет в целях безопасности).
