2016-06-30 29 views
1

ich einen Java-Webapp, die web.xml seine Sicherheit konfigurieren verwendet:Web.xml Sicherheitsbeschränkung auf context-root gilt nicht

<security-constraint> 
    <web-resource-collection> 
     <web-resource-name>webPages</web-resource-name> 
     <description>All web resources</description> 
     <url-pattern></url-pattern> 
     <url-pattern>/admin/*</url-pattern> 
     <http-method>POST</http-method> 
     <http-method>GET</http-method> 
    </web-resource-collection> 
    <auth-constraint> 
     <role-name>admins</role-name> 
    </auth-constraint> 
    <user-data-constraint> 
     <description>SSL not required</description> 
     <transport-guarantee>NONE</transport-guarantee> 
    </user-data-constraint> 
</security-constraint> 

Ich möchte alle Seiten unter/admin/* geschützt werden und das funktioniert. Der Benutzer sieht zunächst korrekt einen Login-Bildschirm und wird anschließend auf die ursprünglich angeforderte Seite umgeleitet.

Ich möchte auch meine Kontext root geschützt: http://host:port/context/ Wenn ich jedoch das Muster <url-pattern></url-pattern> konfigurieren und eine Anfrage an den Stamm, mein Java-Controller nur zu arbeiten beginnt und zeigt die Ansicht ohne den Benutzer jemals den Anmeldebildschirm zu sehen. Warum funktioniert dieses Muster für Dinge wie <servlet-mapping> (um die Anfrage dem Feder-Servlet zuzuordnen), aber nicht als Sicherheitsbeschränkung?

Ich habe sowohl in Chrome und Firefox getestet und mehrfach neu gestartet.

+0

Haben Sie/* für Ihre Root-Kontext-Konfiguration? – aksappy

+0

@aksappy Nein, weil/* als URL-Muster bedeutet "fange alle Anfragen", ich will das nicht, nur den Wurzelkontext. Zum Beispiel sollte /otherpage.do weiterhin ohne Berechtigung arbeiten. – user1884155

+0

Gemäß der Spezifikation, was Sie getan haben, ist richtig. – aksappy

Antwort

0

Sie könnten versuchen, Whitelist-Ansatz, es bedeutet Zugriff nur für öffentliche Ressource geben.

Here is a better answer mit Beispiel, aber in Ihrem Fall sollte wie folgt sein:

<security-constraint> 
    <web-resource-collection> 
    <web-resource-name>webPages</web-resource-name> 
    <description>All web resources</description> 
    <url-pattern>/</url-pattern> 
    <http-method>POST</http-method> 
    <http-method>GET</http-method> 
    </web-resource-collection> 
    <auth-constraint> 
    <role-name>admins</role-name> 
    </auth-constraint> 
    <user-data-constraint> 
    <description>SSL not required</description> 
    <transport-guarantee>NONE</transport-guarantee> 
    </user-data-constraint> 
</security-constraint> 
<security-constraint> 
    <web-resource-collection> 
    <web-resource-name>Public Resources</web-resource-name> 
    <url-pattern>/public/*</url-pattern> 
    <url-pattern>/alsopublic</url-pattern> 
    <url-pattern>...an so on...</url-pattern> 
    </web-resource-collection> 
    <!-- to given public access don't set auth-constraint--> 
</security-constraint> 

Edit: Ref servlet 3 specification

+0

Dies funktioniert nicht. Der Server weiß, dass der Root jetzt "gesichert" ist, aber wenn er versucht, auf die Login-Seite umzuleiten, die sich unter /login.do befindet, wird diese Anfrage blockiert. Nach ein paar Sekunden bekomme ich eine Fehlermeldung auf dem Server, dass die maximale Anzahl an Threads erstellt wurde, was auf eine Endlosschleife hinweist. Auch der Link zu den Spezifikationen des Servlet 3 funktioniert nicht für mich: Ich bin nicht berechtigt, diese Anfrage auszuführen, wie es scheint. – user1884155

+0

Ich verstehe Ihren Kommentar nicht: ¿/ sichern Sie die Wurzel nur so wie es sein sollte. Geben Sie auch an, was /login.do nach der Anmeldung des Benutzers tut (z. B. welche Weiterleitungen). – Guillermo

+0

durch Deklaration /, Es sichert auch alle meine anderen Inhalte, nicht nur die Wurzel. Ich denke, das ist/ist nicht die richtige Art, den Kontextstamm zu beschreiben. Laut Servlet 3.0 ist das korrekte URL-Muster die leere Zeichenfolge. – user1884155