A007MP: Скрипту на стороне клиента Вы не можете запретить ничего! То есть никто не помешает условно хакеру подменить скрипт (js) и отправлять все, что угодно. Данные обязаны проверяться на сервере каждый раз при получении их от клиента.
Так я описываю скрипт на стороне сервера. Он все проверяет и никакой бяки не допускает.
{status:2,erros:{email:'email already exist',pw:'password is too short'}}
При этом этот скрипт не допускает неправильных действий с данными. Например, нельзя отправить личное сообщение от чужого имени, нельзя изменить данные другого пользователя, если сообщений слишком много, опять же скрипт не даст превысить лимит, ну и так далее.
danforth: Поздравляю, вы открыли SPA. Минусы - скорость разработки. Плюсы - скорость работы. Паттерн, скорее всего, MVVM. Только в стадии зародыша.
Понятно. А что получится, если частично перенести обработку данных от клиента (JS) на сервер (PHP)?
Я поясню: страницы будут все-таки формироваться с помощь PHP на стороне сервера, но связь с БД будет по-прежнему происходить через тот "коннектор", который я описал в стартовом топике (одиночный скрипт, который принимает (POST запрос), обрабатывает и отдает (JSON) данные). На клиенте, конечно, придется оставить некоторый интерактив на JS (например, подсветка неверно заполненных полей, предварительная валидация данных и т.д.).
Кстати, PHP скрипты, расположенные на одном сервере быстро друг с другом взаимодействуют?
Вообще у меня задумка была такая, что бы ВСЕ данные проходили (и В базу и ИЗ базы) через одно место, где бы исключалась любая возможная не корректность. И я бы хотел это в любом случае сохранить.
borisd: Например, если у вас в большинстве случаев по другим параметрам хорошо создаются компактные выборки, то индекс на эти колонки (с малым количеством вариантов) выглядит сомнительным.
Мысль ясна. Однако, юзер может захотеть фильтрануть или поискать и по этим колонкам (с малым количеством возможных вариантов). Я так понимаю, при больших размерах таблицы такие выборки без индексов могут стать проблемой?
Aisamiery: ...Хотя фиг его знает что у вас там за приложение.
Приложение: представьте себе таблицу с параметрами товаров (как я выше писал их сейчас 14), юзер видит эту таблицу у себя в браузере. Юзеру дается возможность фильтровать и/или сортировать по любому столбцу. Я так считаю, что в данном случае на каждый такой столбец нужно по индексу.
1. Помнить о том, что все, что приходит с клиента - не безопасно!
2. Тот процесс что вы описали, все же аутентификация а не авторизация.
3. Аутентификация должна проходить по токенам.
4. Для проверки хешей паролей использовать password_hash() и password_verify(), и никаких ==.
donc: Так индексирует или начинает получать трафик?
Ну меня интересует и то и то, конечно. Но сейчас был вопрос конкретно об индексации. Если есть что добавить по трафу, то, конечно, добавляйте, это тоже очень интересно.
---------- Добавлено 22.01.2017 в 14:49 ----------
fluent: Пардон, проблема с кодировкой
Конечно я имел в виду индексирование
Скрипту на стороне клиента Вы не можете запретить ничего! То есть никто не помешает условно хакеру подменить скрипт (js) и отправлять все, что угодно. Данные обязаны проверяться на сервере каждый раз при получении их от клиента.
Так я описываю скрипт на стороне сервера. Он все проверяет и никакой бяки не допускает.
Про данные через одно место, слишком мало инфы вы дали, чтобы сказать вам, хорошо вы придумали, или плохо.
Тогда расскажу поподробнее. Через это "горло" должны проходить следующие действия:
- регистрация нового пользователя (в ответ - сразу сессия)
- вход (в ответ - сессия)
- изменения данных пользователя (в ответ - данные пользователя после обновления)
- отправка личного сообщения
- чтение личных сообщений
- изменение данных о пользователе и так далее.
На вход этому скрипту поступает массив, например, такого вида
array('function'=>'add_user','name'=>'Роман','email'=>'mail@example.com','pw'=>'blablabla');В ответ идет JSON например такого вида:
{status:2,erros:{email:'email already exist',pw:'password is too short'}}При этом этот скрипт не допускает неправильных действий с данными. Например, нельзя отправить личное сообщение от чужого имени, нельзя изменить данные другого пользователя, если сообщений слишком много, опять же скрипт не даст превысить лимит, ну и так далее.
Поздравляю, вы открыли SPA. Минусы - скорость разработки. Плюсы - скорость работы. Паттерн, скорее всего, MVVM. Только в стадии зародыша.
Понятно. А что получится, если частично перенести обработку данных от клиента (JS) на сервер (PHP)?
Я поясню: страницы будут все-таки формироваться с помощь PHP на стороне сервера, но связь с БД будет по-прежнему происходить через тот "коннектор", который я описал в стартовом топике (одиночный скрипт, который принимает (POST запрос), обрабатывает и отдает (JSON) данные). На клиенте, конечно, придется оставить некоторый интерактив на JS (например, подсветка неверно заполненных полей, предварительная валидация данных и т.д.).
Кстати, PHP скрипты, расположенные на одном сервере быстро друг с другом взаимодействуют?
Вообще у меня задумка была такая, что бы ВСЕ данные проходили (и В базу и ИЗ базы) через одно место, где бы исключалась любая возможная не корректность. И я бы хотел это в любом случае сохранить.
Например, если у вас в большинстве случаев по другим параметрам хорошо создаются компактные выборки, то индекс на эти колонки (с малым количеством вариантов) выглядит сомнительным.
Мысль ясна. Однако, юзер может захотеть фильтрануть или поискать и по этим колонкам (с малым количеством возможных вариантов). Я так понимаю, при больших размерах таблицы такие выборки без индексов могут стать проблемой?
А также почитайте о таком понятии, как cardinality индекса.
Если поле принимает только 2 значения, то индекс ставить на него смысла нету.
Ясно, спасибо! А если не два значения, а, допустим, 6? У меня есть несколько INT колонок с таким количеством вариантов (включая вариант Null).
Про кардиналити почитаю, спасибо!
...Хотя фиг его знает что у вас там за приложение.
Приложение: представьте себе таблицу с параметрами товаров (как я выше писал их сейчас 14), юзер видит эту таблицу у себя в браузере. Юзеру дается возможность фильтровать и/или сортировать по любому столбцу. Я так считаю, что в данном случае на каждый такой столбец нужно по индексу.
http://php.net/manual/ru/faq.passwords.php - вот тут написано
Спасибо за ссылочки! Обе очень полезные и познавательные!
---------- Добавлено 23.01.2017 в 15:20 ----------
если коротко, то тут неплохо изложено http://getjump.me/ru-php-the-right-way/#Безопасность
Спасибо большое!
Более-менее правильно.
1. Помнить о том, что все, что приходит с клиента - не безопасно!
2. Тот процесс что вы описали, все же аутентификация а не авторизация.
3. Аутентификация должна проходить по токенам.
4. Для проверки хешей паролей использовать password_hash() и password_verify(), и никаких ==.
Ещё про http://www.php-fig.org/psr/psr-7/ можете почитать.
2. Да, пожалуй, аутентификация. Не задумывался о таких тонкостях.
3. Вы пишете "Аутентификация должна проходить по токенам" - вы не поясните что вы имеете в виду? Что за токены?
4. Пробежался по мануалам этих функций и что-то не уловил чем это может быть луче md5(), например?
Появится мгновенно.
Иногда случается что новая страница никак не принимается.
У меня так, а как у Вас не знаю
Мгновенно - это какая-то фантастика, по-моему.
В моей (правда, довольно небольшой) практике такого никогда не было.
Так индексирует или начинает получать трафик?
Ну меня интересует и то и то, конечно. Но сейчас был вопрос конкретно об индексации. Если есть что добавить по трафу, то, конечно, добавляйте, это тоже очень интересно.
---------- Добавлено 22.01.2017 в 14:49 ----------
Пардон, проблема с кодировкой
Конечно я имел в виду индексирование
А перевод остальных двух строчек? ;)