Передавать исходнй код - большая глупость. Если уж передавать что-то зашифрованное, то уже скомпилированный код. Тут при его взломе хотя бы не получат исходный код в чистом виде.
Такой механизм тоже подвержен атаке. Надо найти, где хранится ключ расшифровки, и подсунуть свой вместо. А дальше уже пихать свой изменённый код, который будет зашифрован уже другим ключом.
Также если скачиваемые файлы кладутся локально и затем запускаются, то их можно перехватывать на этой стадии.
Небольшой пример из области. Я как-то ломал древнюю программу, которая внутри содержала базу знаний, которую показывала в embedded IE. Файлы извлекались во временный каталог, показывались в браузере и тут же удалялись. Две разных части программы я ломал двумя путями:
1. Часть ломалась запретом удаления файлов (в NTFS так можно сделать).
2. Другая часть падала, если не могла удалить файл, но там я просто запустил циклический rsync, который быстро забирал все новые файлы.
А дальше все собранные файлы я скриптами обрабатывал-переименовывал и конвертил в chm-файл, который в винде очень удобно и быстро можно смотреть штатным просмотрщиком справки.
Системы защиты хапускаемого кода разрабатывают годами. Там хранят ключ в зашифрованном виде, растащенный по разным файлам, в разных частях кода вставляют всякие проверки, которые ломаются от изменения любого бита ключа. Делаются отложенные проверки, когда проверка выпадает не сразу, а через неделю-месяц после взлома. Иногда применяются остроумные решения, как в хрестоматийной истории с картриджами приставки, в которой контроль оригинальности был по стартовой картинке, которую пираты привыкли менять на свою собственную. Итд итп. Тут за вечер-другой не сделать лучше, чем сделали программисты толстых крупных бизнесов, при том, что и там защиту совсем даже не раз ломали.
И всё это может требовать нехилых таких вложений сил и времени, которые может быть полезнее потратить на написание более полезного и даже прибыльного проекта. Так что следует начать с целеполагания и модели угроз.
Например, если это очередная запускалка небольших игрушек, то предлагаю просто забить. Лучше сделать больше игрушек и увеличить пользовательскую базу, чем бороться с теми умниками, которые будут это пытаться поломать. Эффективность усилий будет никакая. Ну, можно что-нить простое сделать, чтобы большинство простейших попыток отсечь, и на этом хватит.
xfnxfn, ну вот пример задачи, в которой можно многое попробовать.
Считать с диска список файлов: имя, размер, дата изменения - и сделать список из него. Сделать сортировку по имени, по размеру, по времени изменения несколькими способами (пузырьком, слиянием итд). Заодно тренировка по алгоритмам.
xfnxfn, указатели по-прежнему нужны, просто сфера их применения сильно сократилась. Также часть функциональности указателей теперь можно исполнить с помощью ссылок &.
При использовании std::vector и других структур STL вообще не нужно задумываться, например, о размере выделенной памяти. Добавляешь сколько угодно элементов - класс сам решит все вопросы. Как - его проблемы. И при удалении объекта деструктор сам всё за собой подчистит, не нужно забивать этим себе голову.
На самом деле для общего развития рекомендую попробовать релизовать парочку задач на чистом C, чтобы сравнить ощущения. Вот там особенно заморочиться придётся с указателями и выделениями памяти. В том числе самому считать нужный размер в байтах.
xfnxfn, матрицы обычно лучше передавать не двумерными массивами, а одномерными, с вычислением индекса по формуле i*n+j. Тогда и выделять память многократными операциями не нужно, и обращение к элементу массива не будет требовать двух операций с указателями.
Но совет использовать STL - он полезный. Повсеместное использование указателей в C++ - это практика из конца прошлого века.
Это такая фича. Раньше бот мог писать только тем пользователям, которые по своей инициативе ему сами написали. С некоторых пор бот может писать подписчикам канала, в котором бот добавлен как админ.
В реальности я так ни разу и не видел ни одной действительно полезной реализации этого функционала. Всегда это была реклама или какая-нибудь бесполезная приветственная хрень. Поэтому если канал так себя ведёт - он сразу уходит в чёрный список. И многие пользователи сделают так же, поэтому я настоятельно рекомендую этот чёрный паттерн не использовать.
Елена, такси, доставка и даже неведомое "прочее" позволяют указывать точки куда приехать и куда привезти. Я даже больше скажу - это ещё и точнее работает. Давать доступ к своему местоположению вообще необязательно.
Если использовать API с токеном пользователя, то это всё равно, что пользователь сам лайкает, так что лимиты такие же. Но если начать слишком активно ботоводствовать действия пользователя, то реально можно нарваться на бан.
RINCODE, не надо верить любым сказкам, которые рассказывает нейросеть. В современной версии телебота есть класс AsyncTelebot, который как раз асинхронный.
Однако разбираться потом, что там сломается при замене класса на асинхронный, может быть не очень просто. И вполне возможно окажется, что проще переписать всё на более развитую асинхронную библиотеку aiogram либо даже на сам pyrogram, раз уж он тоже предполагается к использованию.
0xsetup, я go не знаю и поэтому опишу "на пальцах".
Предствим себе, у нас есть "состояние" - это может быть строка, а может быть класс с полями. Самый простой способ хранить состояния - это массив:
user_states[user_id] = state
Но это имеет недостатки: мы вынуждены обходиться одним процессом, а также теряем состояние при падении/перезапуске. Ещё на это требуется память, при большой аудитории это может оказаться важно.
Ещё одна проблема может быть с множественным доступом в многозадачных реализациях, особенно если выполняемое действие не атомарно. Ну, там надо это средствами языка учитывать, например, использовать блокировки на чём-нибудь типа мутексов.
Довольно частая ошибка новичков - они хранят state в одной переменной без учёта конкретного пользователя. Тогда если между запросами одного пользователя влезает другой (третий и так далее), случаются очевидные проблемы.
Вот, и вместо массива состояний можно класть/брать в базу или в key-value.
В данном случае видимо используется redis. Но если состояния путаются, то я полагаю там что-то путается в ключах. Например, может быть stateKey не только userId использует, но и как-то зависит от других внешних сущностей, которые успевают поменяться между запусками?
monelot, обычно делают по-другоу: бот - точка входа для пользователя, и сообщения боту пересылаются администратору, причём администратор их видит также внутри диалога с бото. Ну там ещё всякие кнопки, переключающие диалоги, работа с историей итд. Позволяет не раскрывать владельца. Можно сделать, чтобы человеку могли отвечать несколько операторов, пусть даже не сейчас, а в будущем (на вырост решение).
Если же надо, чтобы пользователь всего лишь попадал напрямую в диалог с владельцем, то просто делаем url-кнопку с ссылкой на телеграмный профиль владельца.
У меня был случай, сайт на битриксе начал дико лагать. Поиски привели к тому, что проблему создавала каруселька на главной, в ротации которой были уже удалённые файлы. Так как файл не находился, вместо него показывался 404.php, который грузил ядро битрикса и отдавал контент довольно медленно. У сайта хватало пассивных посетителей с крутящейся каруселькой, чтобы создавать из-за этого бессмысленную нагрузку.
Я наскоро решил это, завернув 404 по расширениям типа .png .jpg .gif в 404fast.php, который битриксовое ядро не грузил. Конечно, правильнее было бы нормально класть статику в каталог, в котором не используется 404.php вообще, но там за годы существования файла такй бардак в файлах был, что решать его мне совсем не хотелось...
Если речь о том, что бот вешает сообщение с кнопками, а нажатие на кнопку посылает сообщение владельцу бота, то не вопрос, легко можно. Если же это какой-то произвольный пользователь, то боты не могут писать пользователям, не удовлетворяющим некоторым условиям (пользователь должен нажать Start в боте или быть подписан на канал, где бот добавлен админом).
Если "состояние ушло другому пользователю", то это изначально ошибочная реализация.
Состояние должно в ключе иметь id пользователя. От количества пользователей бот может перестать справляться, но взять по id одного пользователя состояние другого пользователя - никак.
Такой механизм тоже подвержен атаке. Надо найти, где хранится ключ расшифровки, и подсунуть свой вместо. А дальше уже пихать свой изменённый код, который будет зашифрован уже другим ключом.
Также если скачиваемые файлы кладутся локально и затем запускаются, то их можно перехватывать на этой стадии.
Небольшой пример из области. Я как-то ломал древнюю программу, которая внутри содержала базу знаний, которую показывала в embedded IE. Файлы извлекались во временный каталог, показывались в браузере и тут же удалялись. Две разных части программы я ломал двумя путями:
1. Часть ломалась запретом удаления файлов (в NTFS так можно сделать).
2. Другая часть падала, если не могла удалить файл, но там я просто запустил циклический rsync, который быстро забирал все новые файлы.
А дальше все собранные файлы я скриптами обрабатывал-переименовывал и конвертил в chm-файл, который в винде очень удобно и быстро можно смотреть штатным просмотрщиком справки.
Системы защиты хапускаемого кода разрабатывают годами. Там хранят ключ в зашифрованном виде, растащенный по разным файлам, в разных частях кода вставляют всякие проверки, которые ломаются от изменения любого бита ключа. Делаются отложенные проверки, когда проверка выпадает не сразу, а через неделю-месяц после взлома. Иногда применяются остроумные решения, как в хрестоматийной истории с картриджами приставки, в которой контроль оригинальности был по стартовой картинке, которую пираты привыкли менять на свою собственную. Итд итп. Тут за вечер-другой не сделать лучше, чем сделали программисты толстых крупных бизнесов, при том, что и там защиту совсем даже не раз ломали.
И всё это может требовать нехилых таких вложений сил и времени, которые может быть полезнее потратить на написание более полезного и даже прибыльного проекта. Так что следует начать с целеполагания и модели угроз.
Например, если это очередная запускалка небольших игрушек, то предлагаю просто забить. Лучше сделать больше игрушек и увеличить пользовательскую базу, чем бороться с теми умниками, которые будут это пытаться поломать. Эффективность усилий будет никакая. Ну, можно что-нить простое сделать, чтобы большинство простейших попыток отсечь, и на этом хватит.