Bogdan, в зависимости от того, что и от кого мы хотим защищать, возможны варианты. Например, если это коммерческий софт с доступом к серверу, который надо защищать от множественного использования, то можно продавать пользователю файл лицензии, который будет содержать индивидуальный ключ ограниченного срока действия, авторизующий на сервере. Для усложнения переиспользования ключ может быть привязан к железу и системе (часть ключа - хеш каких-то данных локалхоста), плюс можно по ключу не выдавать настоящий доступ, а только относительно короткоживущий токен, слишком частый перезапрос которого триггерит блокировку.
Если надо не дать пользователю кидать на сервер данные под видом данных рандомного пользователя, можно, например, шифровать/подписывать передаваемые в брокер данные ключом пользователя.
В своей железке тут уже предлагали железные решения. Можно и не в своей железке, есть разного рода железные токены, генераторы одноразовых паролей итд итп.
И в целом есть много других вариантов. Но, как я уже говорил, всегда надо начинать с модели угроз. Будет ли кто-то вообще заморачиваться, или это на самом деле никому нафиг не нужно?
INeedUrHelp, я тут бываю под настроение, когда мне интересно посмотреть, что в мире делается, или что-нибудь попробовать. Когда мне интересно - я смотрю, разбираюсь, когда скучно - прохожу мимо. Мне скучно ковырять очередную форму логина. Фрилансить мне тоже малоинтересно, тем более 150 рублей - это оплата от силы нескольких минут работы.
Ужас какой. Не нужно никакого цикла, bot.polling сам делает нужный цикл. Нужно просто менять handler'ы по мере ответов от пользователя. Примеров такого - вагон.
Зачем хранить пароль в коде? В статье какой-то лютый пример приведён из серии "как не надо делать вообще никогда". В качестве самого минимального варианта пароль по меньшей мере выносится в конфиг, который в кодовую базу не входит и прикладывается к приложению только при выкатывании в прод (речь, конечно, о сетевых приложениях на своём сервере). А дальше можно делать разные другие усложняющие вещи: передавать пароль при запуске приложения через переменные окружения или даже прямым запросом с консоли, использовать разного рода шифрованные key store с мастер-паролем. который также передавать через окружение или ещё каким-то небанальным способом... Очень много зависит от уровня рисков и от предполагаемых угроз. От чего защищаемся-то?
acwartz, знакомый работал в Huawei, программировал какие-то контроллеры. У них была ферма из этих контроллеров, которые можно было использовать удалённо.
Никита Андреевич, разницу udp/tcp программисту надо понимать обязательно! Он же должен знать, что и почему выбрать для решения конкретной задачи, а без понимания не получится.
by_EL, смотрим man shutdown на тему того, что умеет shutdown, и man halt на тему того, что умеет halt.
То, что все они представляют из себя ссылки на systemctl (проверяется командами типа ls -l /sbin/halt), это всего лишь особенности реализации. Любая программа может через argv[0] узнать, по какому имени её запустили, и systemctl при вызове с именем типа halt или shutdown просто изменяет своё поведение.
Если надо не дать пользователю кидать на сервер данные под видом данных рандомного пользователя, можно, например, шифровать/подписывать передаваемые в брокер данные ключом пользователя.
В своей железке тут уже предлагали железные решения. Можно и не в своей железке, есть разного рода железные токены, генераторы одноразовых паролей итд итп.
И в целом есть много других вариантов. Но, как я уже говорил, всегда надо начинать с модели угроз. Будет ли кто-то вообще заморачиваться, или это на самом деле никому нафиг не нужно?