Ситуация
У меня очень сжатое расписание для написания простого (в основном только для записи веб-приложения). Приложение должно быть в основном управляемым jQuery деревом вопросов. Вопросы и дерево, вероятно, потребуется изменить как до, так и после запуска сайта.
Ответы будут отправлены по электронной почте ... Мне, вероятно, даже не нужно их хранить, но я собираюсь на всякий случай.
Это должно быть запущено на общем хосте в очень короткие сроки.
Моя предложенная стратегия
Само дерево вопросов
Реализация дерева вопросов и проверки в основном в jQuery и HTML. Сохраняйте состояние вопроса-ответа в виде объекта javascript, в котором в качестве формата каждого вопроса используется «Текст вопроса»: «Ответ на вопрос».
Проверка формы будет осуществляться только на основе jQuery, без проверки на стороне сервера отдельных полей, кроме (как упоминалось позже), обеспечивающей вставку только действительного JSON.
Идентификация пользователя
Обработка состояния сеанса с помощью PHP, использование идентификатора сеанса PHP в качестве уникального ключа для каждого пользователя.
После ответа на каждый вопрос сделайте простой AJAX-вызов очень простого сценария PHP, который принимает идентификатор сеанса PHP и повторную установку объекта в формате JSON. (Причина для отправки его каждый раз такова, что если пользователь прекращает отвечать на вопросы, по крайней мере, мы получаем НЕКОТОРЫЕ данные.)
Хранение
Хранилище обрабатывается в (встроенном php) БД SQLite следующим образом:
CREATE TABLE q_and_a_storage (
php_session_id text primary key,
json_storage text
);
Сторона сервера
Сценарий получения PHP AJAX очень тупой. Он просто проверяет базу данных, чтобы увидеть, существует ли идентификатор сеанса, а затем вставляет или обновляет, в зависимости от ситуации. Это также гарантирует, что ответ является допустимым JSON перед вставкой.
Я просто хочу знать, невероятно ли это безрассудно или разумно. Есть ли какая-то большая дыра в безопасности, о которой я не думаю?
Вещи, которые люди захотят узнать:
- В этой итерации я оцениваю менее миллиона заполнителей формы
- Все, что нам действительно нужно сделать, это убедиться, что мы отправили первоначальное электронное письмо с данными, но я сохраняю их на всякий случай
- ОЧЕНЬ вероятно, мне придется перенастроить набор вопросов, и у меня почти нет возможности узнать, какие вопросы должны идти, а какие должны остаться.
- Если мне понадобится более поздний анализ данных, я могу позже отправить их в CouchDB и выполнить сопоставление / сокращение запросов к ним, поэтому эта модель привлекательна для меня.
- Это похоже на то, что отправка только формы javascript удерживает большинство спама, и единственное преимущество атаки - бесполезный JSON, хранящийся в БД.
- Сверхбыстрое время разработки и гибкость набора вопросов - это действительно важные факторы.