А скажите, пожалуйста, так как вы уже писали триггеры на таблицу, почему не написали триггер на DELETE, в котором можно было удаляемые данные отсаживать в другую таблицу. Плюс в том, что программа остаётся со своей структурой, а вы получаете полную свою таблицу.
А вот ещё вопрос: если хочется валидировать параметры, почему бы не воспользоваться всей мощью АОР, да и написать реальный обработчик таких ситуаций. А функцию валидации можно передать через класс в @Validated.
Смешались кони, люди… Зачем смешивать авторизацию и контроль входных данных?
Кстати спрнг для вашего решения имеет стандарт: @PreAuthorize, @PostAuthorize и даже фильтрации данных @PreFilter и @PostFilter. Для них тоже прекрасно пишутся свои функции контроля. И соответственно в коде отделяется бизнес логика от секюрити логики.
Кстати, заметили ли вы что -5 (один ответ) и -7(другой) дают -12?
Если не привлекать циферблаты и куда крутить то можно объяснить так:
Классическое определение деления с остатком: a = b*q + r, где r — и есть остаток.
Для положительных чисел это формула тривиальна: b*q меньше a. А вот для отрицательных возникает вопрос — каким должен быть b*q — меньше? Так если меньше тогда абсолютное значение b*q больше, чем a и остаток всегда будет положительным.
Разные языки программирования\системы используют оба варианта реализации.
Извиняюсь, может я не внимательно читал. Мне показалось, что сначала был алгоритм, а потом придумка, где его можно использовать.
Тогда замечание — удаляя приватный ключ вы больше не сможете подтвердить свою идентичность, и кто угодно сворует ваш ид с открытым ключом и скажет что это его. Так даже воровать ничего не нужно — ну есть двоичные данные, ну и что, что у них структура какая то подпись и какой-то ключ, без закрытого ключа никто не сможет единолично подтвердить акт генерации именно им этих двоичных данных.
У вас нет совпадений, так как у вас не проблемы, которую нужно решить.
Насколько я понимаю, вас увлекло свойство открытого\закрытого ключа. Ну так в книжке куча таких-же увлекательных алгоритмов — вам будет интересно.
Мир криптографии на открытом/закрытом ключе не заканчивается. Есть куча разных алгоритмов. Как насчёт почитать книжку Applied Cryptography — очень интересное чтиво.
А скажите, пожалуйста, так как вы уже писали триггеры на таблицу, почему не написали триггер на DELETE, в котором можно было удаляемые данные отсаживать в другую таблицу. Плюс в том, что программа остаётся со своей структурой, а вы получаете полную свою таблицу.
Кстати может и обучать стоит на фильмах — там как раз кадры будут одинаковые с разной засветкой.
Смешались кони, люди… Зачем смешивать авторизацию и контроль входных данных?
Кстати спрнг для вашего решения имеет стандарт: @PreAuthorize, @PostAuthorize и даже фильтрации данных @PreFilter и @PostFilter. Для них тоже прекрасно пишутся свои функции контроля. И соответственно в коде отделяется бизнес логика от секюрити логики.
Если не привлекать циферблаты и куда крутить то можно объяснить так:
Классическое определение деления с остатком: a = b*q + r, где r — и есть остаток.
Для положительных чисел это формула тривиальна: b*q меньше a. А вот для отрицательных возникает вопрос — каким должен быть b*q — меньше? Так если меньше тогда абсолютное значение b*q больше, чем a и остаток всегда будет положительным.
Разные языки программирования\системы используют оба варианта реализации.
Вы не можете подписать старым ключём -вы убили приватный ключ — вы помните? ;)
Как можно дальше общаться с пицерией, если вы не сможете больше подписать ни одной команды со старым ключём/ид.
И кто тут «я», который присылает команду на два пива? Может это спам? Подтвердите, что вы это вы а не злой хакер Вася Пупкин! :)
После уничтожения закрытого ключа вы не сможете подтвердить в будущем что вы это вы и ваша подпись и открытый ключ превращаются просто в двоичный шум.
Теоретически сейчас вы шлёте команду и двоичный шум.
Тогда замечание — удаляя приватный ключ вы больше не сможете подтвердить свою идентичность, и кто угодно сворует ваш ид с открытым ключом и скажет что это его. Так даже воровать ничего не нужно — ну есть двоичные данные, ну и что, что у них структура какая то подпись и какой-то ключ, без закрытого ключа никто не сможет единолично подтвердить акт генерации именно им этих двоичных данных.
Насколько я понимаю, вас увлекло свойство открытого\закрытого ключа. Ну так в книжке куча таких-же увлекательных алгоритмов — вам будет интересно.