Come posso gestire/limitare l'accesso degli utenti ai servlet e ai jsp?

Question

Attualmente sto scrivendo una piccola applicazione web dinamica in Java. L'applicazione dovrebbe essere una piattaforma di eventi in cui è possibile creare un account utente, accedere e quindi è possibile visualizzare tutti gli eventi aperti (in un iterazione successiva, gli utenti possono creare/partecipare a tali eventi).

In questo momento, la struttura del web-app potrebbe essere (semplificato) ha descritto in questo modo:

Register-Servlet -> Register.jsp 
     | 
     V 
Login-Servlet -> Login.jsp 
     | 
     V 
Main-page-Servlet -> Main.jsp 

Così adesso, un utente potrebbe andare a Login.jsp, la sua login-informazione sarebbe da inviare al servlet di accesso, che lo convaliderà e quindi lo invierà al servlet della pagina principale. Il Main-Page-Servlet poi (dopo aver convalidato di nuovo il login) ottiene tutti gli eventi correnti da un database, lo allega alla richiesta e lo inoltra al Main.jsp, che lo mostra all'utente affinché lo veda.

Ora, se un utente desidera accedere direttamente a Main.jsp (senza venire dalla Main-Page-Servlet), ovviamente non può visualizzare gli eventi disponibili. La soluzione che sto utilizzando attualmente sta eseguendo un controllo null per verificare se gli eventi sono presenti e, in caso contrario, reindirizzare a Main-Page-Servlet.

Mi dà fastidio risolvere il mio problema in questo modo, poiché non penso che sia la migliore pratica e penso che creerà molti altri problemi più grande diventerà la mia applicazione.

Il mio primo pensiero è stato che potrebbe essere utile se potessi semplicemente "nascondere" tutti i .jsp dell'utente, in modo che l'utente possa atterrare solo sui servlet e non possa accedere a .jsp in un modo diverso .

C'è un modo per farlo? Oppure, in caso contrario, quale sarebbe la soluzione migliore se dovessi scrivere un'applicazione professionale a livello aziendale?

Answer 1

Questo può essere gestito in un Filter e ci sono grande spiegazione ed esempio in StackOverflow Servlet-Filter wiki.

Adattare il codice lì per il vostro problema (si noti l'aggiunta e l'uso del metodo needsAuthentication):

@WebFilter("/*") 
public class LoginFilter implements Filter { 
    @Override 
    public void init(FilterConfig config) 
     throws ServletException { 
     // If you have any <init-param> in web.xml, then you could get them 
     // here by config.getInitParameter("name") and assign it as field. 
    } 

    @Override 
    public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) 
     throws IOException, ServletException { 
     HttpServletRequest request = (HttpServletRequest) req; 
     HttpServletResponse response = (HttpServletResponse) res; 
     HttpSession session = request.getSession(false); 

     String requestPath = httpServletRequest.getRequestURI(); 

     if (needsAuthentication(requestPath) || 
      session == null || 
      session.getAttribute("user") == null) { // change "user" for the session attribute you have defined 

      response.sendRedirect(request.getContextPath() + "/login"); // No logged-in user found, so redirect to login page. 
     } else { 
      chain.doFilter(req, res); // Logged-in user found, so just continue request. 
     } 
    } 

    @Override 
    public void destroy() { 
     // If you have assigned any expensive resources as field of 
     // this Filter class, then you could clean/close them here. 
    } 

    //basic validation of pages that do not require authentication 
    private boolean needsAuthentication(String url) { 
     String[] validNonAuthenticationUrls = 
      { "Login.jsp", "Register.jsp" }; 
     for(String validUrl : validNonAuthenticationUrls) { 
      if (url.endsWith(validUrl)) { 
       return false; 
      } 
     } 
     return true; 
    } 
} 

Suggerirei per spostare tutte le pagine che richiedono l'autenticazione all'interno di una cartella come app e quindi modificare il filtro web per

@WebFilter("/app/*") 

In questo modo, è possibile rimuovere il metodo needsAuthentication dal filtro.