Announcement Announcement Module
Collapse
No announcement yet.
question about sessionId management Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • question about sessionId management

    Hi,
    I use Spring security
    originaly I had the following problem: when a user connect on my application the Daos will connect to the data base schema that is selected on the first home page combobox.

    One very anoising problem appeared when the same user connects twice on the same browser on 2 different tabs and on each tab connect to different data base schema. The curious thing is that the 2 connections share the same sessionId. So if the first user on the first tab TAB1 select a schema SCHEMA1 then go to the next tab TAB2, select a schema SCHEMA2 (so that the selected schema for both connection is SCHEMA2), then go back to TAB1 and make an operation, he thinks that he is working on schema SCHEMA1 while he is actually making the operation on SCHEMA2.

    Is there a way to tell Spring to generate each time a new session even if it is the same user with the same credentials (userName/password) working from the same computer and the same browser ?

    as the 2 tabs connection share the same session, I thought about generating a random number at the first access to he home page, put it in the session, and check on each access (I have a index controller that is called after authentication to display the home page) that this number is null (the initial value of that random number) so that if that session parameter is not null it means that the user is connecting on the same browser from the same computer and I block the access (redirect to error page).
    On redirected page I propose to open a new Browser page (of the same browser), but I have again the same session on this reconnection

    So how can I manage all this ?

    I have also some general questions about session. is the session created by the browser or is it created by the server side ? I suppose that as long as the user connect by a userName/password form, a session is created by the browser. But it seems that the sessionId is generated by the server side and in particular by Spring Security. So what is the difference between session and sessionId. Is it possible to have a session created on the client side and that the server gives it an identifier depending on the choosen session strategy in Spring Security ?

    And is the browser that is recording the sessionId in a cookie is able to make the difference between 2 connection by the same user on the same application (server) with the same credentials on two different tab or window ?

    I give you an extract of spring-security.xml file

    Code:
    
        <beans:bean id="authenticationSuccessHandler" class="com.security.AuthenticationSuccessHandlerImpl"
                    p:defaultTargetUrl="/secure/index.htm">
            <beans:property name="userManagementService" ref="userManagementService"/>
            <beans:property name="accountManagementService" ref="accountManagementService"/>
        </beans:bean>
        <beans:bean id="authenticationFailureHandler" class="com.security.AuthenticationFailureHandlerImpl"
                    p:defaultFailureUrl="/login.htm">
            <beans:property name="userManagementService" ref="userManagementService"/>
        </beans:bean>
    
        <beans:bean id="authenticationSuccessHandlerReconnect" class="com.security.AuthenticationSuccessReconnectionHandlerImpl">
            <beans:property name="userManagementService" ref="userManagementService"/>
            <beans:property name="accountManagementService" ref="accountManagementService"/>
        </beans:bean>
        <beans:bean id="authenticationFailureHandlerReconnect" class="com.security.AuthenticationFailureReconnectionHandlerImpl">
            <beans:property name="userManagementService" ref="userManagementService"/>
        </beans:bean>
    
        <beans:bean id="authenticationProvider"
                    class="org.springframework.security.authentication.dao.DaoAuthenticationProvider">
            <beans:property name="passwordEncoder" ref="passwordEncoder"/>
            <beans:property name="saltSource" ref="saltSource"/>
            <beans:property name="userDetailsService" ref="userManagementService"/>
        </beans:bean>
    
        <authentication-manager alias="authenticationManager">
            <authentication-provider ref="authenticationProvider">
                <password-encoder ref="passwordEncoder"/>
            </authentication-provider>
        </authentication-manager>
    
        <beans:bean id="authenticationFilter" class="com.security.UserNamePasswordTokenAuthenticationFilter">
            <beans:property name="authenticationManager" ref="authenticationManager"/>
            <beans:property name="filterProcessesUrl" value="/j_spring_security_check"/>
            <beans:property name="authenticationSuccessHandler" ref="authenticationSuccessHandler"/>
            <beans:property name="authenticationFailureHandler" ref="authenticationFailureHandler"/>
            <beans:property name="userManagementService" ref="userManagementService"/>
        </beans:bean>
    
        <beans:bean id="authenticationEntryPoint"
                    class="org.springframework.security.web.authentication.LoginUrlAuthenticationEntryPoint">
            <beans:property name="loginFormUrl" value="/login.htm"/>
        </beans:bean>
    
        <beans:bean class="com.security.SecurityContextLogoutHandler"
                    name="logoutHandler">
        </beans:bean>
    
        <http entry-point-ref="authenticationEntryPoint" disable-url-rewriting="true">
            <!--Restrict URLs based on role-->
            <intercept-url pattern="/css/**" filters="none" requires-channel="https"/>
            <intercept-url pattern="/js/**" filters="none" requires-channel="https"/>
            <intercept-url pattern="/ext/**" filters="none" requires-channel="https"/>
            <intercept-url pattern="/img/**" filters="none" requires-channel="https"/>
            <intercept-url pattern="/userguide/**" access="IS_AUTHENTICATED_ANONYMOUSLY" requires-channel="https"/>
            <intercept-url pattern="/login.htm*" access="IS_AUTHENTICATED_ANONYMOUSLY" requires-channel="https"/>
            <!--  requires-channel="https"/> -->
            <intercept-url pattern="/login.jsp*" access="ROLE_RDE" requires-channel="https"/>
            <intercept-url pattern="/user/**" access="IS_AUTHENTICATED_ANONYMOUSLY" requires-channel="https"/>
            <intercept-url pattern="/secure/**" access="ROLE_RDE" requires-channel="https"/>
            <intercept-url pattern="/**" access="IS_AUTHENTICATED_ANONYMOUSLY" requires-channel="https"/>
            <custom-filter position="FORM_LOGIN_FILTER" ref="authenticationFilter"/>
            <session-management invalid-session-url="/reconnection.htm">
                <!--<concurrency-control max-sessions="1" error-if-maximum-exceeded="true"/> -->
            </session-management>
            <logout logout-success-url="/login.htm"/>
        </http>
    Any response, ideas, links to internet site, explaination or even solution will greatly much appreciated because it is an urgent need asked by our client
    Last edited by flamant; Jul 21st, 2012, 10:44 AM. Reason: security changes

  • #2
    There isn't much you can do about it... When opening a tab or a new window from the existing browser the session state is copied and as such the session is the same. As a work around in JSF and Spring Web Flow there is a conversation scope which is tied to the start of a process of a tab. But with plain MVC there isn't much you can do.

    Comment


    • #3
      Thanks a lot Marten

      Comment


      • #4
        Hi Marten,
        I think that it will interest you
        in fact we have found a way to have different session on the the same browser for 2 different tab or window connecting on the same application

        first we disable session cookie in tomcat (http://jf.omnis.ch/archives/2004/12/...in-tomcat.html).

        We had to make a change in our spring security xml file
        the initial extract is the following
        <http entry-point-ref="authenticationEntryPoint" disable-url-rewriting="true">
        <!--Restrict URLs based on role-->
        <intercept-url pattern="/css/**" filters="none" requires-channel="https"/>
        <intercept-url pattern="/js/**" filters="none" requires-channel="https"/>
        .........
        it became
        <http entry-point-ref="authenticationEntryPoint" >
        <!--Restrict URLs based on role-->
        <intercept-url pattern="/css/**" filters="none" requires-channel="https"/>
        <intercept-url pattern="/js/**" filters="none" requires-channel="https"/>
        .........

        And it almost completely works, we have 2 different session.

        I work with extjs and on almost all request sent to the server the sessionId is put after the url

        one example is the following

        "https://localhost:8443/something/index.htm;jsessionid=BEAA56EFC34E43B1E2222B3645BF8 955"

        I don't know how it is managed in the background. Does tomcat recognize the String jsessionid and manage the session or is it Spring's task? There is still one issue to solve. I have one request

        "https://localhost:8443/something/getSubjectsTreeNodes.htm?targetDivId=dataEntryCont ent"

        where there isn't any jsessionid after the url and by chance there is afterwards a login request that is sent to the server (I don't see why) and a javascript mistake in the extjs framework code that is dealing with encoding

        Before this failure, there has been 4 request sent to the server with jsessionid and the application proceeded without problem. May be you can give me a clue ?

        Thanks in advance for your answer

        Comment


        • #5
          If you want to introduce a security risk (it makes it easier to do session hijacking) next to that if one changes or removes the jsessionid there is no way to determine which to use (if there is also a cookie). Although it might (sort-of) work I wouldn't suggest going into production with something like this...

          Comment

          Working...
          X