2016-07-01 7 views
0

j_security_check позволяет легко загружать пользователей с сервера ldap. Это экономит мне таблицу USER. Это как задача управления пользователями, отделенная от системы.В чем преимущество использования j_security_check через самокодируемый модуль входа в систему?

Но проблема заключается в том, что в производственной системе со сложными требованиями к ID пользователя связано множество данных. То, что я ожидаю от управления пользователями, - это не просто войти в систему или подтвердить пароль. Например, у меня есть таблица USER_MEMBERSHIP, чтобы записать, какое членство приобрел конкретный пользователь. Если пользователь регистрируется j_security_check, как я могу перечислить пользователей, принадлежащих к определенному членству? В конце концов, я закончил создание другой таблицы USER в своей базе данных и заполнил информацию о пользователе при первом входе в систему. Если мне нужно это сделать, почему я должен использовать j_security_check? Почему бы просто не проверить пароль в моей базе данных и отключить причастность form_login/ldap?

Я так запутался. Справедливо ли говорить, что j_security_check предназначен только для простых систем? Является ли это рекомендуемым механизмом входа в систему для сложных приложений Java EE?

Заранее спасибо.

ответ

0

J_security_check является частью контейнера управляемой аутентификации, которая принимает на себя всю бремя обеспечения пользователей вошли в систему, связывая их с ролями, и обеспечения на основе ролей доступа к различным частям приложения, как это определено записей безопасности в Интернете .xml. Если вы не используете CMA, вы обречены на повторное выполнение всего этого. Возможно; он подвержен ошибкам; это повторение уже проделанной работы. И проверено.

+0

Да. Вы напоминаете мне о роли функции. Это важно, да. Но в сценарии, о котором я говорил на этом посту, какая лучшая практика? Не считаете ли вы целесообразным использовать таблицу USER в качестве локального кеша данных LDAP в своей собственной базе данных? – Song