403 - Доступ лишен после аутентификации

Question

Приветствую!

Когда я пытаюсь пройти аутентификацию против существующего db, я получаю аутентификацию, но я получаю страницу 403. Если я просто попробовал неправильный пароль, я получаю сообщение «неправильные учетные данные», как ожидалось. Я пробовал аутентифицировать приложение для примера, включенное в SpringSecurity, и это отлично работало.

безопасности context.xml:

<?xml version="1.0" encoding="UTF-8"?> 
<beans:beans 
    xmlns="http://www.springframework.org/schema/security" 
    xmlns:beans="http://www.springframework.org/schema/beans" 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 

    xsi:schemaLocation=" 
     http://www.springframework.org/schema/beans 
     http://www.springframework.org/schema/beans/spring-beans-2.0.xsd 
     http://www.springframework.org/schema/security 
     http://www.springframework.org/schema/security/spring-security-2.0.1.xsd"> 

    <global-method-security secured-annotations="enabled"></global-method-security> 

    <http auto-config="true" > 
     <intercept-url pattern="/admin/**" access="ROLE_TEST" /> 
     <intercept-url pattern="/**" access="IS_AUTHENTICATED_ANONYMOUSLY" /> 

     <form-login 
      login-page="/login/index.jsp" 
      default-target-url="/admin/test.jsp" 
      authentication-failure-url="/login/index.jsp?login_error=1" /> 
    </http> 

    <authentication-provider user-service-ref="jdbcUserService">  
     <password-encoder ref="passwordEncoder"> 
       <salt-source system-wide="n103df"/> 
     </password-encoder>   
    </authentication-provider> 


    <beans:bean id="jdbcUserService" class="org.springframework.security.userdetails.jdbc.JdbcDaoImpl"> 
     <beans:property name="rolePrefix" value="" /> 
     <beans:property name="dataSource" ref="dataSource" /> 
     <beans:property name="enableAuthorities" value="true"/> 
     <beans:property name="enableGroups" value="false"/> 
     <beans:property name="authoritiesByUsernameQuery" value="SELECT username,authority FROM authorities WHERE username = ?" /> 
     <beans:property name="usersByUsernameQuery" value="SELECT username,password,enabled as enabled FROM users WHERE username = ?" /> 
     <beans:property name="groupAuthoritiesByUsernameQuery" value="" /> 

    </beans:bean> 

<beans:bean id="passwordEncoder" class="org.springframework.security.providers.encoding.Md5PasswordEncoder"/> 

будет признателен за любую помощь :-) Заранее спасибо!

Answer 1

Если вы получаете код 403, это означает, что у пользователя нет необходимых ролей. Таким образом, аутентификация не является проблемой, является авторизацией.
Единственный способ узнать, что происходит, это установить уровень ведения журнала для отладки, должно быть больше информации. Отправьте его здесь.
Имеются ли в ваших ролях префикс «ROLE_»?

Answer 2

... выставлен. Несмотря на то, ROLE_TEST указанный в конфигурационном файле и то же в колонке «авторитетность» БД, весна-Sec ожидал ROLE_SUPERVISOR:

 
[DEBUG,AbstractSecurityInterceptor,http-8084-7] Secure object: FilterInvocation: URL: /admin/test.jsp; ConfigAttributes: [ROLE_TEST] 
[DEBUG,AbstractSecurityInterceptor,http-8084-7] Previously Authenticated: org.springframework.security.providers.UsernamePasswordAuthenticationToken@af840ed7: Principal: org.springframework.security.userdetails.User@3ec100: Username: testUser; Password: [PROTECTED]; Enabled: true; AccountNonExpired: true; credentialsNonExpired: true; AccountNonLocked: true; Granted Authorities: ROLE_SUPERVISOR; Password: [PROTECTED]; Authenticated: true; Details: org.springframework.security.ui.WebAuthenticationDetails@1c07a: RemoteIpAddress: 127.0.0.1; SessionId: 350B260FAFDDBF04D5CB4AAAB7B8A441; Granted Authorities: ROLE_SUPERVISOR 
[DEBUG,ExceptionTranslationFilter,http-8084-7] Access is denied (user is not anonymous); delegating to AccessDeniedHandler 
org.springframework.security.AccessDeniedException: Access is denied 
     at org.springframework.security.vote.AffirmativeBased.decide(AffirmativeBased.java:68) 

... теперь мне очень интересно, как прийти? Итак, после изменения ROLE_TEST в ROLE_SUPERVISOR в конфигурационном файле все работало так, как ожидалось.