Дмитрий: Допустим есть пользователь 1 и секретный ключ со значением qwerty.
Пользователь делает запрос в апи, передавая туда явно аргументы запроса, и хеш на основе секретного ключа и аргументов. На сервере на основе user_id, аргументов и значения секретного ключа из базы - строится заново хеш и проверяется с присланным.
По факту это означает что секретный ключ не передается от клиента к API вообще никогда, так что даже в случае компрометации запроса - делать другие запросы от клиента к API не получится.
А если к формуле расчета хеша добавить еще и формулу на основе времени например - получается вообще хорошо
jacksparrow: запрос в теле пост при наличии https исключает возможность атаки man in the middle. Если запросы к API предполагаются с мобильных приложений например - это весьма актуально.
в рамках оффтопика - а зачем вообще изменять историю коммитов? мы вот специально перешли на меркуриал именно потому что в нем а) нет возможности удалить коммит б) в истории коммитов хранится к какой ветке он относится - очень удобно потом смотреть кто что когда делал
Дмитрий: что значит "если не считать"? Id по определению должен быть уникальным, в этом весь смысл реляционных баз данных. Уникальность эту вы дополнительно гарантируете primary и unique ключами + логикой приложения / запросов.
Не нужно искать в НФ какой то сакральный смысл, это общий common sense облаченный в строгие формулировки.
Так что ответ - если уникальность id в данной таблице уже есть - то таблица УЖЕ соответствует НФ1
sl1m_dogg п2 - покажите конкретно что у вас написано в namespace и в class файла tasks/task3/Grammar.php. от чего он экстендится к делу отношения не имеет
Дмитрий Ковальский: В целом то что написал Антон Щербаков с поправкой на красивости в виде объектной обертки делает абсолютно любой конструктор запросов в большинстве языков программирования.
Но для решения через хранимые процедуры - Ваше решение безусловно правильное, хотя и не берусь судить как себя mssql тут будет вести с использованием индексов.
PaulMaly: это вопрос терминологии. https://ru.wikipedia.org/wiki/%D0%92%D0%B5%D0%B1-%...
"Веб-приложение — клиент-серверное приложение, в котором клиентом выступает браузер, а сервером — веб-сервер." Никаких упоминаний толстых клиентов в определении веб-приложения нет.
Судя по ответам остальных людей - так думаю не только я.
PaulMaly: у Вас тег стоит "веб-разработка". Фреймворки бывают как бекенд, так и фронтенд, а приложением часто называют весь сервис в совокупности. Так что уточняйте что Вам именно фронт нужен)
