Pavel K

Это процесс открытия диспетчера задач

Я лично за Qt. Дорабатывается, быстр, гуишные библиотеки до 10 Мб занимают точно.

Нужно свою схему выдумывать, но это будет менее секурно, тк нужна связь между вторым фактором (телефоном) и сервером.

То есть нужно, что бы была просто кнопка "Подтвердить" и эти цифры отправлялись на IP адрес сервера.

Тут будут уже не цифры отправляться, а просто запрос с идентификатором сессии, которую нужно разрешить.

+ Это не стандартизировано и придётся делать своё приложение и свой протокол.

Обычно это выглядит так:
1. На каждую попытку входа создаётся уникальный токен, который выводится на экран компьютера при помощи QR-кода.
2. Пользователь открывает приложение на телефоне, где он уже залогинился (используя другой вариант второго фактора, типа тех же TOTP или sms)
3. В приложении сканирует этот код, приложение получает информацию об этой попытке входа с вашего сервера и демонстрирует пользователю (ip адрес, имя устройство, примерное местоположение).
4. В случае подтверждения пользователем - отправляет запрос на сервер, токен становится "подтверждённым"
5. Сервер отправляет в браузер уведомление о том, что вход разрешён и выдаёт уже рабочий токен. Успех.
(Используется в Steam, Discord, Telegram)

Второй вариант:
1. Пользователь вводит логин + пароль и выбирает в качестве второго фактора - приложение на телефоне, где он уже залогинен.
2. В приложение приходит уведомление о том, что совершена попытка входа, которую нужно подтвердить или отказать. Для дополнительной безопасности также может быть запрошено число, которое отображено на странице входа.
3. При подтверждении - попытка также подтверждается и в браузер отправляется уведомление.
Используется в сервисах MS, Github, Google

Оба варианта не отменяют TOTP, так как требуют как минимум одно уже авторизованное устройство.

но пользователи жалуются, что не удобно вбивать цифры из приложения с телефона.

Пользователи всегда будут жаловаться. Ещё больше они будут жаловаться, если они не смогут залогиниться в ваш сервис, когда у них нет связи на телефоне.

Это дополнение называется Microsoft Autenticator и почти именно так и работает. К сожалению - это способ только для самого Microsoft.

Это невозможно, либо отказаться от такой идеи, либо сделать окно вообще без границ и верхней панели (QtCore.Qt.FramelessWindowHint), и сделать свою верхнюю панель.

для дат timestamp>0 довольно простая математика.

#include <stdio.h>
#include <time.h>
int main(){

    time_t all_seconds = time(NULL);
    printf("временная метка - количество секунд с 1970-01-01 00:00:00 +0000 в четверг : %lu\n",all_seconds);

    double all_minutes = all_seconds/60.0;
    double all_hours = all_minutes/60.0;
    double all_days = all_hours/24.0;
    double all_years = all_days/(365.0+0.2425); //с учётом високосного
    //timestamp  начинается с 1970-01-01 00:00:00 +0000 в четверг
    long years_l = (int)all_years;
    long year = years_l + 1970;
    printf("год : %ld ",year);
    bool is_leap_year = !((year % 4 != 0) || ((year % 100 == 0) && (year % 400 != 0)));//високосный каждый 4 но не кратен 100

    if(is_leap_year){
        printf("високосный\n");
    }else{
        printf("не високосный\n");
    }

    double days_from_year_start = all_years - years_l;
    int day_in_month[12]={31,28,31,30,31,30,31,31,30,31,30,31};
    int month=0;
    double day_d=days_from_year_start*(365.0+(is_leap_year?1:0));
    int day=(int)day_d;
    int day_in_month_t;
    do{
        day_in_month_t=day_in_month[month];
        day-=day_in_month_t;
        if(is_leap_year){
            if(month==1){
                day--;
            }
        }
        month++;

    }
    while((month<12) && (day>day_in_month_t));
    const char* month_name[12]={"январь","февраль","март","апрель","май","июль","июнь","август","сентябрь","октябрь","ноябрь","декабрь"};
    printf("месяц : %s\n",month_name[month]);
    day++;// сдвиг нулевого дня 0 -> 1
    printf("день : %d \n",day);

    int day_of_week = ((((int)all_days)%7)+3)%7;//сдвиг для 0 дня. 1 день 1970 был в чеверг
    const char* week[7]={"пн","вт","ср","чт","пт","сб","вс"};
    printf("день недели : %s \n",week[day_of_week]);

    int hour = ((int)all_hours)%24;
    printf("час для GMT+0 : %d \n",hour);

    int minutes = ((int)all_minutes)%60;
    printf("минуты : %d \n",minutes);

    int seconds = ((int)all_seconds)%60;
    printf("секунды : %d \n",seconds);
return 0;
}

