6

Sto cercando di ottenere Tuckey UrlRewriteFilter per riordinare gli URL per la mia webapp. Un problema che ho riscontrato è che quando la sicurezza di primavera nota che un utente anonimo sta tentando di accedere a una risorsa protetta, reindirizza a un URL che include il percorso del servlet.Riscrivi gli URL di reindirizzamento sicurezza primavera

Quello che mi piacerebbe è, per esempio:

> GET http://localhost:8080/my-context/protected-resource 
< Location: http://localhost:8080/my-context/login 

Quello che ho attualmente ottengo è:

documenti
> GET http://localhost:8080/my-context/protected-resource 
< Location: http://localhost:8080/my-context/-/login 

rilevanti che ho trovato finora:

DefaultRedirectStrategy, che fa il reindirizzamento effettivo in questione: http://static.springsource.org/spring-security/site/docs/3.0.x/apidocs/org/springframework/security/web/DefaultRedirectStrategy.html. Ha una proprietà contextLative che è allettante ma non penso che la taglierà, se riuscirò a trovare un modo per configurarla.

un post sul blog che ha contribuito a farmi fino a questo punto: http://nonrepeatable.blogspot.com/2009/11/using-spring-security-with-tuckey.html

Quello che mi piacerebbe sapere è:

  1. Can/dovrei convincere Tuckey di riscrivere l'intestazione Posizione. < la regola in uscita > non sembra essere di aiuto qui.
  2. Posso/devo modificare in qualche modo la configurazione SS per emettere l'URL riscritto. Non penso che sia abbastanza ordinato, in quanto si romperebbe se la riscrittura fosse disabilitata.

web.xml sembra

<filter> 
    <filter-name>UrlRewriteFilter</filter-name> 
    <filter-class>org.tuckey.web.filters.urlrewrite.UrlRewriteFilter</filter-class> 
    <init-param> 
     <param-name>LogLevel</param-name> 
     <param-value>log4j</param-value> 
    </init-param> 
</filter> 
<filter-mapping> 
    <filter-name>UrlRewriteFilter</filter-name> 
    <url-pattern>/*</url-pattern> 
    <dispatcher>REQUEST</dispatcher> 
</filter-mapping> 

<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> 
    <dispatcher>REQUEST</dispatcher> 
    <dispatcher>FORWARD</dispatcher> 
    <dispatcher>INCLUDE</dispatcher> 
    <dispatcher>ERROR</dispatcher> 
</filter-mapping> 

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

urlrewrite.xml assomiglia:

<urlrewrite> 
    <rule> 
     <from>^/(.*)$</from> 
     <to>/-/$1</to> 
    </rule> 
</urlrewrite> 

applicationContent-security.xml assomiglia:

<http auto-config="true"> 
    <!-- allow GET requests to /login without authentication --> 
    <intercept-url pattern="/-/login" method="GET" filters="none"/> 

    <intercept-url pattern="/-/admin/**" access="ROLE_ADMIN"/> 
    <intercept-url pattern="/-/**" access="ROLE_USER"/> 

    <form-login login-page="/-/login" 
       login-processing-url="/-/login.do" 
       authentication-failure-url="/-/login?login_error" 
       default-target-url="/-/index" 
       always-use-default-target="true"/> 

    <logout logout-url="/-/logout" 
      logout-success-url="/-/login"/> 

    <access-denied-handler error-page="/-/access-denied"/> 
</http> 
+0

e impostare l'attributo della pagina di accesso su/login? – rodrigoap

risposta

0

I'v mai usato Tuckey, ma dopo un rapido sguardo al docum entazione vorrei provare ad aggiungere una regola per il caso login:

<urlrewrite> 
    <rule> 
     <from>^/my-context/login$</from> 
     <to>/my-context/login</to> 
    </rule> 
    <rule> 
     <from>^/(.*)$</from> 
     <to>/-/$1</to> 
    </rule> 
</urlrewrite> 

EDIT
Ok, e qualcosa di simile:

<urlrewrite> 
    <rule> 
     <from>^/-/login$</from> 
     <to>/login</to> 
    </rule> 
    <rule> 
     <from>^/(.*)$</from> 
     <to>/-/$1</to> 
    </rule> 
</urlrewrite> 
+2

Il problema non è che le richieste in entrata non vengano riscritte, ma piuttosto che le intestazioni di posizione in uscita come parte di un reindirizzamento non vengano riscritte. Da allora ho capito che una regola in uscita con protocollo completo, host, porta, contesto, ecc catturerà l'intestazione di posizione, ma non è nemmeno eccezionale. – ptomli

2

Ho guardato in questo problema per il nostro progetto lo scorso anno e al quella volta il problema era che Tucky non stava collaborando con response.encodeRedirectUrl() per riscrivere gli URL di reindirizzamento. Li ho contattati ma non ho seguito questo.

La mia soluzione era di consentire all'URL disordinato di tornare al client, ma di ripulirlo con una regola di reindirizzamento di Tucky (un secondo reindirizzamento).

Quindi aggiungere un'altra regola che corrisponde al proprio brutto URL dalla reindirizzamento sicurezza e la vostra propria reindirizzamento all'URL pulita:

<rule> 
    <from>^/whatever/ugly.*$</from> 
    <to type="redirect">/login</to> 
</rule> 

Sì, si tratta di due redirect, ma il cliente non potrà mai vederlo .. . che è probabilmente il punto.

1

sicurezza Primavera sta facendo il reindirizzamento con un URL assoluto come http://example.org/-/login

tenta di utilizzare un'uscita-regola senza il marcatore ^ start of string per abbinare l'URL assoluto generato entro la primavera.

<outbound-rule> 
    <from>/-/login(.*)$</from> 
    <to>/login$1</to> 
</outbound-rule>  
1

Mi sono imbattuto nello stesso problema, ma sembra risolto nella versione 3.2.0 di Tuckey. Ad esempio, response.encodeRedirectUrl() è ora incluso da Tuckeys UrlRewriteWrappedResponse in cui viene eseguita l'esecuzione della regola in uscita.