| |||||||||
| |||||||||
bikerx:
Подскажите, возможно ли в данной версии CMS организовать торговую площадку?
Что бы зарегистрированный пользователь, входящий в определенную группу, мог создать свой магазин, наполнить его товарами и при заказе получать уведомление в личку, ну как то так.
Что бы зарегистрированный пользователь, входящий в определенную группу, мог создать свой магазин, наполнить его товарами и при заказе получать уведомление в личку, ну как то так.
Это называется SAAS решение. можно, но нужен отдельный сервер, а то и несколько и 1-2 администратора. А также написать серверный софт (возможно на PHP, для создания пользовательской директории и развертывания EWC, самое главное - изоляция пользователя от других)
Просьба также не засорять тему апдейтов конкретной венрсии, а заводить новые в поддержке пользователей.
Просьба также не засорять тему апдейтов конкретной венрсии, а заводить новые в поддержке пользователей.
Как то все слишком сложно, зачем!
Мне все видится немножко проще, система типа как при создании ветки форума, админ назначает модератора который может редактировать определенные темы. Так и здесь админ создает категорию, она же магазин и назначает модера, он же продавец.
Таким же образом можно и дать пользователям вести свой блог или фото галерею.
Конечно я могу не понимать всей сложности процесса, поэтому это просто мысли в слух, или идеи на будущее.
Ну вот почему цитата admina получилась кривой, почему видно код? Нет ну с форумом надо что то решать, не солидно!
дело в том что модерский доступ к CMS позволяет редактировать шаблоны, куда можно внедрить код шелла PHP, или вирус.
а можно в товар вставить Javas c r i p t, угоняющий куки (админа) к примеру.
Через редактирование статьи (TinyMCE) можно отредактировать любой файл и получить доступ к любому файлу, в том числе к данным админа в папке userstat/admin.txt (причем даже из соседних папок)
так что ... только полная изоляция юзерских магазинов методами серверно-админскими
а можно в товар вставить Javas c r i p t, угоняющий куки (админа) к примеру.
Через редактирование статьи (TinyMCE) можно отредактировать любой файл и получить доступ к любому файлу, в том числе к данным админа в папке userstat/admin.txt (причем даже из соседних папок)
так что ... только полная изоляция юзерских магазинов методами серверно-админскими
Модерский доступ я взял только для примера, ведь можно создать группу допустим "Торговцы" со своими правами, картинки допустим разрешить подгружать по ссылке с сервисов. Визуальные редакторы тоже на сколько знаю можно ограничивать доступом, оставлять только те функции которые безопасны.
К сожалению права администратора настолько широки, что сделать из него торговцев с ограниченными правами - не получится, к тому же я не так параноидально проверяю отправляемые админом данные, как проверяю у простых юзеров, поэтому все равно найдут лазейку куда шелл воткнуть или JS для угонов кук.
Движок рассчитан на благоразумных админов, без вредительских целей.
По другому администрирование магазина невозможно, без редактора карточек товара, загрузки фото в галерею и прочее.
Админ может шелл качнуть просто загрузив фото в галерею, так как фотки при загрузке не изменяются и вредоносный код не обрежется.
добавление юзеров типа торговец потребует модернизации ВСЕХ модулей. Эти затраты обойдуться дороже и по времени дольше чем нормальное SAAS решение изолированных виртуальных директорий.
Движок рассчитан на благоразумных админов, без вредительских целей.
По другому администрирование магазина невозможно, без редактора карточек товара, загрузки фото в галерею и прочее.
Админ может шелл качнуть просто загрузив фото в галерею, так как фотки при загрузке не изменяются и вредоносный код не обрежется.
добавление юзеров типа торговец потребует модернизации ВСЕХ модулей. Эти затраты обойдуться дороже и по времени дольше чем нормальное SAAS решение изолированных виртуальных директорий.
Вот сварганил идеальную схему.
www.eurowebcart.ru
без двух нижних серверов можно обойтись, если не планируется сводить в единую базу товары всех магазов.
www.eurowebcart.ru
без двух нижних серверов можно обойтись, если не планируется сводить в единую базу товары всех магазов.
Идея интересна, но это все больше подходит для большого и дорогого проекта типа PROM и прочих.
А я говорил о более простом решении, что больше похожее на доску объявлений, только навороченную.
А я говорил о более простом решении, что больше похожее на доску объявлений, только навороченную.
Такой вопрос. Нужно создать пользователя, к примеру "manager" с правами редактирования карточек товаров. Ближайший я так понимаю хоть и с намного большими возможностями это "moder" (или есть еще ктото более урезанный?)Но чтобы редактировать карточки нужно иметь доступ к папке ../admin. Как вариант это заведение отдельного "userpassword" для папки ../admin никак не фигурирующего в пользователях. А можно ли добавить в файл /admin/.htpasswd двух пользователей, к примеру:
admin:хеш проля
manager:хеш пароля
будет ли корректно отрабатываться?
или есть другие еще варианты?
admin:хеш проля
manager:хеш пароля
будет ли корректно отрабатываться?
или есть другие еще варианты?
я бы сделал по другому
создать директорию admin2
в ней .htacccess и только необходимые модули из ./admin как копия или через require, посмотрите как сделано в директории /blogger и тогда не надо давать статус MODER, хоть простой юзер. в админской директории права не проверяются.
создать директорию admin2
в ней .htacccess и только необходимые модули из ./admin как копия или через require, посмотрите как сделано в директории /blogger и тогда не надо давать статус MODER, хоть простой юзер. в админской директории права не проверяются.
1. htacccess и htpasswd под restricted создать?
2. с ходу не нашел где в коде определена привязка роли blogger к папке ./blogger/ Чтобы по аналогии привязать конкретного пользователя к папке или роль employee
2. с ходу не нашел где в коде определена привязка роли blogger к папке ./blogger/ Чтобы по аналогии привязать конкретного пользователя к папке или роль employee
1. да.
2. привязывать не надо, дайте доступ к папке и ссылку к админу товаров admin2/index.php для редактирования edit.php и т.п. не надо давать доступ к полной админке и статусу ADMIN, только к самому необходимому.
2. привязывать не надо, дайте доступ к папке и ссылку к админу товаров admin2/index.php для редактирования edit.php и т.п. не надо давать доступ к полной админке и статусу ADMIN, только к самому необходимому.
я правильно тогда понял?, что если просто скопировать нужные файлы в admin2:
и заменить в путях "./" на "$htpath/admin/" (ну и где необходимо admin/ на admin2/, то возникает тогда ограничение только на индексацию товаров, что связано с записью, к примеру файлика ./search/$numo.txt в папку admin/.
и решение тогда indexator.php убрать а в header.inc вызывать его через require?
change.php
clone.php
edit.php
footer.inc
header.inc
index.php
indexator.php
new_item.php
newgal.php
clone.php
edit.php
footer.inc
header.inc
index.php
indexator.php
new_item.php
newgal.php
и заменить в путях "./" на "$htpath/admin/" (ну и где необходимо admin/ на admin2/, то возникает тогда ограничение только на индексацию товаров, что связано с записью, к примеру файлика ./search/$numo.txt в папку admin/.
и решение тогда indexator.php убрать а в header.inc вызывать его через require?
Вроде вообще не надо ничего менять. там все пути относительные по отношению к этой директории.
индексатор можно не копировать, а вставить его в крон, он сам будет пускаться, тогда после забивки товаров надо объяснить модераторам, что надо дождаться автоматической индексации.
я вообще думал, что можно сделать встроенный планировщик, чисто на доступе к сайту и проверки времени... но если есть крон, то лучше сделать через него.
индексатор можно не копировать, а вставить его в крон, он сам будет пускаться, тогда после забивки товаров надо объяснить модераторам, что надо дождаться автоматической индексации.
я вообще думал, что можно сделать встроенный планировщик, чисто на доступе к сайту и проверки времени... но если есть крон, то лучше сделать через него.