Announcement Announcement Module
No announcement yet.
HttpSessionListener issue when upgrading from 2.0.4 to 3.0.3 Page Title Module
Move Remove Collapse
This topic is closed
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • HttpSessionListener issue when upgrading from 2.0.4 to 3.0.3

    HttpSessionListener issue when upgrading from 2.0.4 to 3.0.3

    Hi all,

    I have a HttpSessionListener implementation that used to work in 2.0.4 version and is not working in the 3.0.3 version.

    The code with the issue is in sessionCreated(...):

    	public void sessionCreated(HttpSessionEvent se) {
    		log.debug("Session Created ...");
    		SecurityContext securityContext = SecurityContextHolder.getContext();
    		if (securityContext != null) {
    			log.debug("securityContext != null " + securityContext.getClass().getName() );
    			Authentication authentication = securityContext.getAuthentication(); // Here I get null while in old version has worked
    			if(authentication != null) {
    				log.debug("authentication != null " + authentication.getClass().getName());
    				Object principal = authentication.getPrincipal();
    				if(principal != null) {
    					log.debug("principal != null " + principal.getClass().getName());
    					if (principal instanceof User) {
    						User user = (User) principal;
    						log.debug("User Exists!");
    						List<MenuItem> menuItems = MenuHelper.getMenuItemsForRole(user.getRolesAsString());
    						se.getSession().setAttribute(WebConstants.MENU_ITEMS, menuItems);
    			else {
    				log.debug("authentication IS null");
    The issue is that after login the Authentication is populated in SecurityContext after the call of sessionCreated(...) and at the moment when I call it is null.

    The log after login is:

    DEBUG com.devbis.webapp.listener.SessionListener sessionCreated (43) - Session Created ...
    DEBUG com.devbis.webapp.listener.SessionListener sessionCreated (48) - securityContext != null
    DEBUG com.devbis.webapp.listener.SessionListener sessionCreated (67) - authentication IS null
    DEBUG onAuthentication (94) - Started new session: F9C86192C58E2291B549ABF0A13F14C7
    DEBUG successfulAuthentication (289) - Authentication success. Updating SecurityContextHolder to contain: org.springframew[email protected]441d0230: Principal: [email protected]
    Can I still use this approch to set a session attribute when I have a new session with a sucessful authentication in 3.0.3?
    If not what is the recomended approch in 3.0.3?

    As a reference the security config is:

    <?xml version="1.0" encoding="UTF-8"?>
    <beans:beans xmlns="" 
        <http auto-config="true" lowercase-comparisons="false">
            <intercept-url pattern="/admin/*" access="ROLE_ADMIN"/>
            <intercept-url pattern="/passwordHint.html*" access="ROLE_ANONYMOUS,ROLE_ADMIN,ROLE_USER"/>
            <intercept-url pattern="/signup.html*" access="ROLE_ANONYMOUS,ROLE_ADMIN,ROLE_USER"/>
            <intercept-url pattern="/**/*.html*" access="ROLE_ADMIN,ROLE_USER"/>
            <form-login login-page="/login.jsp" authentication-failure-url="/login.jsp?error=true" login-processing-url="/j_security_check"/>
            <remember-me user-service-ref="userDao" key="e37f4b31-0c45-11dd-bd0b-0800200c9a66"/>
    		<authentication-provider user-service-ref="userDao"> 
    			<password-encoder ref="passwordEncoder"/> 
            <protect-pointcut expression="execution(* *..service.UserManager.getUsers(..))" access="ROLE_ADMIN"/>
            <protect-pointcut expression="execution(* *..service.UserManager.removeUser(..))" access="ROLE_ADMIN"/>
    Thank you,

  • #2
    I think this is a bit of an unreliable strategy - assuming that the context has already been populated at the point that a session is created. There is no guarantee that this will be the case and even if it works for a while, a change in your application could break it.

    It looks like something that is part of your UI configuration, so perhaps it would be better addressed in the controller which renders the menu. You could cache the role-based menus there, rather than having a reference in each user session, and render the appropriate one based on the current user's role.