Так я описываю скрипт на стороне сервера. Он все проверяет и никакой бяки не допускает.
Тогда расскажу поподробнее. Через это "горло" должны проходить следующие действия:
- регистрация нового пользователя (в ответ - сразу сессия)
- вход (в ответ - сессия)
- изменения данных пользователя (в ответ - данные пользователя после обновления)
- отправка личного сообщения
- чтение личных сообщений
- изменение данных о пользователе и так далее.
На вход этому скрипту поступает массив, например, такого вида
array('function'=>'add_user','name'=>'Роман','email'=>'mail@example.com','pw'=>'blablabla');
В ответ идет JSON например такого вида:
{status:2,erros:{email:'email already exist',pw:'password is too short'}}
При этом этот скрипт не допускает неправильных действий с данными. Например, нельзя отправить личное сообщение от чужого имени, нельзя изменить данные другого пользователя, если сообщений слишком много, опять же скрипт не даст превысить лимит, ну и так далее.
Понятно. А что получится, если частично перенести обработку данных от клиента (JS) на сервер (PHP)?
Я поясню: страницы будут все-таки формироваться с помощь PHP на стороне сервера, но связь с БД будет по-прежнему происходить через тот "коннектор", который я описал в стартовом топике (одиночный скрипт, который принимает (POST запрос), обрабатывает и отдает (JSON) данные). На клиенте, конечно, придется оставить некоторый интерактив на JS (например, подсветка неверно заполненных полей, предварительная валидация данных и т.д.).
Кстати, PHP скрипты, расположенные на одном сервере быстро друг с другом взаимодействуют?
Вообще у меня задумка была такая, что бы ВСЕ данные проходили (и В базу и ИЗ базы) через одно место, где бы исключалась любая возможная не корректность. И я бы хотел это в любом случае сохранить.
Мысль ясна. Однако, юзер может захотеть фильтрануть или поискать и по этим колонкам (с малым количеством возможных вариантов). Я так понимаю, при больших размерах таблицы такие выборки без индексов могут стать проблемой?
Ясно, спасибо! А если не два значения, а, допустим, 6? У меня есть несколько INT колонок с таким количеством вариантов (включая вариант Null).
Про кардиналити почитаю, спасибо!
Приложение: представьте себе таблицу с параметрами товаров (как я выше писал их сейчас 14), юзер видит эту таблицу у себя в браузере. Юзеру дается возможность фильтровать и/или сортировать по любому столбцу. Я так считаю, что в данном случае на каждый такой столбец нужно по индексу.
Спасибо за ссылочки! Обе очень полезные и познавательные!---------- Добавлено 23.01.2017 в 15:20 ----------
Спасибо большое!
2. Да, пожалуй, аутентификация. Не задумывался о таких тонкостях.
3. Вы пишете "Аутентификация должна проходить по токенам" - вы не поясните что вы имеете в виду? Что за токены?
4. Пробежался по мануалам этих функций и что-то не уловил чем это может быть луче md5(), например?
Мгновенно - это какая-то фантастика, по-моему.
В моей (правда, довольно небольшой) практике такого никогда не было.
Ну меня интересует и то и то, конечно. Но сейчас был вопрос конкретно об индексации. Если есть что добавить по трафу, то, конечно, добавляйте, это тоже очень интересно.---------- Добавлено 22.01.2017 в 14:49 ----------
А перевод остальных двух строчек? ;)
