shurshur, тогда вопрос автора ещё более бессмысленный.
Берём Thunderbird, генерим PGP ключ. Находим ещё одного такого товарища и переписываемся абсолютно безопасно
shurshur, поддерживает конечно. Я живых людей пользующихся PGP не видел. Ну ладно, я сам пробовал пару раз.
Но Thunderbird это не почтовый сервис. Для сервиса (гугла/яндекса) это будет просто письмо с бессмысленным набором символов.
Так-то вон и ProtoMail поддерживает и даже использует внутри себя. Но наружу всё равно шлёт открытым текстом (в TLS), если явно не настроить и не предоставить публичный ключ.
Технически e2ee для писем существует уже 35 лет (см PGP), но на практике я ни разу его не видел.
pavlik 322, если гугл/яндекс/майл будут хранить зашифрованные письма, то подумайте и попробуйте ответить на вопрос кто и в какой момент будет их расшифровывать?
> Если id autoincrement, то нужна централизованная генерация чтобы не попасть в лапы коллизий.
и кто сказал что это не так в случае телеграма?
учитывая что у них как раз пользователи привязаны к датацентрам сделать id = префикс ДЦ + автоинкремент внутри ДЦ вообще не проблема.
> нужен генератор который будет выдавать уникальные идентификаторы ничего не зная о уже сгенерированных
ну возьмите UUID и не изобретайте велосипед. Я бы сейчас взял UUIDv7
Пользователь может заставить браузер отправлять оба заголовка, но только в каком-нибудь fetch-запросе, не в переходе по ссылке (если не рассматривать перекомпиляцию браузера и всякие curl-ы).
В нормально настроенном сервере заголовок X-Forwarded-For скорее будет принят во внимание, а X-Real-IP проигнорирован. Но разумеется всегда есть опция настроить сервер криво и выстрелить себе в ногу.
47911, оно очень даже влияет на скачку файла. Скорее всего вам нужен last, а не break, что бы nginx сделал внутренний переход в локацию которая обрабатывает php-файлы
Salamandrine, технически, с точки зрения протокола HTTP, это два разных заголовка.
X-Forwarded-For исторически используется в прокси-серверах, может содержать несколько значений через запятую и вообще говоря ему нельзя доверять, потому что любой прокси-сервер на пути может туда записать что угодно. В реальности настоящих прокси серверов в дикой природе уже практически нет.
В nginx используется заголовок X-Real-IP в тех местах где ему гарантированно можно доверять. Например если вы ставите свой nginx за другим сервером который вы контролируете (или доверяете тем кто его контролирует) и который выставляет правильный заголовок X-Real-IP.
https://yandex.ru/dev/disk-api/doc/ru/reference/public