Precedenza di security-constraint su filtri in servlet

Question

Mentre studiava per la sicurezza-vincoli e filtri in servlet, ho fatto le seguenti dichiarazioni nel file web.xml, che non ha funzionato come mi aspettavo:

<security-constraint> 
    <web-resource-collection> 
     <web-resource-name>BeerSelector</web-resource-name> 
     <url-pattern>/SelectBeer.do</url-pattern> 
     <http-method>GET</http-method> 
     <http-method>POST</http-method> 
     </web-resource-collection> 
    <auth-constraint> 
     <role-name>Admin</role-name> 
    </auth-constraint> 
</security-constraint> 


    <filter> 
    <filter-name>LoginFilter</filter-name> 
    <filter-class>model.MyFilter</filter-class> 
    </filter> 


    <filter-mapping> 
    <filter-name>LoginFilter</filter-name> 
    <url-pattern>/SelectBeer.do</url-pattern> 
    </filter-mapping> 

Secondo quanto ho letto: i filtri devono essere rilevati prima dello la richiesta raggiunge un determinato URL, quindi, come mai il vincolo di sicurezza è stato invocato per primo?

So che ha senso da un punto di vista della sicurezza (per raggiungere il filtro che si può autenticare), ma mi piacerebbe conoscere la sequenza attivata dalla richiesta.

Il contenitore ricerca prima le risorse protette, quindi attiva il vincolo di sicurezza?

Ma questo sarà in contraddizione con il seguente paragrafo citato da Head First servlet e JSP "

Ricordate che in DD, il è su ciò che accade dopo la richiesta. In altre parole, il cliente ha già fatto la richiesta quando il contenitore inizia a guardare le elementi per decidere come rispondere. i dati di richiesta è già stato inviato attraverso il filo

o forse la richiesta attiva solo entrambi: filtro e vincolo di sicurezza, ma il vincolo di sicurezza è favorito sul filtro?

Answer 1

L'esecuzione del filtro avviene nel lato "servizio" della richiesta. I vincoli di sicurezza operano prima di questo. Aiutano il server a decidere se verrà pubblicato l'URL. Puoi pensare al ruolo dei filtri come qualcosa che esegue "solo prima/dopo l'esecuzione del servlet".

Answer 2

Il contenitore elabora prima i vincoli di sicurezza.

In poche parole il contenitore servlet prima esamina l'URL entrante e controlla se abbinato cosiddetti escluso o incontrollati vincoli. Escluso significa che l'URL non è accessibile a nessuno, mentre deselezionato significa il contrario e consente a tutti di accedere all'URL.

In questa fase il contenitore può chiamare il proprio codice se è stato installato un cosiddetto provider JACC.

Dopo questo il contenitore può provare ad autenticare l'utente corrente, dove può chiamare di nuovo il proprio codice. Se hai registrato un SAM (ServerAuthModule) questo sarà sempre chiamato a questo punto, se non hai registrato un SAM o quando stai lavorando con un'implementazione Java EE non completa (ad esempio un server di profilo web Java EE come TomEE o un contenitore Servlet nudo come Tomcat) dipende dal server se qualche tipo di modulo di login specifico del server viene sempre chiamato (raro) o chiamato solo quando l'accesso non è concesso all'utente non autenticato (tipico).

Il SAM è un filtro simile a quanto può reindirizzare, inoltrare e avvolgere la richiesta e la risposta, ma non è un filtro servlet HTTP.

Dopo che l'autenticazione ha avuto esito positivo, il criterio JACC verrà richiamato o quando non è stato installato uno, il contenitore utilizzerà un meccanismo proprietario per verificare se ora è stato autorizzato l'accesso.

Se è effettivamente determinato che si ha accesso, verrà richiamata la cosiddetta "risorsa", il che significa che il contenitore chiamerà il primo Filtro nella catena di filtraggio, che alla fine invierà al Servlet di destinazione a cui il l'URL richiesto è stato mappato.

Si può leggere di più sul SAM qui: http://arjan-tijms.omnifaces.org/2012/11/implementing-container-authentication.html

E più sui provider JACC qui: http://arjan-tijms.omnifaces.org/2014/03/implementing-container-authorization-in.html