Dark Hole: вполне себе та, тем паче тут семерка. Вообще если нужно решать задачу фоновой обработки, надо посмотреть в сторону очередей и обработчиков (консьюмеров). Для управления обработчиками использовать supervisor или system.d в зависисмости от конкретной версии ОС.
Victor Alekseev что вы к Мише прицепились, у него все правильно написано :)
Не знаю как сейчас, но вообще у пхп 4 исконных режима работы: модуль веб-сервера, cgi, fastcgi и cli. Fpm - это менеджер процессов, который просто позволяет гибко настривать процессы php под количество запросов (а в качестве протокола fastcgi используется).
>>А можете подсказать, что ещё за варианты работы nginx c обработчиками php
Что вы на крон вешаете или из консоли запускаете - то в cli работает. cgi и mod уже почти никто не использует.
sim3x если у вас не супер-пупер хайлоад можете сейвить в табличку и не париться.
Я имел дело с распределенной архитектурой, пиковыми 3*10^4 rps на нелегкие бекенды и это все спокойно работало через очереди с отдачей id через предварительное сохранение в СУБД.
Если речь про что-то еще большее + ограничение по бюджету, то можно как lega написал. Но там параллельно еще куча вопросов возникнет, станет не до этого) В хайлоадах у кого нормальная архитектура и шардирование, тот и молодец.
fens можно так сделать, но зачем? Минусы, навскидку:
а.) Усложняется отладка и поддержка. Если что-то выбирается не так, понять что не так сложнее. Равно как и объяснить суть схемы не-автору решения.
б.) Отказ от джойнов: вы по-сути описали хранимый запрос, "представление". Обычно в РСУБД представления используют чтобы быстро посмотреть нужную инфу в нужном виде. На уровне бизнес логики в yii это решается как раз джойнами, ибо стандартная функциональность. Смысла пилить велосипед я не вижу, имхо.
>>будет вызывать instantiate у главной модели которая будет возвращать по типу конкретный класс а дальше populate запихнет в модель всю строку ну а модель примет только те поля которые ее
Я так понял вы хотите иметь некое представление где будет все обо всем, а при скармливании данных представления какому-то классу этот класс будет решать, какую конкретную модель вернуть. Хоть тресни, я не вижу каких-то супер-преимуществ у этого подхода. Можно так же через UNION объединить инфу из двух табличек и при необходимости подтягивать общее из справочника.
fens ну наследование - термин из ООП, малоприменимо к РБД, ведь наследуются не конкретные реализации, а классы. Ваша табличка entities напоминает справочник, а таблички с подробностями - суть конкретные данные. Вот я бы на вашем месте и использовал их, а если где-то в логике ПО требуется инфа из справочника - подтягивал бы справочник.
Григорий Васильков можно но https с сильным ключом очень долго расшифровывать.
>>Я думал это не работает, типа сам сервак контроллит уникальность sessid
Сервер контролит уникальность, но не привязку к конкретному юзеру. Какой id ему пришлют, тот он и использует (если существует такой session id). Какой-то защиты "из коробки" нет, поэтому и придумали https, csrf и много чего еще)
Это плохая практика по ряду причин:
1. Опасная, т.к. значение куки PHPSESSID тогда выводится на страницу, что повышает риск session hijacking (угона сессии). Понятно что при нынешней CORS и повсеместном HTTPS риск уменьшается, но не до нуля. Другой вариант: допустим злоумышленник смог получить PHPSESSID, но не может дойти до места генерации формы с токеном (многие крупные ресурсы имеют доп. механизмы защиты, например проверяют если логинятся необычным браузером/из необычного места и т.п.). Если токеном является PHPSESSID, то он сможет отправить форму, зная что она идет в качестве токена.
2. Негибкая, например если вы хотите чтобы токен устаревал быстрее чем обновлялась сессия, PHPSESSID использовать нельзя. То же самое если у вас будет разное время устаревания для разных форм и т.п.
Строго говоря, у CSRF токена нет задачи фильтровать ботов, это больше про безопасность от подделки запросов. Капчу точно не заменит.
P.s.: У капчи есть альтернативы, но это не csrf токен. Можете просто сделать текстовый инпут в форме и скрыть его стилями, боты будут его заполнять, а пользователи - нет, т.к. не увидят. Года три-четыре назад такое хорошо работало, как сейчас не знаю.
Григорий Васильков просто: перед отдачей формы с токеном последний пишется в сессию юзера. При приходе формы от юзера токен сверяется с данными сессии.
Пума Тайланд чет не понял. ТС пишет про 5 мультов юзеров в СУТКИ, вы пишите про нагрузочное тестирование единовременное. По-моему тут сначала надо понять пиковые нагрузки и потом добавить к ним запас процентов двадцать, и от этого отталкиваться, а не от суммы юзеров за сутки.
По поводу слов DevMan - все зависит от того, как вы подключаетесь к интернету.
Если через wifi+собственный компьютер - админ не увидит ничего, пока сами не поставите его сертификаты.
Если через компьютер организации, где у админа админские права и удаленный доступ на вашу машину - админ может все, начиная от установки сертификатов и заканчивая получением скриншотов вашего экрана.
Оптимус Пьян расшифровка происходит на конечных точках, у клиента и у сервера симметричным ключом, о котором они изначально договариваются на этапе рукопожатия.