MS
Ну тоже не двойной вызов просто. Одинарного хватает.
да, я понял
Size: a a a
2021 March 26
MS
еще ключи тоже, добавлю
DP
короче:
приложение1 генерирует ссылку (на приложение2) и отправляет её человеку
приложение2 проверяет параметры и подпись, если подпись хорошая, идем дальше
приложение1 генерирует ссылку (на приложение2) и отправляет её человеку
приложение2 проверяет параметры и подпись, если подпись хорошая, идем дальше
Подпись чьих?
DP
просто на приложении1 шифруешь параметры квери публичным ключом, кладешь первые 32 байта в урлу
в приложении2 повторно шифруешь полученные параметры квери и проверяешь что первые 32 байта совпадают.
Я не уверен что хеш алгоритмы тут сработают лучше, хотя они обладают тем же эффектом
в приложении2 повторно шифруешь полученные параметры квери и проверяешь что первые 32 байта совпадают.
Я не уверен что хеш алгоритмы тут сработают лучше, хотя они обладают тем же эффектом
У тебя это не публичный ключ получается. Потому что если его опубликовать то будет беда
DP
Вообще решение это цифровая подпись например
IC
Вообще решение это цифровая подпись например
Jwt подписанный сертификатом сервера?
DP
Jwt подписанный сертификатом сервера?
Ну в ссылку jwt сувать такое
DP
Длинно будет
DP
Еще придется энкодить, еще длиннее
IC
Длинно будет
Надо в боди
DP
Дак он же ссылку говорит
DP
Какие там боди
AH
У тебя это не публичный ключ получается. Потому что если его опубликовать то будет беда
Публичный ключ шифрует. Все я ок написал
AH
Тут даже не публик прайват нужен, а просто ключ
AH
Потому что оба сервера по идее в трастед енварйнмент. Им только надо убедиться что чувак посередине (клиент) не поменял ссылку
DP
Публичный ключ шифрует. Все я ок написал
"В приложении два повторно шифруешь"?
DP
Тогда тебе придется для каждоого сайта свой ключ использовать
DP
Проще цифровой подпись делать
AH
"В приложении два повторно шифруешь"?
Да. Это просто ключ, некий секрет известный обоим серверам
DP
Да. Это просто ключ, некий секрет известный обоим серверам
Если известный обоим то это не публичный ключ)