Здравствуйте, Dziman, Вы писали:
D> Какие плюсы, минусы у каждого из подходов?
Если копировать подход из мира *nix, то вход под root должен быть запрещен, в то время как sudo (аналог супер-роли) может быть у нескольких человек и в случае разбора полетов гораздо проще найти концы.
Управляю вселенной не привлекая внимания санитаров.
Здравствуйте, Dziman, Вы писали:
D>Какие плюсы, минусы у каждого из подходов?
Надо плясать от бизнес процессов. Если явно предполагается, что у системы будет один админ и всем понятно, кто этот человек — первый подход имеет право на жизнь. Если нет — только второй, иначе учетка админа станет ничьей, ее пароль начнут писать на бумажках и прочие вытекающие.
Есть многопользовательское приложение(веб, но я думаю это не принципиально). Пользователи имеют роли хранящиеся в БД, которые определяют что можно делать, чего нельзя. И есть суперпользователь(условный root), который может делать вообще все.
Возник спор как этого рута реализовывать.
Подход 1: где-то 'захардкожен' id рута и он проверяется для определения что это рут. При этом этому пользователю 'выдаются' стандартным механизмом 'максимальная' роль.
Мы делаем по аналогии с root в *nix — id всегда 0, у винды тоже (S-1-5-21[domain]-500). Есть конечно группы root и Administrators, но нет группы/роли, определяющей рута или Администратора. Это подход, проверенный десятилетиями. И зачем нам велосипеды изобретать?
Подход 2: просто дбавляется 'суперроль' с максимальными полномочиями и назначается нужным пользователям(даже если это будет только один реальный пользователь).
Какие плюсы, минусы у каждого из подходов?
Здравствуйте, Anton Batenev, Вы писали:
AB> D> Какие плюсы, минусы у каждого из подходов?
AB> Если копировать подход из мира *nix, то вход под root должен быть запрещен, в то время как sudo (аналог супер-роли) может быть у нескольких человек и в случае разбора полетов гораздо проще найти концы.
Неа, стандартный подход: "Вон в *nix есть суперюзер с ид=0, значит и у нас так будет. Там еще sudo и прочие ограничения для него? Не, не слышали."
Здравствуйте, Dziman, Вы писали:
D>Здравствуйте, Anton Batenev, Вы писали:
AB>> D> Какие плюсы, минусы у каждого из подходов?
AB>> Если копировать подход из мира *nix, то вход под root должен быть запрещен, в то время как sudo (аналог супер-роли) может быть у нескольких человек и в случае разбора полетов гораздо проще найти концы.
D>Неа, стандартный подход: "Вон в *nix есть суперюзер с ид=0, значит и у нас так будет. Там еще sudo и прочие ограничения для него? Не, не слышали."
Нету для рута никаких ограничений. И входить под ним можно, и что угодно, если настроить систему.
Здравствуйте, Dziman, Вы писали:
D> Неа, стандартный подход: "Вон в *nix есть суперюзер с ид=0, значит и у нас так будет. Там еще sudo и прочие ограничения для него? Не, не слышали."
Ну я написал как бы я сделал. А то, что большинство под root по FTP ходят — ну дурака могила исправит.
Управляю вселенной не привлекая внимания санитаров.
Здравствуйте, Dziman, Вы писали:
D>Есть многопользовательское приложение(веб, но я думаю это не принципиально). Пользователи имеют роли хранящиеся в БД, которые определяют что можно делать, чего нельзя. И есть суперпользователь(условный root), который может делать вообще все. D>Возник спор как этого рута реализовывать. D>Подход 1: где-то 'захардкожен' id рута и он проверяется для определения что это рут. При этом этому пользователю 'выдаются' стандартным механизмом 'максимальная' роль. D>
Мы делаем по аналогии с root в *nix — id всегда 0, у винды тоже (S-1-5-21[domain]-500). Есть конечно группы root и Administrators, но нет группы/роли, определяющей рута или Администратора. Это подход, проверенный десятилетиями. И зачем нам велосипеды изобретать?
D>Подход 2: просто дбавляется 'суперроль' с максимальными полномочиями и назначается нужным пользователям(даже если это будет только один реальный пользователь). D>Какие плюсы, минусы у каждого из подходов?
У меня реализован первый подход, т.е. при создании системы сразу имеется пользователь админ. Он же в свою очередь может создавать других админов.
Здравствуйте, Dziman, Вы писали:
D>Есть многопользовательское приложение(веб, но я думаю это не принципиально). Пользователи имеют роли хранящиеся в БД, которые определяют что можно делать, чего нельзя. И есть суперпользователь(условный root), который может делать вообще все. D>Возник спор как этого рута реализовывать. D>Подход 1: ... D>Подход 2: ...
Подход 3 — флажок в базе "супер админ" у пользователя. Это комбинация 1 и 2 — с одной стороны не требуется хардкода, с другой стороны супер-админу можно многие проверки прав просто отключить.
