А если я в тело запроса буду подставлять идентификатор запроса?

А если я в тело запроса буду подставлять идентификатор запроса?

И хранить каждый запрос?

И хранить каждый запрос?

Не запрос, а его идентификатор

Не запрос, а его идентификатор

Ну я это имел в виду

Каждый запрос будет иметь свой UUID

Генерить случайным образом

Записывать на стороне сервера

И не пускать запросы с такими UUID

Но проще юзать https

Но проще юзать https

Юзай шттпс

Что мешает?

Что мешает?

Ничего

Ничего

Таки юзай

Так я и не против

Просто для общего развития стало интересно, можно ли без https как-то решить эту проблему

Так у меня итак все запросы через Nginx с ssl проксируются

Просто для общего развития стало интересно, можно ли без https как-то решить эту проблему

Велосипеды

Да

Да

> клиент генерит

Есть примеры реализации?

Условно от клиента публичным ключом шифровать запрос, на сервере приватным расшифровывать?

Но он его не пихнет в jwt

Т.к. не знает токена

Блягениально: прятать ююид в самом зашифрованном запросе

Условно от клиента публичным ключом шифровать запрос, на сервере приватным расшифровывать?

клиент своим собственным сертом подписывает запросы, сервер проверяет подпись

Блягениально: прятать ююид в самом зашифрованном запросе

Именно

Я вижу это так, при авторизации генерировать пару ключей для пользователя, на клиент отправлять публичный, на сервере хранить приватный. Далее все запросы через post и сшифровкой тела запроса. На сервере запрос расшифровывается и читается

У клиента и у сервера есть ключ, которым клиент шифрует запрос, а сервер расшифровывает

У клиента и у сервера есть ключ, которым клиент шифрует запрос, а сервер расшифровывает

Тогда его можно упереть с устройства

Я вижу это так, при авторизации генерировать пару ключей для пользователя, на клиент отправлять публичный, на сервере хранить приватный. Далее все запросы через post и сшифровкой тела запроса. На сервере запрос расшифровывается и читается

+ в теле каждого запроса хранить его uuid и отправлять тоже, а на сервере смотреть на наличие этого id

Я вижу это так, при авторизации генерировать пару ключей для пользователя, на клиент отправлять публичный, на сервере хранить приватный. Далее все запросы через post и сшифровкой тела запроса. На сервере запрос расшифровывается и читается

Так HTTPS работает )

Заново изобретаете https?

Заново изобретаете https?

+++

Так HTTPS работает )

Я сделаю https внутри https...

Как в знакомом фильме

Тогда его можно упереть с устройства

Если у вас есть доступ к устройству - то да

DH

DH

Диффи-Хелман это ассиметричное шифрование

С приватным и публичным ключом

как бы единственный легальный тут вариант - это подписывать запросы сертами

Ох

Зачем лишняя ебля, если https хватит?

Я в базе храню и deviceid и remoteip и так далее, если все это связать и проверять откуда был отправлен запрос с токеном то можно понять был ли отправитель авторизован

Ты там второй телеграм делаешь?

Зачем лишняя ебля, если https хватит?

человек уверен, что трафик будут митмить

https://pypi.org/project/httpsig/

можете наработки посмотреть

Ты там второй телеграм делаешь?

Почти, корпоративный мессенджер

можете наработки посмотреть

Обязательно завтра посмотрю

Взял бы жаббер

Взял бы жаббер

Не зашёл

Нафига еще один мессенджер?)

У всех имеющихся мессенджеров слишком ограничен функционал

Там речь не только о чате

Многоуровневые обсуждения, группы, подгруппы, движение чатов по дереву и тд

Долго расписывать))

Понятно

Кстати, где-то читал, что телеграмм регенерит ключи шифрования каждые 100 сообщений

У всех имеющихся мессенджеров слишком ограничен функционал

Jabber не ограничивает тебя

У всех имеющихся мессенджеров слишком ограничен функционал

я бы сказал, наоборот, перегружен)

большая часть его нафиг не нужна

тот же слак - это просто ужас

Хотя сама идея слака ничего так

Акулы-людоеды, зомбоапокалипсис, мессенджеры...

Я имею в виду, что нам ничего не подошло, поэтому разрабатываем свой, узконаправленный

Хотя сама идея слака ничего так

"идея слака"? ты имел в виду "спиздить идею IRC"?

Например что не могло подойди в мессендежерах? Наличие функционала отправки самого мессаджа? Я даже в догадках потерялся.

"идея слака"? ты имел в виду "спиздить идею IRC"?

Ну да, именно.

Я имею в виду, что нам ничего не подошло, поэтому разрабатываем свой, узконаправленный

а что именно вам не хватило?

Многоуровневые обсуждения, группы, подгруппы, движение чатов по дереву и тд

вот это все есть в Google/Apache Wave

который никому не нужное говно

Именно в перегрузе функционалом проблема всех мессенджеров (и не только мессенджеров). Чем аскетичнее, тем лучше.

вот это все есть в Google/Apache Wave

Он жив? Хороший был проект. Жаль, невовремя они его сделали, слишком рано.

Открываешь окно, страницу, а там 100500 кнопок. 100500 Карл!!!

Из глаз начинает течь кровь.

Он жив? Хороший был проект. Жаль, невовремя они его сделали, слишком рано.

мне кажется, он мертв с самого начала был

а вот Inbox зря они до ума не доводят

Спокойно встаешь. Идешь на кухню. Берешь в руку вилку и начинаешь выковыривать себе глаза.

мне кажется, он мертв с самого начала был

Ну, нет. Я ещё помню, как инвайт туда получил раньше официального релиза. И пользовался, да. Какое-то время. Но тормозил, даже на моём неслабом компьютере тормозил.

Ну, нет. Я ещё помню, как инвайт туда получил раньше официального релиза. И пользовался, да. Какое-то время. Но тормозил, даже на моём неслабом компьютере тормозил.

все пользовались. Примерно неделю, пока не надоело

по сути, реддиту прикрутить автообновление бранчей комментов в риалтайме...

кстати, фейсбук так уже делает

Может кто-то делает свой фейсбук?

Может кто-то делает свой фейсбук?

кому функциональности не хватило

Пашка сделал)

Хотя у меня есть идея соцсети. Прикольная идея. Но нет возможности реализации.