Организация закрытой зоны на сайте

scorpion-ds

Новичок
Организация закрытой зоны на сайте

Уже в течение года я с еще одним разработчиком разрабатываю CMS. Одна из функций организовать закрытую зону сайта. То есть часть страниц сайта должна быть доступна только после регистрации и авторизации на сайте.
На теперешний момент это организовано так:
Пользователь после регистрации добавляется в общую таблицу пользователей, и ему назначается одна из групп по умолчанию. После этого администратор может назначить ему другую группу.
В свою очередь у каждой группы пользователей есть уровень доступа к сайту, он может просматривать общие страницы, если есть права то может просматривать и страницы закрытой зоны, может быть доступ к АЦ, по АЦ тоже есть разделение уровня доступа к объектам (к примеру: новости, голосовалки, каталог продукции, настройкам системы и т.п.), некоторые пользователи могу иметь права на редактирование некоторых страниц сайта или всех.
Все это реализовано на уровне ядра системы, и, по сути, есть неотъемлемой частью CMS, если конечный заказчик не хочет иметь закрытую зону на сайте (без закрытой зоны сайт дешевле), то я ставлю все настройки закрытой зоны по умолчанию и убираю всякое упоминание о ней в шаблонах АЦ и сайта.

Но новый начальник (работает только две недели) убеждает меня, что я действую не правильно, и хочет, что бы я сделал следующие:
Создал две таблицы пользователей, в первую помещались бы пользователи имеющие доступ в АЦ, а во вторую пользователи которые регистрируются через сайт и полностью раздели их управление на сайте, доводы такие:
1. Пользователи, которые регистрируются на сайте, не смогут использовать такого имени, какое потом вдруг захочет себе взять администратор. При этом учетная запись для АЦ должна подходить и к закрытой зоне.
2. «Физическое разделение» (в разных таблицах БД) пользователей для АЦ и закрытой зоны более удобно. Хотя я предложил, что могу просто разработать отельный интерфейс управления пользователями закрытой зоны, но это я так понял, не устраивает.
3. Использование дополнительных полей для пользователей, которые регистрируются для закрытой зоны (был пример про цвет глаз и т.п.).
4. Две таблицы взломать сложней, чем одну.
5. Можно легко убрать закрытую зону из системы, если ее наличие не оплатил заказчик. До этого я просто ставил «заглушки» и убирал упоминание о закрытой зоне из шаблонов АЦ и сайта – и ни кто пока не жаловался и даже не знал о ее наличии.
6. Администратор сайта не сможет случайно назначить какому-то пользователю доступ в АЦ или что-то подобное.

P.S.: Извиняюсь если написал слишком много, но хотел более подробно раскрыть проблему.
 

whirlwind

TDD infected, paranoid
По моему это бред он предлагает. В общем случае, это приведет к дублированию кода.

1. а если администратор захочет Порше?
2. чем удобно?
3. этот товарищ про join вообще знает?
4. бред. код надо писать нормальный. юзать плейсходлеры и т.п.
5. можно ничего не убирать, а просто исключить определенную фикстуру при инсталяции.
6. более-менее тянет на разумный довод, но помоему решается гораздо легче чем дублирование системы авторизации
 

AmdY

Пью пиво
Команда форума
для большинства проектов подходит вариант, когда все юзверы хранятся в одной таблице, в которой хранится минимально необходимая инфа, доп. инфу храню в отдельных таблицах.
Но недавно делал блог, в котором было необходимо заводить отдельные таблицы.
 
Сверху