Геннадий Акулов

Ну якщо у вас тільки 2 поля (чи не набагато більше), то ви можете використати IF чи CASE функції тобто якось так

UPDATE A JOIN B ON A.id=B.id SET A.one = IF(B.name = 'one',1,0), A.two= IF(B.name = 'two',1,0)

Якщо ж їх більше або ж ви не знаєте самих назв полів, то тут потрібно придумати щось інше )

Надіюсь вам це допоможе

$command = '/start 123456 dsad';
$regex = '/(\/start\s)(\d+)/';
if(preg_match($regex, $command, $match)) {
    $num = $match[2];
    echo $num; // 123456
}

Словарь, в котором ключ - это команда, а значение - это обработчик этой команды "CommandExecutor"
Все обработчики - это классы, наследуемые от единого класса "CommandExecutor", который умеет сам регистрироваться в словаре этом, и у которого есть метод Execute, который собственно и будет вызываться в момент прихода сообщения из того самого словаря.

В своём боте по учёту долгов https://t.me/DebtsTrackerRuBot я реализовал это следующим образом.

Создал табличку TgChat в БД с ключём по chat_id и в ней есть поле lang:string. По умолчании там русский, но пользователь может в настройках поменять на английский или другой.

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

В этой же табличке хранится текущее состояние чата так что грузить эту запись надо всё равно, соответсвенно накладных расходов ноль.

Чтобы понять, к чему относится ответ пользователя, нужно в БД сохранить статус диалога, например "задан вопрос №3" и при приходе сообщения проверять этот статус.

В bot api telegram и не должно быть методов для работы с состояниями.
Состояния это уже логика самого приложения, а api это интерфейс для работы с мессенджером.

Самый простой вариант для состояний:
1. Делаем таблицу state, в которой храним id пользователя и его текущее состояние.
2. При каждом обращении к боту проверяем в каком состоянии пользователь. Если обращение в первые, то создаем запись.
3. В логике бота смотрим при каких состояниях, что должно происходить.

Можно все в базу писать, можно redis использовать, можно в памяти держать (если скрипт бота постоянно работает, а не через вебхуки запускается скрипт и после выполнения завершается).

Тут дело не в том, что переменные в другом case не видны, а в том, что переменная локальная и после того, как $login или $password устанавливается происходит выход из функции.

Стандартной реализации нет. Бот - просто канал взаимодействия. Проверки и ограничения надо делать на своей стороне.
Там особой логики и нет. Просто делаете таблицу с id (или логин, если есть, но лучше id) пользователей, кто может использовать бота. Все остальные просто игнорируются.

Модель - это любая ваша бизнес-логика, всякие вычисления и запросы к бд. То есть то, без чего приложение впринципе не имеет смысла.

Контроллер - это посредник между моделью и видом. Он запрашивает данные (вызывает методы) у модели и затем передает их в вид.

Вид - с помощью полученных данных от контроллера рисует пользовательский интерфейс.

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

Нужна одна точка входа. Клиент всегда запрашивает только index.php, оно там внутри на основе данных из запроса решает какой контроллер создать и какой метод из контроллера выполнить. Всё.

Когда данные обработаны в PDO, они напрямую передаются драйверу базы данных, либо запрос строиться безопасным образом внутри данного расширения. Как можно заметить, это простой путь решения проблемы с SQL инъекциями.
Однако при использовании предопределенных выражений совместно с PDO необходимо знать некоторые нюансы, чтобы избежать неприятных ситуаций. Например, в MySQL клиенте некоторые запросы, составленные посредством предопределенных выражений, не могут быть выполнены, а так же они не используют кэш, что может замедлить работу вашего web-приложения.
Гарантированная безопасность при использовании предопределенных выражений звучит успокаивающе, но разработчики не должны принимать PDO и другие слои абстракции\предопределенные выражения за абсолютную защиту от взлома. Любые входящие данные должны проверяться, PDO – дополнительная линия обороны. Это расширение не закрывает все множество уязвимостей, посредством которых может быть нанесен вред вашей информации, но в то же время, PDO неплохо справляется с вопросом предотвращения SQL инъекций.

Источник

Защищенность PDO от инъекций строится на использованании не динамически создаваемых запросов, но запросов с параметрами. Любой момент изменения запроса в коде под какие-то (часто необдуманные) нужды приводит к возможности инъекции.

пример вам уже привели, повторю его:

$qry = 'select * from users where user_id='".$usrname.'" and passwd='".md5($passwd.'$salt).'"';

запрос подвержет инъекции: достаточно подсунуть имя с двойной кавычкой и далее через точкузапятую свой запрос. Остаток с паролем комментируется символами:

$usrname = '"; update users set passwd="12345" where id="admin"; -- ';

приведет фактически к такому запросу

select * from users where id=""; update users set passwd="12345" where id="admin"; -- passwd=''

совсем другое дело PDO. Он не допускает мультикомандные запросу как факт (то есть после первого select обработка не пойдет). А во вторых указанные инъекции просто запицется в параметры запроса, что будет обработанно корректно.