для остальных дат надо делать пересчёт с учётом более длинных циклов и нулевого года.

Я думаю, что пара gmtime + timegm -- это простое, понятное, сравнительно портабельное и довольно быстрое решение:

#include <time.h>

enum time_floor_level {
    YEAR, MONTH, DAY, HOUR, MINUTE,
};

time_t time_floor(time_t t, enum time_floor_level level)
{
    struct tm tm;

    gmtime_r(&t, &tm);

    switch (level) {
    case YEAR:
        tm.tm_mon = 0;
    case MONTH:
        tm.tm_mday = 1;
    case DAY:
        tm.tm_hour = 0;
    case HOUR:
        tm.tm_min = 0;
    case MINUTE:
        tm.tm_sec = 0;
    }
    return timegm(&tm);
}

Сделай новую ветку и вмержи туда.
Работу продолжай в основной и подмерживай её в новую ветку где вмержен PR.

Так ты сможешь легко откатиться

async_read не перекрывает async_write потому, что под капотом происходит не совсем то, что вы видите в исходных кодах. Блоки кода вроде boost::asio::async_read и boost::asio::async_write (я их далее буду называть задачами) во время компиляции разбиваются на более мелкие инструкции. В фоне система может приостанавливать исполнение одной задачи, запоминая все её данные, переключаться на другую задачу и какое-то время исполнять её, потом приостанавливать её исполнение и переключаться на третью задачу, потом снова на первую и так далее по кругу. За счёт этого можно в рамках одного потока выполнять сразу несколько задач. Сама эта система конфигурируется таким образом, чтобы переключаться по очереди этих задач один раз, например, в микросекунду. И таким образом она кусками их выполняет, а у вас складывается впечатление, что они работают параллельно, потому что переключения по очереди происходят очень быстро и зависят не от объёма кода, который нужно выполнить, а от фиксированного времени, которое система готова потратить на работу с одной задачей.

Обычно асинхронность именно так и организуется. Если же исполнение синхронное, то система просто работает над одной задачей и никуда не переключается, пока её не завершит.

Не уверен, что правильно понял ваш второй вопрос. Когда операции выполняются, они естественно потребляют ресурсы. А если их нет в очереди исполнения, то никаких ресурсов не потребляется. Система просто вхолостую раз в микросекунду проверяет очередь задач.

Read время от времени запускается, так что да, определённые ресурсы потребляются, потому что всегда проверяется, если что-нибудь, что нужно прочитать, но там проверяется буффер на предмет данных, а не сам сокет. Так что, ресурсы потребляются, но не настолько сильно, как при чтении существующих данных.

(Раз в микросекунду — это не точное значение, и я его привёл только для примера, чтобы было понятно, что переключение по очереди задач происходит очень часто.)

Не использовать eval, а парсить уравнение самостоятельно или при помощи какой-нибудь готовой библиотеки.
Например вот: https://nerdamer.com/ или https://mathjs.org/
PS: серьезно. Не используйте eval. Никогда