2012-05-21 3 views
2

Я после этого учебника security В этом руководстве упоминаются, что добавить что-то вроде этого для формы безопасности на основели безопасность на основе JSF поддержки формы

<form action="j_security_check" method=post> 
    <p>username: <input type="text" name="j_username"></p> 
    <p>password: <input type="password" name="j_password"></p> 
    <p><input type="submit" value="submit"></p> 
</form> 

Но в форме JSF я не имею attributr действий в часе: форма , который я установил в j_security_check. Также использование j_username и j_password также необходимо использовать в JSF для обеспечения безопасности на основе формы?

Благодаря

ответ

6

Да, этот URL действия и имена полей являются обязательными для form based authentication. Это указано в спецификации сервлета. Вы можете просто использовать его как есть на странице JSF. Единственное различие заключается в том, что форма отправки и аутентификации полностью обрабатывается контейнером, а не JSF. Тебе не нужно беспокоиться об этом.

Если вы хотите получить более тонкий контроль над процессом отправки формы или хотите использовать встроенную валидацию JSF и полномочия ajax и т. Д., Тогда вы всегда можете взять ее на programmatic authentication в управляемом компоненте JSF. Для этого вам нужно использовать HttpServletRequest#login() в методе действий. Проверка подлинности по-прежнему обрабатывается контейнером.

E.g.

<h:form> 
    <h:inputText value="#{login.username}" required="true" /> 
    <h:inputSecret value="#{login.password}" required="true" /> 
    <h:commandButton value="login" action="#{login.submit}"> 
     <f:ajax execute="@form" render="@form" /> 
    </h:commandButton> 
    <h:messages /> 
</h:form> 

с

public String submit() { 
    FacesContext context = FacesContext.getCurrentInstance(); 
    HttpServletRequest request = (HttpServletRequest) context.getExternalContext().getRequest(); 

    try { 
     request.login(username, password); 
     return "home?faces-redirect-true"; 
    } catch (ServletException e) { 
     context.addMessage(null, new FacesMessage(FacesMessage.SEVERITY_ERROR, "Unknown login", null)); 
     return null; 
    } 
} 
+0

HHm спасибо, но когда мы используем 'request.login (имя пользователя, пароль);', то как JSF проверяет его. Как я вхожу в basit (пользователь) и basit (пароль). Нужно ли устанавливать пароль имени пользователя где-нибудь на сервере Glassfish или в базе данных? Означает, как работает request.login()? Спасибо – Basit

+0

Точно так же, как проверка подлинности на основе форм. Единственное различие заключается в том, что вы вызываете его программным способом, а не отправляете 'j_security_check' с' j_username' и 'j_password'. – BalusC

+0

ok спасибо многим :) – Basit

1

Вот как я реализовал j_security_check (Container Managed Security) для моего JSF приложения, запущенного в Websphere 7. К сожалению, версия API сервлетов Я использую не

request.login() 

Класс «Фильтр входа» был создан для перехвата вызовов j_security_check. ResponseWrapper запоминает URL-адрес, который будет перенаправлен после входа в систему.

public class LoginFilter implements Filter { 
     private static String loginPage = "login.xhtml"; // read it from init config 
    public void doFilter(ServletRequest request, ServletResponse response, 
      FilterChain chain) throws IOException, ServletException { 
     // TODO Auto-generated method stub 
     // create wrapper 
     HttpServletRequest req = (HttpServletRequest) request; 
     MyWrapper myRes = new MyWrapper((HttpServletResponse) response); 
     // call authentication 
     chain.doFilter(request, myRes); 
     // check for login error 
       String redirectURL = myRes.getOriginalRedirect(); 
      if (StringUtils.isBlank(redirectURL) || redirectURL.contains(loginPage)) { 
        myRes.setOriginalRedirect(homePage); 
       } 
    myRes.sendMyRedirect(); 

} 
    class MyWrapper extends HttpServletResponseWrapper { 
     String originalRedirect; 

     public MyWrapper(HttpServletResponse response) { 
      super(response); 
     } 

     @Override 
     public void sendRedirect(String location) throws IOException { 
      // just store location, don’t send redirect to avoid 
      // committing response 
      originalRedirect = location; 
     } 

     // use this method to send redirect after modifying response 
     public void sendMyRedirect() throws IOException { 
      super.sendRedirect(originalRedirect); 
     } 

     public String getOriginalRedirect() { 
      return originalRedirect; 
     } 

     public void setOriginalRedirect(String originalRedirect) { 
      this.originalRedirect = originalRedirect; 
     } 


    } 

Веб-сайт выглядит следующим образом.

<filter> 
    <filter-name>LoginFilter</filter-name> 
    <filter-class>com.servlet.filter.LoginFilter</filter-class> 
</filter> 

<filter-mapping> 
    <filter-name>LoginFilter</filter-name> 
    <url-pattern>/j_security_check</url-pattern> 
</filter-mapping> 
<filter> 
    <filter-name>RequestJSFFilter</filter-name 
     <filter-class>com.servlet.filter.RequestJSFFilter</filter-class> 
</filter> 
<filter-mapping> 
    <filter-name>RequestJSFFilter</filter-name> 
    <url-pattern>*.xhtml</url-pattern> 
</filter-mapping> 

Другой фильтр, который перехватывает все * .xhtml и направляет к login.xhtml. В login.xhtml форма может выглядеть следующим образом:

<form action="j_security_check" method=post> 
    <p>username: <input type="text" name="j_username"></p> 
    <p>password: <input type="password" name="j_password"></p> 
    <p><input type="submit" value="submit"></p> 
</form> 

Надеюсь, это поможет.

+0

Это, по-видимому, специфичная для Websphere. Фильтр может не отображаться непосредственно на '/ j_security_check', так как это будет обрабатываться контейнером задолго до того, как будут введены фильтры, специфичные для webapp. Ваш подход потерпит неудачу, по крайней мере, у Tomcat, JBoss и Glassfish. – BalusC

+0

Я согласен с этим. Я искал решение, которое работает с Websphere. К сожалению, я не смог его найти. Отсюда отправлено это, что может помочь кому-то. – kamal079

Смежные вопросы