Spring Security / SpringMVC'de kimliği doğrulanmış bir kullanıcı manuel olarak nasıl ayarlanır

Yeni bir kullanıcı bir 'Yeni hesap' formu gönderdikten sonra, sonraki sayfada oturum açmalarına gerek kalmaması için bu kullanıcıyı manuel olarak oturum açmak istiyorum.

Yaylı güvenlik önleyiciden geçen normal form giriş sayfası gayet iyi çalışıyor.

Yeni hesap formu denetleyicisinde bir UsernamePasswordAuthenticationToken oluşturuyorum ve bunu SecurityContext'te manuel olarak ayarlıyorum:

SecurityContextHolder.getContext().setAuthentication(authentication);

Aynı sayfada daha sonra kullanıcının şu şekilde oturum açtığını kontrol ediyorum:

SecurityContextHolder.getContext().getAuthentication().getAuthorities();

Bu, kimlik doğrulamasında daha önce belirlediğim yetkileri döndürür. Herşey iyi.

Ancak yüklediğim sonraki sayfada aynı kod çağrıldığında, kimlik doğrulama belirteci yalnızca UserAnonymous'dur.

Önceki talepte belirlediğim kimlik doğrulamasını neden saklamadığından emin değilim. Düşüncesi olan var mı?

• Oturum kimliğinin doğru ayarlanmaması ile bir ilgisi olabilir mi?
• Bir şekilde kimlik doğrulamamın üzerine yazan bir şey var mı?
• Belki de kimlik doğrulamayı kaydetmek için başka bir adıma ihtiyacım var?
• Veya bir şekilde tek bir istek yerine tüm oturum boyunca kimlik doğrulamasını bildirmek için yapmam gereken bir şey var mı?

Burada neler olduğunu görmeme yardımcı olabilecek bazı düşünceler arıyorum.

Bir süre önce seninle aynı sorunu yaşadım. Ayrıntıları hatırlayamıyorum, ancak aşağıdaki kod benim için işe yarayan şeyleri sağladı. Bu kod, bir Bahar Web Akışı akışında, dolayısıyla RequestContext ve ExternalContext sınıflarında kullanılır. Ancak sizinle en alakalı kısım doAutoLogin yöntemidir.

public String registerUser(UserRegistrationFormBean userRegistrationFormBean,
                           RequestContext requestContext,
                           ExternalContext externalContext) {

    try {
        Locale userLocale = requestContext.getExternalContext().getLocale();
        this.userService.createNewUser(userRegistrationFormBean, userLocale, Constants.SYSTEM_USER_ID);
        String emailAddress = userRegistrationFormBean.getChooseEmailAddressFormBean().getEmailAddress();
        String password = userRegistrationFormBean.getChoosePasswordFormBean().getPassword();
        doAutoLogin(emailAddress, password, (HttpServletRequest) externalContext.getNativeRequest());
        return "success";

    } catch (EmailAddressNotUniqueException e) {
        MessageResolver messageResolvable 
                = new MessageBuilder().error()
                                      .source(UserRegistrationFormBean.PROPERTYNAME_EMAIL_ADDRESS)
                                      .code("userRegistration.emailAddress.not.unique")
                                      .build();
        requestContext.getMessageContext().addMessage(messageResolvable);
        return "error";
    }

}


private void doAutoLogin(String username, String password, HttpServletRequest request) {

    try {
        // Must be called from request filtered by Spring Security, otherwise SecurityContextHolder is not updated
        UsernamePasswordAuthenticationToken token = new UsernamePasswordAuthenticationToken(username, password);
        token.setDetails(new WebAuthenticationDetails(request));
        Authentication authentication = this.authenticationProvider.authenticate(token);
        logger.debug("Logging in with [{}]", authentication.getPrincipal());
        SecurityContextHolder.getContext().setAuthentication(authentication);
    } catch (Exception e) {
        SecurityContextHolder.getContext().setAuthentication(null);
        logger.error("Failure in autoLogin", e);
    }

}

Başka tam çözüm bulamadım, bu yüzden benimkini göndereceğimi düşündüm. Bu biraz hack olabilir, ancak sorunu yukarıdaki soruna çözdü:

public void login(HttpServletRequest request, String userName, String password)
{

    UsernamePasswordAuthenticationToken authRequest = new UsernamePasswordAuthenticationToken(userName, password);

    // Authenticate the user
    Authentication authentication = authenticationManager.authenticate(authRequest);
    SecurityContext securityContext = SecurityContextHolder.getContext();
    securityContext.setAuthentication(authentication);

    // Create a new session and add the security context.
    HttpSession session = request.getSession(true);
    session.setAttribute("SPRING_SECURITY_CONTEXT", securityContext);
}

Sonunda sorunun kökenini anladım.

Güvenlik bağlamını manuel olarak oluşturduğumda, hiçbir oturum nesnesi oluşturulmadı. Spring Security mekanizması, yalnızca isteğin işlenmesi bittiğinde, oturum nesnesinin boş olduğunu fark eder (istek işlendikten sonra güvenlik içeriğini oturuma kaydetmeye çalıştığında).

