Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

SEC-1327: Documentation: Session handling, spring_security_login, pre authenticated filters #1573

spring-issuemaster opened this Issue Dec 15, 2009 · 6 comments


None yet
1 participant

Edward Sargisson (Migrated from SEC-1327) said:

I believe the documentation could be better and say:

  1. The HttpSessionSecurityContextRepository will store the SecurityContext in the HttpSession if one exists even if the class has allowSessionCreation=false.
  2. spring_security_login creates a session.
  3. This means that AbstractPreAuthenticatedProcessingFilter may find the SecurityContext and not proceed with the pre-authentication path.
  4. A useful pre-authentication applicationContext-security.xml starting point would be useful. e.g. one that prevents session creation and doesn't use form-login.

I've been writing a pre-authentication filter to integrate with the RPX SaaS OpenID service. My application is REST so I never wanted a session to be created. As a starting point I used the expanded version of the http namespace configuration.

While writing my filter I assumed that there would be no session and therefore the successfulAuthentication() method would be called. In that method I have a redirect which I want to fire on a new sign-in.

However, if the user goes to a page as anonymous which does not allow access they get the spring_security_login. This creates a session which is then used on subsequent logins and the redirect doesn't happen.

I feel that a few improvements to the documentation would have prevented this defect.

Code snippets to explain my mistake:

RpxFilterImpl extends AbstractPreAuthenticatedProcessingFilter
protected void successfulAuthentication(HttpServletRequest request, HttpServletResponse response, Authentication authResult) {
if (getSessionCodeFromRequest(request) == null) {
User user = (User)authResult.getPrincipal();
Session session = sessionRepository.createSession(user);
Cookie sessionCookie = new Cookie(SESSION_COOKIE_NAME, session.getSessionCode());

    super.successfulAuthentication(request, response, authResult);

    // We get called for other urls so we only want to redirect
    // if this is an actual sign in.
    logger.debug("requestUri: " + request.getRequestURI());
    if (tokenUrl.equals(request.getRequestURI())) {
        try {
            redirectStrategy.sendRedirect(request, response, "/editPersonalRoute_extjs3.html");
        } catch (IOException e) {
            logger.error("Error during redirect from security", e);

Luke Taylor said:

If you choose to use form login, then it's pretty rare that you would be doing so without using a session. However, if you set create-session="never", then a session should not be created. If it is then it's a bug.

Likewise with spring_security_login, which shouldn't create a session unless it is allowed to. The only call to getSession() in the relevant class uses

if (loginError) {
HttpSession session = request.getSession(false);

If possible, please clarify where the session is being created.

Luke Taylor said:

Not a bug

Eyal said:

I newbie to Spring Frame work.
according to a book, that is my guide, I have to use FilterToBeanProxy for tunneling the security issue form the web.xml to Spring Framework.

How It can be done now?


Luke Taylor said:

Hi Eyal. This is not an appropriate place for asking random questions. Please read the documentation, look at the samples and use the support forum for any specific questions to which you cannot find an answer elsewhere.

Edward Sargisson said:

Luke: I agree this isn't a code defect. I do still think the documentation could be better though.

However, after your comment above I wanted to find where the session was being created (because I wanted to prove you wrong...) and, to my surprise, found that it was my index.jsp. Adding session="false" to the page directive solved the problem.

Therefore point 2 in this item is incorrect. However, I believe the changes in the rest of this item would be very useful.

Luke Taylor said:

I've added some extra Javadoc to HttpSessionSecurityContextRepository and AbstractPreAuthenticatedProcessingFilter and a minor addition to the suggestion in the docs about using a null implementation of SessionSecurityContextRepository to prevent if you don't want the context stored. I don't think it is the kind of thing that should have extensive coverage be in the user manual. There is already a pre-authentication sample with an configuration file. Making your application stateless is a separate concern and the most common error is that the user creates a session somewhere themselves (typically in a JSP, as was the case here).

@spring-issuemaster spring-issuemaster added this to the 3.0.0 milestone Feb 5, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment