Обновление сайта — каждый четверг в 12:00 по московскому времени.
Иными словами - у тебя есть на самом сайте: 1. workflow с накоплением очереди. И обработка очереди заявок раз в сутки, изменяющая статический контент базы и отображения сайта раз в сутки. 2. onclick="acquire_contacts(arguments[0]) - на что выдаётся всё равно статический (в смысле содержимого базы) результат. 3. Генератор workflow с личными кабинетами.
Если бы это реализовывалось в "правильной" парадигме - поект состоял бы из: - юзера nobody, которому отдаётся контент только на чтение приложением /home/nobody/app_read_site с владельцем nobody и правами 0100 (права на каталоге /home/nobody 500), от статик html отличается только наличием отдаваемого по acquire_contacts - инструментов администрирования сайта /root/app_admin с правами (грубо говоря - на слабой машине с единственным сайтом почему бы так и не сделать) root - частей личного кабинета для каждого заведённого пользователя - .../userapp_money и .../userapp_zayavka - которые исполняются от имени пользователей user_nnnnn и в конечном итоге атомарно генерят элементы в единственной доступной этой группе пользователей на добавление элементов таблице базы данных - queue (как реализуемой - а пофиг, хоть в сислог писать, а при логротейт обрабатывать). А все контактные данные, тексты, доступные этому узеру на свободное изменение - лежат и меняются прямо в домашнем каталоге /home/user_nnnnn пользователя.
ВСЕ действия на запись в таблицы, кроме той, что очередь заявок - из кода админки.
http тут, https, ssh, rsync... а не так уж и важно какой протокол. В правильной парадигме - залогиненный всегда остаётся в рамках своего домашнего каталога с данными и ограниченного набора кода, каким бы он ни был и НА КАКОМ БЫ (вплоть до компилируемых) языке ни был написан.
no subject
Обновление сайта — каждый четверг в 12:00 по московскому времени.
Иными словами - у тебя есть на самом сайте:
1. workflow с накоплением очереди.
И обработка очереди заявок раз в сутки, изменяющая статический контент базы и отображения сайта раз в сутки.
2. onclick="acquire_contacts(arguments[0]) - на что выдаётся всё равно статический (в смысле содержимого базы) результат.
3. Генератор workflow с личными кабинетами.
Если бы это реализовывалось в "правильной" парадигме - поект состоял бы из:
- юзера nobody, которому отдаётся контент только на чтение приложением /home/nobody/app_read_site с владельцем nobody и правами 0100 (права на каталоге /home/nobody 500), от статик html отличается только наличием отдаваемого по acquire_contacts
- инструментов администрирования сайта /root/app_admin с правами (грубо говоря - на слабой машине с единственным сайтом почему бы так и не сделать) root
- частей личного кабинета для каждого заведённого пользователя - .../userapp_money и .../userapp_zayavka - которые исполняются от имени пользователей user_nnnnn и в конечном итоге атомарно генерят элементы в единственной доступной этой группе пользователей на добавление элементов таблице базы данных - queue (как реализуемой - а пофиг, хоть в сислог писать, а при логротейт обрабатывать). А все контактные данные, тексты, доступные этому узеру на свободное изменение - лежат и меняются прямо в домашнем каталоге /home/user_nnnnn пользователя.
ВСЕ действия на запись в таблицы, кроме той, что очередь заявок - из кода админки.
http тут, https, ssh, rsync... а не так уж и важно какой протокол.
В правильной парадигме - залогиненный всегда остаётся в рамках своего домашнего каталога с данными и ограниченного набора кода, каким бы он ни был и НА КАКОМ БЫ (вплоть до компилируемых) языке ни был написан.