Основная безопасность в JSF

Это зависит.

при создании базы данных, которая должна быть встроена в отдельное приложение, которое Вы также создаете, можно принять решение поместить подтверждение правильности данных или в DBMS или в приложение или обоих. Почти все базы данных, создаваемые закаленными программистами, которые являются новичками базы данных, соответствуют этой категории. В этом случае некоторые из других ответов отвечают на Ваш вопрос.

однако, при создании базы данных, которая предназначается, чтобы хранить данные, полученные от нескольких приложений, и программирование некоторых из тех приложений находится вне контроля, тогда необходимо создать DBMS, чтобы быть защитными, а не позволить неправильным данным из поврежденного приложения заражать данные, которым Вы служите до других приложений и интерактивных пользователей. Вы не можете зафиксировать все ошибки, но можно поймать многие из них.

Как минимум, необходимо разработать таблицы так, чтобы у них был по крайней мере один возможный первичный ключ (возможные первичные ключи называют ключами-кандидатами). Необходимо выбрать первичный ключ из ключей-кандидатов и объявить его как ограничение первичного ключа. Это осуществляет объектную целостность.

кроме того, необходимо объявить "ссылочное" ограничение для каждого внешнего ключа. Это осуществляет ссылочную целостность. С достойным DBMS необходимо быть в состоянии осуществить ссылочную целостность, даже когда внешний ключ является дополнительным, другими словами, могло бы быть ПУСТЫМ. АННУЛИРУЕТ, Конечно, ни к чему не относятся.

нет никакого смысла в перемещении этих двух видов проверки к приложению. Приложение должно совершить поездку в прямом и обратном направлениях в базу данных так или иначе для обнаружения нарушений правила.

идея, что бизнес-логика не должна быть в базе данных, является, по-моему, неверным толкованием того, о чем базы данных - все. Снова, если Ваша база данных встраивается в отдельное приложение, то подойдите себе.

относительно правил проверки, которые запрещают отсутствующие значения (АННУЛИРУЕТ), нет никакого вреда в реализации их и в приложении и в базе данных. Во многих случаях это - правильный поступок. Так же с проверками принадлежности к диапазону.

Для очень крупных проектов, Вам нужен отдельный документ для выделения всех бизнес-правил на данных. Этот документ должен указать, где правила осуществляются, в базе данных, в приложении (приложениях) или обоих.

36
задан Mr_and_Mrs_D 6 February 2014 в 21:01
поделиться

2 ответа

В ядре 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 ).

46
ответ дан 27 November 2019 в 06:01
поделиться

Если вы хотите попробовать более продвинутый подход, я предлагаю изучить Spring-security + JSF. Это работает как шарм.

Вы можете написать свое приложение, как если бы оно не находилось под защитой, а затем просто настроить, какие области должны быть защищены с помощью аспектов.

Spring security: http: // static. springsource.org/spring-security/site/[1228 visibleA Учебник: http://ocpsoft.com/java/acegi-spring-security-jsf-login-page/

4
ответ дан 27 November 2019 в 06:01
поделиться
Другие вопросы по тегам:

Похожие вопросы: