2012-01-10 19 views
5

Sto cercando di ottenere la mia primavera + letargo + spring-security e tiles2 - l'applicazione "HelloWorld" al lavoro, dopo this guide (è purtroppo in tedesco).j_spring_security_check 404 issue

Il mio problema è che ricevo un messaggio di errore "404" quando accedo alla mia applicazione. Il reindirizzamento alla pagina di accesso funziona come previsto, ma non riesco a raggiungere "http://localhost:8080/App/j_spring_security_check" quando si preme il pulsante di accesso.

mio web.xml appare in questo modo:

<context-param> 
    <param-name>contextConfigLocation</param-name> 
    <param-value> 
     /WEB-INF/defs/applicationContext.xml 
     /WEB-INF/defs/applicationContext-security.xml 
    </param-value> 
</context-param> 

<filter> 
    <filter-name>springSecurityFilterChain</filter-name> 
    <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class> 
</filter> 

<filter-mapping> 
    <filter-name>springSecurityFilterChain</filter-name> 
    <url-pattern>/*</url-pattern> 
</filter-mapping> 

<listener> 
    <listener-class>org.springframework.security.web.session.HttpSessionEventPublisher</listener-class> 
</listener> 

e applicationContext-security.xml file ha un aspetto in questo modo ...

<http use-expressions="true"> 
    <intercept-url pattern="/index.html" access="permitAll" /> 
    <intercept-url pattern="/timeout.html" access="permitAll" /> 
    <intercept-url pattern="/redirect.html" access="permitAll" /> 
    <intercept-url pattern="/media/**" access="permitAll" /> 
    <intercept-url pattern="/includes/**" access="permitAll" /> 
    <intercept-url pattern="/office/**" access="hasRole('ROLE_USER')" /> 
    <intercept-url pattern="/office/admin/**" access="hasRole('ROLE_ADMIN')" /> 

    <form-login login-page="/index.html" 
      authentication-failure-url="/index.html?login_error=1" 
      default-target-url='/office/kunden.html' 
      always-use-default-target='true' 
      /> 
    <logout logout-success-url="/index.html" /> 
    <remember-me /> 
    <session-management invalid-session-url="/index.html"> 
     <concurrency-control max-sessions="2" error-if-maximum-exceeded="true" /> 
    </session-management> 
</http> 

<authentication-manager> 
    <authentication-provider> 
     <jdbc-user-service data-source-ref="mysqldataSource" 
        authorities-by-username-query="select username, authority from benutzer where username = ?" 
        users-by-username-query="select username, password, enabled from benutzer where username = ?"/> 
    </authentication-provider> 
</authentication-manager> 

La connessione al database sembra essere O.K.

Sarei molto felice se qualcuno potesse darmi un suggerimento su questo, perché ho già fatto un sacco di google, ma non ho ancora trovato una soluzione.

Io uso la primavera 3.1 e Tomcat 7.0.23

+0

Intendi "j_security_check" o "j_spring_security_check"? Avete entrambi qui ... –

+0

Spiacente, è j_spring_security_check – xSNRG

+0

Controllare l'output del registro di debug per quella richiesta e vedere cosa dice Spring Security sull'elaborazione. Dovresti vedere un rapporto dettagliato del suo passaggio attraverso la catena del filtro. –

risposta

0

La configurazione sembra ok. Una cosa che può fare il caso del 404 è se il default-target-url='/office/kunden.html' punta a un controller o una vista che non esiste.

Verificare che l'URL /office/kunden.html funzioni, quindi disattivare la sicurezza (aggiungere solo <security:intercept-url pattern="/**" access="permitAll" />) e provarlo.

Un'altra cosa che può andare storta, è che il tutorial è per la primavera 3.0 ma non per la primavera 3.0. Non mi aspetterei che questa sia la causa, ma provatelo e fatelo downgrade.

+0

Questo è quello che ho fatto prima, disattivare le restrizioni di sicurezza. Stesso problema. Forse hai ragione e il downgrade aiuta. – xSNRG

+0

Potete chiarire esattamente quale richiesta sta causando il 404? Dovresti essere in grado di gestirlo dal registro e monitorando le richieste inviate dal tuo browser (ad esempio usando Firebug). –

+0

@xSNRG: Se lo stesso problema si verifica senza la sicurezza molla, il problema è correlato al controller o alla vista 'kunden'. - Hai implementato il tutorial fino alla sua fine, perché sembra che il controller 'kunden' sia implementato dopo la sicurezza? – Ralph

2

Vorrei verificare due cose:

  1. richieste di invio
  2. config Primavera-sicurezza

Per controllare richiesta la spedizione appena assicurarsi che l'applicazione è accessibile nel servlet container in il primo posto. Significato, hai menzionato http://localhost:8080/App/j_spring_security_check. La tua applicazione è accessibile con quell'URL? http://localhost:8080/App mostra il contenuto appropriato (HTTP 200)? Inoltre, assicurarsi che il servlet del dispatcher sia configurato correttamente. Nel tutorial che ci ha fornito, c'è questa sezione:

<!-- Spring Hauptteil --> 

    <servlet> 
     <servlet-name>spring</servlet-name> 
     <servlet-class> 
      org.springframework.web.servlet.DispatcherServlet 
     </servlet-class> 
     <load-on-startup>1</load-on-startup> 
    </servlet> 
    <servlet-mapping> 
     <servlet-name>spring</servlet-name> 
     <url-pattern>*.html</url-pattern> 
    </servlet-mapping> 

Se non è stato fornito nel vostro web.xml, allora la richiesta potrebbe anche non essere inviato correttamente prima che si finisce per essere esaminato tramite molla di sicurezza.

Se questo non ti aiuta, prova questo.

A seguito di documentation, la configurazione minima dovrebbe essere sufficiente per verificare se la configurazione è corretta. Se hai seguito il tutorial, potresti commettere un piccolo errore (typeo, ad esempio) che farà sì che la sicurezza di primavera non venga avviata correttamente. Quindi è facile saltare alcune informazioni di errore nell'output del logger. Ti suggerisco di fare quanto segue.

  1. Modificare applicationContext-security.xml per supportare la configurazione minima fornita nella documentazione.
  2. lanciare l'applicazione e andare a http://localhost:8080/App/j_spring_security_check

Se si ottiene la risposta corretta - provare a modificare config fino a quando si è fatto.

Point per imparare Che DelegatingFilterProxy (definito in web.xml) in realtà non fa altro che delegare richiesta a qualche altro filtro gestito dal CIO di primavera. Questo filtro viene definito in applicationContext-security tramite lo spazio dei nomi di sicurezza. Se questo non funziona per qualche motivo, il filtro non verrà inizializzato e si potrebbe finire nel vedere http 404 indipendentemente dal fatto che il resto dell'applicazione si avvii correttamente.

Uffff, un sacco di testo;)

0

Per coloro che devono affrontare gli stessi sintomi, ma per una situazione diversa, coloro che sono dietro un bilanciatore di carico che fa offloading SSL, la seguente risposta potrebbe mettere in giusta direzione. Ho avuto un problema simile e si è scoperto che la richiesta in ingresso è stata gestita corretto, tuttavia, come una cauzione molla risposta invia un reindirizzamento a un URL assoluto che è definito dall'attributo default-target-url (iniziando con http anziché https)

<security:form-login login-page="/login.jsp" default-target-url="/index.jsp" authentication-failure-url="/login.jsp?error=true" /> 

Ora il browser client tenta di aprire il percorso reindirizzato su http, fallisce sul loadbalancer (che accetta solo il traffico HTTPS) e segnala un 404 NOT FOUND

abbiamo risolto il problema aggiungendo la direttiva seguente mod_header per tutte le richieste in ingresso sulla porta 443 (https) nel servizio di bilanciamento del carico:

RequestHeader set X-Forwarded-Proto "https"

Aggiunge un'intestazione aggiuntiva. Se si esegue un server applicazioni come Jetty, riconoscerà questa intestazione e tradurrà la richiesta in entrata. (vedi http://www.gossamer-threads.com/lists/apache/users/407272)