Eclipse Community Forums: Virgo » snaps session sharing

Help

Home

Home » Eclipse Projects » Virgo » snaps session sharing

Show: Today's Messages :: Show Polls :: Message Navigator

snaps session sharing [message #668279]

Wed, 04 May 2011 19:40

Eric Hough

Messages: 14
Registered: July 2010

Junior Member

Following up on my use of Spring Security w/ Snaps post, I ran into another issue.

I'd like all my hosts and snaps to share the same security context, so when the user logs in via my /authenticate snap, another arbitrary snap can obtain the security context and thus identify the user.

The problem is that SnapHttpSession qualifies all its attribute names with ##/snapname. So in my case, the /authenticate snap stores the context into ##/authenticate.SPRING_SECURITY_CONTEXT. In turn, no other host/snap can read the security context.

I was able to fix this by simply getting rid of the qualifying mechanism, in essence allowing all snaps to share the exact same session attributes.

--- a/org.eclipse.virgo.snaps.core/src/main/java/org/eclipse/virgo/snaps/core/internal/webapp/container/SnapHttpSession.java
+++ b/org.eclipse.virgo.snaps.core/src/main/java/org/eclipse/virgo/snaps/core/internal/webapp/container/SnapHttpSession.java
@@ -54,7 +54,7 @@ public final class SnapHttpSession extends HttpSessionWrapper {
     }
 
     private String qualifyName(String baseName) {
-        return QUALIFIED_NAME_MARKER + this.snapServletContext.getSnapContextPath() + "." + baseName;
+        return baseName;
     }

We're only using the session for security, so this shouldn't bring up any other side effects for us. I saw a bit of discussion on the dev list regarding snaps sharing session state. Maybe this would be a good time to tackle the issue? I'm up for helping!

Report message to a moderator

Re: snaps session sharing [message #668365 is a reply to message #668279]

Thu, 05 May 2011 12:42

Dmitry Sklyut

Messages: 279
Registered: January 2010

Senior Member

Hi Eric,

You should not need to managed attributes in the shared session.

Here is an example of Spring Security config you can use on the snap side to get that done. Idea is that host does authentication but snap does authorization on the particular subset of urls.

<?xml version="1.0" encoding="UTF-8"?>
<beans:beans xmlns="http://www.springframework.org/schema/security"
             xmlns:beans="http://www.springframework.org/schema/beans"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
                                 http://www.springframework.org/schema/security http://www.springframework.org/schema/security/spring-security-3.0.xsd">

    <!-- manually configure the filter chain to better control security filter behavior -->
    <beans:bean id="springSecurityFilterChain" class="org.springframework.security.web.FilterChainProxy">
        <filter-chain-map path-type="ant">

            <!-- ignore static resources -->
            <filter-chain pattern="/r/**" filters="none"/>
            <filter-chain pattern="/assets/**" filters="none"/>

            <!-- ignore theme resources -->
            <filter-chain pattern="/themes/**" filters="none"/>

			<!-- only deal with urls for this slice -->
            <filter-chain pattern="/slice/**"
                          filters="customFilterSecurityInterceptor"/>
        </filter-chain-map>
    </beans:bean>

    <!-- FilterSecurityInterceptor - last filter in the filter chain  == FILTER_SECURITY_INTERCEPTOR -->
    <!-- in this set-up it is the only filter that we need, as host will provide authentication and exception translation mechanism -->
    <beans:bean id="customFilterSecurityInterceptor"
                class="org.springframework.security.web.access.intercept.FilterSecurityInterceptor">

        <!-- we will always have an authenticated request here - or at least we should -->
        <beans:property name="authenticationManager">
            <beans:bean class=".....PassThroughAuthenticationManager"/>
        </beans:property>
        <beans:property name="accessDecisionManager">
            <beans:bean class="org.springframework.security.access.vote.AffirmativeBased">
                <beans:property name="decisionVoters">
                    <beans:list>
                        <beans:bean class="org.springframework.security.access.vote.RoleVoter"/>
                        <beans:bean class="org.springframework.security.access.vote.AuthenticatedVoter"/>
                    </beans:list>
                </beans:property>
            </beans:bean>
        </beans:property>
        <beans:property name="securityMetadataSource">
            <!-- NOTE: url security configuration goes here -->
            <filter-security-metadata-source lowercase-comparisons="true" path-type="ant">
                <intercept-url pattern="/admin" access="ROLE_ADMIN"/>
                <intercept-url pattern="/admin/status" access="ROLE_ADMIN"/>
				.......
            </filter-security-metadata-source>
        </beans:property>
        <!-- THIS IS IMPORTANT - force it to re-evaluate -->
        <beans:property name="observeOncePerRequest" value="false"/>
    </beans:bean>
    <!-- end FilterSecurityInterceptor -->
</beans:beans>

PassThroughAuthenticationManager is very simple:

public final class PassThroughAuthenticationManager implements AuthenticationManager {
    @Override
    public Authentication authenticate(Authentication authentication) throws AuthenticationException {
        return authentication;
    }
}

Also make sure you have this flag set:

<!-- THIS IS IMPORTANT - force it to re-evaluate -->
        <beans:property name="observeOncePerRequest" value="false"/>

Ping back if you have questions.

Regards,
Dmitry

Report message to a moderator

Previous Topic:	Dependency Problem?
Next Topic:	osgi console

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Thu Apr 25 07:41:57 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter