можно правки кода запихивать в шаблон для того, чтобы не слетали при обновлении. Не в саму разметку, а также папка создаётся для компонента и туда вставляются файлы для подмены.
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-адресу! (по токену - уже не сможете, т.к. его не к чему привязать на сервере: нет уникальной учётки => нельзя идентифицировать конкретного клиента!)
Al:
1. да, параметры API
2. да
3. password - это учётка юзера, например md5(login+pass), для авторизации
4. да, мы шлём ВСЕ параметры, кроме password
5. да, см. п.4
6. если пароль для всех клиентов одинаков (или он пустой), значит вы используете АНОНИМНЫЙ ДОСТУП, но обычно к API выдаются учётные данные для каждого клиента по-отдельности.
Если доступ к API - АНОНИМНЫЙ, то необходимо получить SKEY (который и будет тем же password-ом на клиенте) от сервера заранее или при авторизации.
SKEY - генерится сервером любым известным только серверу алгоритмом (случайным или НЕ случайным - неизвестно: можно сделать как угодно).
Только тогда обязательно нужно вводить время жизни токена (и делать его по-меньше: сутки достаточно), привязку токена к IP и контроль уникальности ВСЕХ запросов - тут однозначно ЕДИНАЯ историческая таблица запросов к API от всех клиентов.
Как понять фразу: "Вложенные теги не беря в учет." ?!