Собираюсь писать веб-морду для пользователя корпоративного каталога,
которая предоставляет следующий функционал:

Для всех пользователей:
 - изменение некоторых полей в LDAP своей учетной записи (пароль)
 - просмотр своей некоторой генерируемой персональной информации
   (персональная статистика пользования интернет, etc)

Для админов филиалов:
 - изменение некоторых полей в LDAP для своей ветки пользователей
   (пароль, ACL, etc)
 - просмотр некоторой генерируемой персональной информации своей ветки
   пользователей (статистика своей ветки, etc)

Требования возникают следующие:
 - пользователь должен вбивать пароль максимум 1 раз для смены пароля,
   и максимум 1 раз для просмотра генерируемой персональной информации
   (она может занимать больше одной страницы). Желательно всего 1 раз
   для всего этого.
 - админ должен вбивать пароль максимум 1 раз для редактирования
   пользовательских данных (интерфейс может занимать больше одной
   страницы) и максимум 1 раз для просмотра генерируемой персональной
   информации своей ветки пользователей (она также будет больше одной
   страницы). Желательно всего 1 раз для всего этого.


alterator-fbi подойдет для решения этих задач?

Судя по обсуждению по ссылке ниже, я понял, что авторизация при входе в
альтератор не должна использоваться для авторизации пользователя в
бакенде:
http://lists.altlinux.org/pipermail/devel-conf/2009-January/008300.html

Возникает вопрос: можно ли как-нибудь избавиться от формы ввода пароля
при первоначальном входе на страницу альтератора, и всех пользователей
пускать как бесправных анонимусов?
Можно логин/пароль по-умолчанию повесить в форме login.html в виде
hidden-полей, но может есть более прямой способ?

Как реализовать передачу полученной в конкретном бакенде информации
(логин/пароль)  в цепочке показываемых пользователю страниц-разных
бакендов?
Хорошо бы, если бы между бакендами информацию (логин/пароль)  можно
было бы передавать не только при переходах между бакендами по ссылкам
внутри форм, но и при переходах между бакендами в меню слева -- это
реализуемо?
На w.a.o есть указание на некий alterator-workflow -- это не оно?


Ну и приветствуются прочие советы/замечания на эту тему.

Attachment: signature.asc
Description: PGP signature

_______________________________________________
devel-conf mailing list
devel-conf@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/devel-conf

Ответить