можно правки кода запихивать в шаблон для того, чтобы не слетали при обновлении. Не в саму разметку, а также папка создаётся для компонента и туда вставляются файлы для подмены.
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 от всех клиентов.
Al: еще забыл, по предотвращению повторных запросов:
1. Создаёте таблицу исторических запросов к API и логируйте каждый запрос, затем - проверяете по ней уникальность. (лучше, но медленнее)
2. ИЛИ/И Привязывайте сессию (токен) к IP-адресу клиента (хуже, но быстрее).
Лучше - сразу оба метода использовать.
Ну и всё это (весь обмен данными) - лучше шифровать данными авторизации/токеном.
А уже после - обернуть в SSL.
Al: мда... смотрите:
hash - это подпись Вашего запроса (аналог того, как Вы ставите подпись ручкой в документе).
То, под чем Вы расписываетесь - это параметры.
Чтобы проверить, что запрос к API выполнили именно Вы, передаёте на сервер:
параметр1,..,параметрN, hash, token, timestamp, random - вот эти параметры - передаются все в открытом виде (т.е. как есть)!
Пример формулы (*) формирования HASH на клиенте: HASH=md5(параметр1.параметрN.token.timestamp.random.password)
password - сервер знает и пересылать его не нужно!
Сервер получает этот запрос и сверяет время timestamp со своим серверным: что запрос не просрочен более, чем на сутки. (можно еще записывать в таблицу вызовов API и проверять уникальность запроса по HASH+token и частоту обращений к API, если это необходимо)
И после базовой проверки - проверяет HASH:
Берёт все параметры и создаёт HASH у себя по той же самой формуле (*) из присланных параметров и получает свой вариант SHASH (server-hash).
Затем - сравнивает абсолютно: if (HASH===SHASH) => если да: значит исполняет запрос, нет - генерит ошибку.
