можно правки кода запихивать в шаблон для того, чтобы не слетали при обновлении. Не в саму разметку, а также папка создаётся для компонента и туда вставляются файлы для подмены.
Al: мы ВООБЩЕ НИКОГДА не пересылаем password на сервер!
Мы пересылаем только HASH и все остальные параметры!
На сервере мы никогда не сверяем отдельно хэши, содержащие учётные данные, т.к. мы НЕ ПЕРЕДАЁМ ИХ!
Сверяются только общие хэши: HASH (где мы берём от клиента все параметры, кроме password) и SHASH (где password - берём из БД).
Al: пароль на клиенте - лучше НИКОГДА не хранить! Хранить только TOKEN АВТОРИЗАЦИИ! Если сервер сказал, что TOKEN просрочен/недействителен - выдавать диалог пользователю на ввод учётных данных.
Al: password = это хэш учётных данных пользователя! Понимаете, что сервер может не знать Ваше имя пользователя и Ваш пароль) Он может лишь знать Ваш ID и HPASS=password = hash(login.pass.SALT). А SALT ("соль") - единый для всего у сервера.
В итоге, в базе - нельзя понять соответствие аккаунта и пароля к нему тогда, когда стащат базу!)
Т.е. 2 таблицы: AUTH и USERS.
В AUTH - храним ID и HPASS (тот, что у нас в обсуждении: password)
В USERS - храним ID, username, firstname, lastname и т.д.
После прохождения авторизации - работаем только с таблицей USERS.
Пароль в сессии (пусть и парольный хэш) - хранить смысла нет: получили из базы, проверили и сразу забыли.
Al: добавка: при АНОНИМНОМ доступе к API Вы сможете лимитировать только по IP-адресу! (по токену - уже не сможете, т.к. его не к чему привязать на сервере: нет уникальной учётки => нельзя идентифицировать конкретного клиента!)
