2013-02-12 7 views
6

In JSF, sembra che le sessioni siano state create prima del un accesso riuscito. Semplicemente richiedendo la pagina di login si crea una nuova sessione.Quando viene creata una sessione durante l'accesso JSF?

Sembra molto dispendioso (e vulnerabile agli attacchi DDoS) creare una sessione per ogni richiesta ricevuta, piuttosto che ogni utente connesso con successo.

Il codice seguente è piuttosto generico, ma mostra il tipo di scenario semplice a cui mi riferisco.

index.xhtml:

<html> 
    <body> 
     <h:form id="login"> 
      <h:outputLabel for="username">Username</h:outputLabel> 
      <p:inputText id="username" name="username" value="#{userController.username}"/> 
      <h:outputLabel for="password">Password</h:outputLabel> 
      <p:password id="password" name="password" value="#{userController.password}"/> 

      <p:commandButton id="loginButton" value="login" action="#{loginController.login}"/> 
     </h:form> 
    </body> 
</html> 

LoginController.java

@ViewScoped 
public class LoginController implements Serializable { 

    String username; 
    String password; 

    public void login(){ 
     HttpServletRequest request = (HttpServletRequest) FacesContext.getCurrentInstance().getExternalContext().getRequest(); 
     if (request.getSession(false) == null){ 
      System.out.println("No session."); 
     } else { 
      System.out.println("Session already exists."); 
     } 

     try { 
      request.login(username, password); 
     } catch (ServletException e) { 
      FacesContext.getCurrentInstance.addMessage(null, new FacesMessage("Login failure", e.getMessage())); 
     } 
    } 

    // username and password getters/setters 

} 

Edit: esempio di codice caotica fisso

risposta

8

Prima di tutto, la vostra metodologia di test è completamente sbagliato.

if (request.getSession() == null){ 
    System.out.println("No session."); 
} else { 
    System.out.println("Session already exists."); 
} 

Si prega di leggere attentamente le javadoc del getSession() metodo di argumentless. Ti renderai conto che è mai restituisce null.

Tornando al problema concreto, per impostazione predefinita JSF effettivamente autocreare la sessione perché lo stato di visualizzazione JSF deve essere memorizzato lì. Se si imposta il metodo di salvataggio dello stato JSF su client anziché su server, non verrà memorizzato nella sessione e quindi non è necessario creare alcuna sessione.

<context-param> 
    <param-name>javax.faces.STATE_SAVING_METHOD</param-name> 
    <param-value>client</param-value> 
</context-param> 

Nella prossima JSF 2.2 si potrebbe in alternativa anche mettere il fagiolo nel campo di applicazione richiesta e utilizzare <f:view transient="true"> per andare completamente senza stato. Questo è per la versione corrente di JSF 2.1 disponibile solo da Mojarra 2.1.19. Vedi anche per es. this blog da uno degli sviluppatori di Mojarra.

+0

Confessione: il codice di esempio è stato fortemente adattato dal nostro codice di produzione. Inizialmente usavo getSession (false). Ma a parte questo, grazie per aver confermato ciò che pensavo. Nonostante molte ricerche in giro (libri, blog, documenti Oracle) non ho trovato conferma esplicita che JSF autorizza la sessione. – MMeldrum

+0

Per inciso, questo rende davvero più semplice eliminare un server allagandolo con nuove richieste di accesso (nonostante non siano disponibili credenziali di accesso)? – MMeldrum

+0

Dipende dall'hardware del server e dalla configurazione. Per esempio. connessione/richiesta di pool, timeout della sessione, memoria disponibile, larghezza di banda della rete, ecc. Misurare è sapere. – BalusC

Problemi correlati