Have to login in twice with SSL enabled

[momatej]

Little intro. I had this problem with last version of acegi, security 2 and now I upgraded to security 3 and it is still the same.
Problem being that after I logout from not secured content (only login.html page is secured) I have to submit the login information twice in order to go to my account.

Tomcat config:

    
<Connector 
    port="443" 
    protocol="org.apache.coyote.http11.Http11NioProtocol" <!-- tried all java protocols here and it is the same with each one -->
    maxThreads="150" 
    scheme="https" 
    secure="true" 
    SSLEnabled="true"
    clientAuth="want" 
    keystoreFile="c:\Program Files\Apache Software Foundation\Tomcat 6.0\conf\cert\tomcat.keystore" keystorePass="topsecretstuff"  keyAlias="tomcat"
    />

Application Context:

<bean id="filterChainProxy" class="org.springframework.security.web.FilterChainProxy">
        <security:filter-chain-map path-type="ant">
            <security:filter-chain pattern="/**"
                                   filters="channelProcessingFilter, <!-- without this it works nice and but NO https login -->
                                   httpSessionContextIntegrationFilter,
                                   securityContextPersistenceFilter,
                                   logoutFilter,
                                   usernamePasswordAuthenticationFilter,                                       
                                   rememberMeProcessingFilter,
                                   anonymousProcessingFilter,
                                   exceptionTranslationFilter,
                                   filterInvocationInterceptor"/>
        </security:filter-chain-map>
    </bean>

    <bean id="channelProcessingFilter" class="org.springframework.security.web.access.channel.ChannelProcessingFilter">
        <property name="channelDecisionManager" ref="channelDecisionManager"/>
        <property name="securityMetadataSource">
            <security:filter-security-metadata-source path-type="ant" lowercase-comparisons="true">
                <security:intercept-url pattern="/login.html" access="REQUIRES_SECURE_CHANNEL"/>
                <security:intercept-url pattern="/j_spring_security_check" access="REQUIRES_SECURE_CHANNEL"/>
                <security:intercept-url pattern="/images/**" access="ANY_CHANNEL"/>
                <security:intercept-url pattern="/css/**" access="ANY_CHANNEL"/>
                <security:intercept-url pattern="/**" access="REQUIRES_INSECURE_CHANNEL"/>
            </security:filter-security-metadata-source>
        </property>
    </bean>

Funny thing is that there is nothing in logs. Everything looks as it should. If I add this to channelProcessingFilter:

<security:intercept-url pattern="/account/**" access="REQUIRES_SECURE_CHANNEL"/>

The login works just fine but when I try to go to any
http:/host/**
page there is no user present. But if I go to
http:/host/account/**
the user shows up. And I have to logout from https:/host/j_spring_security_logout
because the
http:/host/j_spring_security_logout
doesn't work.

I even got the new book "Spring Security 3" from Peter Mularien just because of this but no luck. Got some nice ideas from it though.

I'm pulling my hear out here for 2 days now. Please HELP

[Luke Taylor]

Check the FAQ on logging in over HTTPS. This is probably the issue.

[momatej]

I got this from the FAQ:

This happens because sessions created under HTTPS, for which the session cookie is marked as “secure”, cannot subsequently be used under HTTP. The browser will not send the cookie back to the server and any session state will be lost (including the security context information). Starting a session in HTTP first should work as the session cookie won't be marked as secure.

The question is now, how do I start the session in HTTP?

Also I found following thread:
http://forum.springsource.org/showthread.php?t=72946
But still there is no mention about how to start the session in HTTP with cookie not marked secure.

How does the cookie crumble

[momatej]

I found this thread:
http://forum.springsource.org/showthread.php?t=65651

And both solution on the bottom seem to be working fine.

Bless you csw199 !!!

SOMEONE SHOULD UPDATED THE FAQs

[Luke Taylor]

SOMEONE SHOULD UPDATED THE FAQs

What do you think it should say?

Some people should also read it first .

[momatej]

In all fairness I have been reading for 3 days and it hard to find info! Either you get lucky you find it right away or you spend $50 (Spring Security 3) on book go through the whole thing (plus give google run for its money) and have still nothing to show for it.
I know you were just kidding but I though I get this out before I blow aneurysm

In the FAQs mention of httpsCookieFilter in web.xml would help me tremendously instead of just saying make the cookies not secure. Also the mentioning of how remember_me plays role in it would be of great help.

[Luke Taylor]

Well, I'm only partly kidding. If you search Google for "Spring Security" then the FAQ is one of the clearly listed links in the first result and this is a question that comes up repeatedly. I realise that there are lots of things to learn and it can be frustrating, but this is a general issue to do with web applications and the use of secure cookies (you will also find it heavily discussed in tomcat forums and lists and elsewhere on the web). It's not something that is specific to Spring Security and the exact behaviour is likely to vary between different servlet containers and versions, so I don't think it's fair to lay the blame at omissions in the FAQ.

I don't think either of the options suggested in the other thread are generally applicable. Remember-me is not desirable in many applications and the use of JSESSIONID is a container issue and not something an application should be setting explicitly. There's no guarantee that will work in other servers. Application requirements vary widely and it's ultimately up to the developers to understand and control how and when sessions are created.

[pmularien]

Darn, I should have added something to the book saying to read the FAQ

I'm sorry that you didn't find the answer you were looking for in the book, but I hope it helped you in other areas!