2012-06-05 14 views
6

Tworzenie aplikacji internetowej w Java EE z JSF. Wszystkie strony są zabezpieczone przed przeglądaniem przez formularz uwierzytelniania z akcją "j_security_check" i wejściami "j_username" i "j_password".Niewłaściwe przekierowanie po zalogowaniu (Java EE w/JSF)

Po pomyślnym zalogowaniu, jednak nie jestem przekierowywany do strony chciałem, aby uzyskać dostęp do tego adresu URL, ale

/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development 

Więc szukam na jsf.js plik skryptu ze wszystkimi kodu JS zamiast strony, którą chciałem zobaczyć. Nie ma znaczenia, czy mam dostęp do katalogu głównego lub innej strony, za każdym razem jestem przekierowywany pod ten URL. Następnie zmieniam adres URL na dowolną stronę, ładuje się dobrze i jestem zalogowany.

Muszę powiedzieć, że już miałem ten problem, który magicznie odszedł, więc przekierował mnie poprawnie. Po kilku tygodniach znowu się popsuły, ale nie, jeśli to moja wina, a jeśli tak, to nie znam przyczyny. W ogóle nie działałem z przekierowaniem ani regułami nawigacyjnymi.

Dobrze wspomnieć, że używam również PrettyFaces.

EDIT:

<security-constraint> 
    <display-name>secured</display-name> 
    <web-resource-collection> 
     <web-resource-name>all</web-resource-name> 
     <description/> 
     <url-pattern>/*</url-pattern> 
    </web-resource-collection> 
    <auth-constraint> 
     <description/> 
     <role-name>admin</role-name> 
     <role-name>teacher</role-name> 
    </auth-constraint> 
</security-constraint> 
<security-constraint> 
    <display-name>secured for admins</display-name> 
    <web-resource-collection> 
     <web-resource-name>admin pages</web-resource-name> 
     <description/> 
     <url-pattern>/admin/*</url-pattern> 
    </web-resource-collection> 
    <auth-constraint> 
     <description/> 
     <role-name>admin</role-name> 
    </auth-constraint> 
</security-constraint> 
<security-constraint> 
    <display-name>unsecured</display-name> 
    <web-resource-collection> 
     <web-resource-name>css</web-resource-name> 
     <description/> 
     <url-pattern>/css/*</url-pattern> 
    </web-resource-collection> 
    <web-resource-collection> 
     <web-resource-name>js</web-resource-name> 
     <description/> 
     <url-pattern>/js/*</url-pattern> 
    </web-resource-collection> 
    <web-resource-collection> 
     <web-resource-name>img</web-resource-name> 
     <description/> 
     <url-pattern>/img/*</url-pattern> 
    </web-resource-collection> 
</security-constraint> 
<login-config> 
    <auth-method>FORM</auth-method> 
    <realm-name>wetk-security</realm-name> 
    <form-login-config> 
     <form-login-page>/faces/login.xhtml</form-login-page> 
     <form-error-page>/faces/login.xhtml</form-error-page> 
    </form-login-config> 
</login-config> 
+0

Co znajduje się w elementach '> twojego pliku' web.xml'? –

+0

Edytowane pytanie. – redhead

Odpowiedz

8

Pojemnik udało bezpieczeństwa odsyła do ostatniego żądania HTTP, które spowodowało sprawdzanie uwierzytelniania. W twoim przypadku to najwyraźniej automatycznie dołączony plik JavaScript API JSF. Może się tak zdarzyć, jeśli przeglądarka załadowała stronę, która ma zostać uwierzytelniona, w całości z pamięci podręcznej przeglądarki, podczas gdy przeglądarka załadowała plik JS w pełni od strony serwera lub przetestowała ważność pliku pamięci podręcznej JavaScript przez warunkowe żądanie GET .

Chciałabyś, aby wykluczyć zasobów JSF (<h:outputScript>, <h:outputStylesheet> i <h:graphicImage> z kontroli uwierzytelniania. Można to zrobić poprzez wyłączenie wspólny wzorzec URL /javax.faces.resource/*. Można tylko chcesz dodać wzór /faces prefiksu jak jesteś widocznie używając go zamiast wzoru *.xhtml sufiksu.

Należy również nakazać przeglądarce nie cache ograniczony stron, aby zapobiec przeglądarki go z pamięci podręcznej (na przykład przez naciśnięcie przycisku po wylogowaniu z powrotem). Mapa następujący filtr na tym samym wzorcu adresu URL, co w przypadku twojego <security-constraint>.

@WebFilter("/secured/*") // Use the same URL pattern as <security-constraint> 
public class NoCacheFilter implements Filter { 

    @Override 
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { 
     HttpServletRequest httpReq = (HttpServletRequest) request; 
     HttpServletResponse httpRes = (HttpServletResponse) response; 

     if (!httpReq.getRequestURI().startsWith(httpReq.getContextPath() + ResourceHandler.RESOURCE_IDENTIFIER)) { // Skip JSF resources (CSS/JS/Images/etc) 
      httpRes.setHeader("Cache-Control", "no-cache, no-store, must-revalidate"); // HTTP 1.1. 
      httpRes.setHeader("Pragma", "no-cache"); // HTTP 1.0. 
      httpRes.setDateHeader("Expires", 0); // Proxies. 
     } 

     chain.doFilter(request, response); 
    } 

    // ... 
} 
+0

Więc wypróbowałem twój kod i w procesie logowania (pierwsze żądanie i po przesłaniu formularza) filtr nigdy nie otrzymuje żądanej strony. Otrzymuje go dopiero po ponownym zmianie adresu URL. Tak więc, nie działa ponownie, nadal widzę skrypt JS. – redhead

+0

Czy wyczyściłeś pamięć podręczną przeglądarki przed testowaniem? – BalusC

+0

Próbowałem całkowicie wyczyszczoną Operę, ale bez zmian. – redhead

Powiązane problemy