Spring Security, isteğin sonunda yeni bir oturum nesnesi ve oturum kimliği oluşturur. Ancak bu yeni oturum kimliği, tarayıcıya yanıt verildikten sonra isteğin sonunda gerçekleştiği için hiçbir zaman tarayıcıya ulaşmaz. Bu, sonraki istek önceki oturum kimliğini içerdiğinde yeni oturum kimliğinin (ve dolayısıyla el ile oturum açan kullanıcımı içeren Güvenlik bağlamının) kaybolmasına neden olur.

Neler olup bittiğini daha iyi anlamak için hata ayıklama günlüğünü açın.

HTTP yanıtlarında döndürülen başlıklara bakmak için tarayıcı tarafında bir hata ayıklayıcı kullanarak oturum tanımlama bilgilerinin ayarlanıp ayarlanmadığını anlayabilirsiniz. (Başka yollar da var.)

Bir olasılık, SpringSecurity'nin güvenli oturum çerezleri ayarlaması ve istenen sonraki sayfanızın "https" URL'si yerine "http" URL'sine sahip olmasıdır. (Tarayıcı, "http" URL'si için güvenli bir çerez göndermez.)

Servlet 2.4'teki yeni filtreleme özelliği temelde filtrelerin yalnızca istek akışında uygulama sunucusu tarafından gerçek istek işlemeden önce ve sonra çalışabileceği kısıtlamasını hafifletir. Bunun yerine, Servlet 2.4 filtreleri artık her dağıtım noktasında istek dağıtıcısı ile etkileşime girebilir. Bu, bir Web kaynağı bir isteği başka bir kaynağa ilettiğinde (örneğin, isteği aynı uygulamadaki bir JSP sayfasına ileten bir sunucu uygulaması), istek hedeflenen kaynak tarafından işlenmeden önce bir filtre çalışabileceği anlamına gelir. Ayrıca, bir Web kaynağının diğer Web kaynaklarından (örneğin, diğer birçok JSP sayfasından çıktıyı içeren bir JSP sayfası) çıktı veya işlevi içermesi durumunda, Servlet 2.4 filtrelerinin, dahil edilen her bir kaynaktan önce ve sonra çalışabileceği anlamına gelir. .

Bu özelliği açmak için ihtiyacınız olan:

web.xml

<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>/<strike>*</strike></url-pattern>
    <dispatcher>REQUEST</dispatcher>
    <dispatcher>FORWARD</dispatcher>
</filter-mapping>

Kayıt Kontrolör

return "forward:/login?j_username=" + registrationModel.getUserEmail()
        + "&j_password=" + registrationModel.getPassword();

Bir extjs uygulamasını test etmeye çalışıyordum ve bir testAuthenticationToken'ı başarıyla ayarladıktan sonra bu, bariz bir neden olmadan aniden çalışmayı durdurdu.

Çalışmak için yukarıdaki cevapları alamadım, bu yüzden benim çözümüm test ortamında bu yayı atlamaktı. İlkbaharda şöyle bir dikiş koydum:

public class SpringUserAccessor implements UserAccessor
{
    @Override
    public User getUser()
    {
        SecurityContext context = SecurityContextHolder.getContext();
        Authentication authentication = context.getAuthentication();
        return (User) authentication.getPrincipal();
    }
}

Kullanıcı burada özel bir türdür.

Daha sonra, test kodunun yayı değiştirmesi için bir seçeneğe sahip olan bir sınıfa sarıyorum.

public class CurrentUserAccessor
{
    private static UserAccessor _accessor;

    public CurrentUserAccessor()
    {
        _accessor = new SpringUserAccessor();
    }

    public User getUser()
    {
        return _accessor.getUser();
    }

    public static void UseTestingAccessor(User user)
    {
        _accessor = new TestUserAccessor(user);
    }
}

Test sürümü şuna benzer:

public class TestUserAccessor implements UserAccessor
{
    private static User _user;

    public TestUserAccessor(User user)
    {
        _user = user;
    }

    @Override
    public User getUser()
    {
        return _user;
    }
}

Çağıran kodda hala veritabanından yüklenen uygun bir kullanıcıyı kullanıyorum:

    User user = (User) _userService.loadUserByUsername(username);
    CurrentUserAccessor.UseTestingAccessor(user);

Açıkçası, gerçekten güvenliği kullanmanız gerekiyorsa bu uygun olmayacaktır, ancak test dağıtımı için güvenliksiz bir kurulumla çalışıyorum. Başka birinin benzer bir durumla karşılaşabileceğini düşündüm. Bu, daha önce statik bağımlılıkları alay etmek için kullandığım bir model. Diğer alternatif ise, sarmalayıcı sınıfının durağanlığını koruyabilmenizdir, ancak bunu gerekli olduğu sınıflara CurrentUserAccessor'ı geçirmeniz gerektiğinden kodun bağımlılıkları daha açık olduğu için tercih ediyorum.