Это зависит.
при создании базы данных, которая должна быть встроена в отдельное приложение, которое Вы также создаете, можно принять решение поместить подтверждение правильности данных или в DBMS или в приложение или обоих. Почти все базы данных, создаваемые закаленными программистами, которые являются новичками базы данных, соответствуют этой категории. В этом случае некоторые из других ответов отвечают на Ваш вопрос.
однако, при создании базы данных, которая предназначается, чтобы хранить данные, полученные от нескольких приложений, и программирование некоторых из тех приложений находится вне контроля, тогда необходимо создать DBMS, чтобы быть защитными, а не позволить неправильным данным из поврежденного приложения заражать данные, которым Вы служите до других приложений и интерактивных пользователей. Вы не можете зафиксировать все ошибки, но можно поймать многие из них.
Как минимум, необходимо разработать таблицы так, чтобы у них был по крайней мере один возможный первичный ключ (возможные первичные ключи называют ключами-кандидатами). Необходимо выбрать первичный ключ из ключей-кандидатов и объявить его как ограничение первичного ключа. Это осуществляет объектную целостность.
кроме того, необходимо объявить "ссылочное" ограничение для каждого внешнего ключа. Это осуществляет ссылочную целостность. С достойным DBMS необходимо быть в состоянии осуществить ссылочную целостность, даже когда внешний ключ является дополнительным, другими словами, могло бы быть ПУСТЫМ. АННУЛИРУЕТ, Конечно, ни к чему не относятся.
нет никакого смысла в перемещении этих двух видов проверки к приложению. Приложение должно совершить поездку в прямом и обратном направлениях в базу данных так или иначе для обнаружения нарушений правила.
идея, что бизнес-логика не должна быть в базе данных, является, по-моему, неверным толкованием того, о чем базы данных - все. Снова, если Ваша база данных встраивается в отдельное приложение, то подойдите себе.
относительно правил проверки, которые запрещают отсутствующие значения (АННУЛИРУЕТ), нет никакого вреда в реализации их и в приложении и в базе данных. Во многих случаях это - правильный поступок. Так же с проверками принадлежности к диапазону.
Для очень крупных проектов, Вам нужен отдельный документ для выделения всех бизнес-правил на данных. Этот документ должен указать, где правила осуществляются, в базе данных, в приложении (приложениях) или обоих.
В ядре JSF нет встроенных функций аутентификации, кроме возможности использовать такие вещи, как атрибуты, отображаемые компонентом ,
, ориентированные на безопасность на основе ролей.
По умолчанию , приложение JSF полагается на те же механизмы безопасности, управляемые контейнером, что и веб-компонент, который его содержит ( учебник JEE5 ). Сторонние фреймворки, такие как Seam , могут предоставить альтернативы.
Если вы хотите добавить собственную безопасность приложения, фильтр сервлетов является одним из более простых механизмов.
Этот фильтр защищает ресурсы в каталоге с ограниченным доступом
, как определено в web.xml
:
<filter>
<filter-name>AuthenticationFilter</filter-name>
<filter-class>restricted.AuthenticationFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>AuthenticationFilter</filter-name>
<url-pattern>/restricted/*</url-pattern>
</filter-mapping>
Реализация класса фильтра:
public class AuthenticationFilter implements Filter {
private FilterConfig config;
public void doFilter(ServletRequest req, ServletResponse resp,
FilterChain chain) throws IOException, ServletException {
if (((HttpServletRequest) req).getSession().getAttribute(
AuthenticationBean.AUTH_KEY) == null) {
((HttpServletResponse) resp).sendRedirect("../restricted_login.faces");
} else {
chain.doFilter(req, resp);
}
}
public void init(FilterConfig config) throws ServletException {
this.config = config;
}
public void destroy() {
config = null;
}
}
Компонент входа в систему, определенный в faces-config.xml
:
public class AuthenticationBean {
public static final String AUTH_KEY = "app.user.name";
private String name;
public String getName() { return name; }
public void setName(String name) { this.name = name; }
public boolean isLoggedIn() {
return FacesContext.getCurrentInstance().getExternalContext()
.getSessionMap().get(AUTH_KEY) != null;
}
public String login() {
FacesContext.getCurrentInstance().getExternalContext().getSessionMap().put(
AUTH_KEY, name);
return "secret";
}
public String logout() {
FacesContext.getCurrentInstance().getExternalContext().getSessionMap()
.remove(AUTH_KEY);
return null;
}
}
Форма входа в JSF на странице limited_login.jsp
:
<f:view>
<p><a href="restricted/secret.faces">try to go to secret
page</a></p>
<h:form>
Username:
<h:panelGroup rendered="#{not authenticationBean.loggedIn}">
<h:inputText value="#{authenticationBean.name}" />
<h:commandButton value="login"
action="#{authenticationBean.login}" />
</h:panelGroup>
<h:commandButton value="logout"
action="#{authenticationBean.logout}"
rendered="#{authenticationBean.loggedIn}" />
</h:form>
</f:view>
(URL / механизм перенаправления был выбран для краткости, а не для каких-либо рекомендаций; дополнительные параметры см. В Servlet API ).
Если вы хотите попробовать более продвинутый подход, я предлагаю изучить Spring-security + JSF. Это работает как шарм.
Вы можете написать свое приложение, как если бы оно не находилось под защитой, а затем просто настроить, какие области должны быть защищены с помощью аспектов.
Spring security: http: // static. springsource.org/spring-security/site/[1228 visibleA Учебник: http://ocpsoft.com/java/acegi-spring-security-jsf-login-page/