что серверу мы вроде как это подсунем тот же хеш, что и поймали
А я говорил про то, чтобы сам пароль был захешированным.
Почему Вы так упорно не хотите, чтобы пароль был не в хешированном виде, уходя от пользователя на сервер?
Это защищает пользователя от "утечки" открытого пароля (plain text) через "прослушку" сети и на стороне сервера: при возможной утечки БД.
Это намного лучше, чем отправка в plain text! Чтобы было "по-проще ловить" - можно использовать "примесь": рандомную вставку случайных символов в случайные позиции. И это уже будет вообще нереально восстановить, а сервер - спокойно проверит.
Соль нужна всегда, если хеширует клиент (думал, что это и так очевидно!)
тем, что пароль будет сложно восстановить как при перехвате запроса, так и при хищении БД сервера.
Там никогда не используется реальное ID, потому что ID зависит от контекста использования (какая интеграция и с каким сервисом)
И поверьте, этот хардкод будет одной из наименьших проблем в проекте - мы даже не знаем, с чего начинать рефакторинг, а надо и фичи пилить )
в таблице заказчик будет id заказчика и через цикл перебором он будет искать этот же id в другой таблице и подставлять значения при совпадении, либо сделать связь через внешний ключ
App это разновидность Error?
именно так, он также используется для реализации интерфейса Throwable
любой голый фреймворк генерит у меня страницу примерно 0.1 сек, у меня авторизованный скрипт с примерно около десятка запросов генерит страницу за 0.005, да мне и не нужен фв на 50 мегабайт, у меня скрипт весь с графикой около 5-ти мег
class App extends Error - На человеческий переводится как мой App сплошной Error.
установил бы какой-либо из популярных фреймворков
тяжёлые, про фалкон читал, но не вникал сильно
show create table routes
EXPLAIN SELECT * FROM routes WHERE archive = 1 AND created >= '2020-01-01 00:00:00';