Zajmuję się czystymi sposobami bezpieczeństwa programistycznego Java EE, zwłaszcza użytkownikami logowania, opartymi na dziedzinie jdbc z mojego serwera glassfish.

Tak w zasadzie w moim serwletie logowania, który robię

String username = request.getParameter("username");
String password = request.getParameter("password");

try {
    request.login(username, password);
....

Bez robienia niczego w moim pliku web.xml używana jest domyślna dziedzina (plik). Nie chcę tego, chcę używać jdbcRealm o nazwie jdbcsecurerealm.

Dodaję więc następujące informacje do mojego pliku web.xml

<login-config>
    <auth-method>FORM</auth-method>
    <realm-name>jdbcsecurerealm</realm-name>
</login-config>

Zauważ, że nie dodaję żadnego formularza-login-config do zdefiniowania formularza-strony logowania i strony-błędu-strony.

Następnie, jeśli zdefiniuję ograniczenia bezpieczeństwa, takie jak

<security-constraint>
    <web-resource-collection>
        <web-resource-name>Admin Pages</web-resource-name>
        <description></description>
        <url-pattern>/admin/*</url-pattern>
    </web-resource-collection>
    <auth-constraint>
        <role-name>administrator</role-name>
    </auth-constraint>
</security-constraint>

cóż ... to działa! Request.login sprawdza na moim jdbcRealm i jeśli spróbuję uzyskać dostęp do zabezpieczonych stron bez zalogowania się, otrzymuję niezły 403.

Ale wydaje mi się, że miksuję deklaratywne bezpieczeństwo i programowe bezpieczeństwo, ponieważ uważam, że nie powinienem deklarować niczego wewnątrz web.xml, ale raczej używać request.isUserInRole.

Pytanie:

Czy trafiam na specyficzne zachowanie glassfisha, czy może używać programowego bezpieczeństwa (request.login) z dziedziną jdbc zdefiniowaną wewnątrz web.xml bez formularza-login-config?

Aktualizacja Widziałem właśnie, że istnieje możliwość określenia dziedziny wewnątrz glassfish-application.xml, czy jest to lepsze podejście do budowania ucha zamiast wojny, aby określić dziedzinę?