Насколько я знаю, в некоторых компиляторах C++ не получится использовать string, не подключив заголовочный файл явно, даже если он включается где-то в недрах других файлов. Кроме того, нужно учитывать, что если в одной реализации в заголовочном файле доступен string, то в другой его может и не быть, потому что реализовано как-то иначе (через базовый класс, например).
Так что лучше указать явно.
Вообще, если бы тут делали как в языках типа python и в каждом заголовочном файле был свой namespace вместо std, то было бы более очевиден ответ на этот вопрос :)
art_gara55555, написал в ответы, чтобы приходящие из поиска находили решение. Вообще, я заметил, что часто стали возникать примеры кода с interval=1, видимо не все понимают, как это работает...
Nik Faraday, да, я уже писал выше, что это отдельный сервис, что может быть неудобно. Но его можно развернуть у себя, доступ в интернет для его работы я так понимаю не нужен.
art_gara55555, увеличь интервал, 1 секунда это мало, и при любой ошибке ты скорее всего очень быстро сделаешь второй запрос, который и вызовет подобное поведение. Дефолтные 30 секунд это норма, не надо их менять без очень веских причин.
Long polling так и работает: запрос длится 30 секунд, если приходит событие - запрос завершается досрочно. Это позволяет и события получать быстро, и сервер слишком часто не дёргать.
Обычно эта ошибка означает, что с этим токеном запущено два экземпляра бота. Например, забыл остановить бот перед внесением правок, отредактировал и запустил ещё одного.
Плохая практика - делать рассылки в боте. В Телеграме специально для этой задачи придумали каналы. Пользователи сами могут подписываться на каналы, которые их интересуют, и отписываться, если интерес пропал.
Nik Faraday, наверняка есть и это не только отсутствие платной поддержки, но я не изучал какие именно.
Неприятно, что на сайте разработчиков нелегко найти внятное описания этой разницы, при том, что обычно проекты с такой моделью монетизации и открытости эту информацию не скрывают.
ProjectSoft, сейчас браузеры легко исправляют очень многие косяки разметки, но это не значит, что это правильно. Но на самом деле там явно дело не в этом, раз пользователь получает 404, то у него проблемы где-то от начала /bot и до конца /sendMessage.
А ещё, скорее всего, он что-то делает неправильно, потому что передавать ссылки на API-вызовы в HTML - это более чем странно.
CityCat4, да, я работаю в том, что имеет отношение к очень критичной инраструктуре. И у нас сейчас занялись этой головной болью исключительно потому, что в некоторых конкурсах это обязательное требование (в конкурсах вообще часто бывают идиотские требования, что уж поделать). Сами же мы ни капли не интересуемся наличием в этом реестре при покупке чего бы то ни было, потому что это лишено какого-либо смысла.
Nik Faraday, вот буквально только что в NextCloud Apps нашёл ONLYOFFICE, нажал "установить" и теперь лежащий у меня в NextCloud .docx-файл открылся в нём.
kaxa3201, если стоит задача искать по всяким вариантам типа по фамилии из ФИО, то разделяем ФИО на слова, каждое шифруем отдельно, при поиске шифруем поисковые слова и используем like на них. Примерно так.
Полноценный поиск по шифрованным данным, конечно, невозможен. Иначе бы смысла в шифровании не было вообще: можно было бы по словарным спискам распространённых фамилий прилично идентифицировать кучу людей из шифрованной базы.
Заказчику можно предложить сделать какой-то Особо Защищённый Сервис с персональными данными, который будет огорожен от остальной инфраструктуры и предназначен для обслуживания именно этих специальных запросов. Разумеется, не надо думать, что можно так легко и нахаляву работать с персональными данными как будто они не являются персональными.
Если речь о том, может ли пользователь сформировать произвольный запрос, то да, может. Защититься от этого невозможно. Но можно бороться с последствиями, защищая сервер от выполнения недостоверных запросов, на которые у клиента нет прав, которые не соответствуют ограничениям целостности итд итп.
Это вопрос как проектирования архитектуры, структуры API-вызовов, так и внедрения проверок и ограничений на сервере, проверки правомочности операций, реализации какой-либо системы авторизации и аутентификации (сейчас модно использовать jwt-токены). Нельзя дать однозначный ответ, как лучше. Очень сильно зависит от задачи и требований.
mayton2019, я даже больше скажу, нам тут приходится с нашими "девопсами" периодически воевать, чтобы они не лезли все логи сливать куда-нить по сети в какую-нить неведомую хреновину. Наша позиция - логи должны писаться на локальный диск в виде файлов. Чтоб никакие потери сети или глюки хреновины не повлияли ни на строчку лога.
Так что лучше указать явно.
Вообще, если бы тут делали как в языках типа python и в каждом заголовочном файле был свой namespace вместо std, то было бы более очевиден ответ на этот вопрос :)