shurshur

Чтобы шаблонизатор flask так не делал, надо использовать фильтр safe.

{{ url_for('static' filename='...')|safe }}

См. также документацию.

Не надо использовать time.sleep в асинхронном коде, это блокирует event loop! Вместо этого надо использовать асинхронный вариант asyncio.sleep.

По существу с таким кодом будет делаться 10 отправок в секунду, а официально лимит 30 в секунду. Но лучше бы дополнительно отлавливать исключение с flood control и по нему делать дополнительный sleep хотя бы на 1 секунду, а то и чуть больше, чтобы счётчик числа попыток на стороне Telegram обнулился за это время.

bot.send_message(message.chat.id, 'привет '+message.text)

или

bot.send_message(message.chat.id, f'привет {message.text}')

"Сниффить" может только root.

upd: Каждый объект и каждый запрос имеют ID.
ID каждого объекта больше предыдущего на 1.

Помнить самый большой из id уже возвращавшихся, при каждом запросе проверять, нет ли id больше запомненного. Запросы делать с определёнными интервалами (sleep), чтобы их число в единицу времени не превышало лимитов (наприммер, если разрешено максимум 10 запросов в минуту, то нужно сделать интервал не меньше 6 секунд).

Между прочим, getUpdates в библиотеках telegram используют примерно так же. Более того Bot API позволяет указать в параметре offset нужный id, чтобы в ответ вернулись только более новые.

Довольно кроссплатформенный способ запросить права администратора реализует модуль https://pypi.org/project/elevate/

Для этого порт надо пробрасывать как tcp, не http/https.

Но вообще-то это неправильная практика. Как раз на прокси/балансеры и вешают сертификат в таких случаях, а дальше терминируют трафик на http или на https с любым сертификатом.

input - синхронная функция, она блокирует event loop. Для работы с консолью можно использовать асинхронную функцию ainput из модуля aioconsole.

import asyncio
from aioconsole import ainput

async def main():
  s = await ainput('Enter something: ')
  print (f"You entered {s}")

loop = asyncio.get_event_loop()
loop.run_until_complete(main())

primary key и не обязан "сам заполняться" ни в одной базе. Даже в mysql это отдельная фича - auto_increment. А тут для этого нужен sequence или serial. См. например тут: https://www.postgresqltutorial.com/postgresql-serial/

В России есть Россвязь, которая распределяет номерную ёмкость по операторам. Эта информация публична, можно скачать машиночитаемые выгрузки у них на сайте: https://rossvyaz.gov.ru/deyatelnost/resurs-numerac...

Далее, в России есть MNP, позволяющий переносить мобильный номер от оператора к оператору. Но только в пределах региона. Поэтому если задача по номеру определять только регион, то она надёжно решается указанными выше выгрузками. Оператора по ним определять ненадёжно, так как ежедневно много номеров меняют оператора, и любые данные быстро устаревают.

Оператором базы данных перенесённых номеров (БДПН) является ЦНИИС, на его сайте можно получить текущего оператора только по конкретному номеру: https://zniis.ru/bdpn/check/ а обновляемый доступ ко всей базе простым смертным не получить.

Чтобы понимать масштаб проблемы, сейчас в России ~14.7 млн. перенесённых номеров, за вчерашние сутки ~9.5 тыс. номеров поменяли оператора и ~1.5 тыс. вернулись из списка перенесённых к своему родному оператору.

Таким образом, никакого смысла в подобном сайте без обновляемого доступа к БДПН (а она обновляется каждые 2 часа) нет.

Что касается технической реализации, то тут всё достаточно просто, если у тебя есть доступ к БДПН. ЦНИИС публикует раз в сутки Numbering_Plan, аналогичный выгрузке DEF-9xx.csv Россвязи (формат отличается, но смысл тот же - диапазоны, каждый назначен оператору+региону), также публикует раз в сутки Port_All с полным списком MNP. Если не нужно поддерживать (для простоты) частые (каждые 2 часа) обновления, то этого достаточно. Любой номер сначала проверяем на наличие в Port_All, если не нашёлся - ищем подходящий диапазон в Numbering_Plan.

BGP оперирует не IP-адресами, а автономными системами, которые должны быть не менее чем /24 (256 адресов). Судя по всему, у вас нет своей AS, а адреса принадлежат провайдерам.

Я вижу только один способ сохранить прям те же самые адреса: сервер поместить в датацентр, а на старом месте оставить недорогой сервер для проброса нужных портов в целевой сервер в датацентр. Лучше подобное воспринимать как временное решение, всё переносить на новый IP сервера, переводить туда клиентов и всё такое, чтобы в дальнейшем когда-нибудь от лишних провайдеров отказаться.

Если у оператора есть точка присутствия в датацентре, а текущий договор на юрлицо, то можно попробовать официально договориться с ним о том, чтобы подключиться к нему в датацентре и перености IP, но у оператора моугт быть (и скорее всего будут) свои нюансы устройства сети, которые это не позволят.