Hi Thomas,
I think you're on the right track, all the pieces are in there. But you should
be careful about configuring Springs listener and the BlossomDispatcherServlet
in web.xml. The reason for this is that they will be started even when Magnolia
is in install/update mode. Therefore any beans you have in Spring that requires
Magnolia at startup will fail and BlossomDispatcherServlet will fail to
register templates, paragraphs and dialogs with Magnolia. You should try to
find out why you couldnt get it working when initializing them in your module.
Maybe the config locations weren't set properly?
If you start it up the way you have it now with a clean repository it will
likely fail.
Sorry if i'm causing you any lost sleep ;)
// Tobias
On Mar 8, 2011, at 1:31 PM, Thomas Duffey wrote:
> Thanks Tobias, I believe I have this working now. In case someone else goes
> down this road, here's a recap:
>
> I have a custom Magnolia module that uses Blossom to define some Magnolia
> Templates, a standard Spring Dispatcher with standard Spring Web MVC
> Controllers to handle requests for some non-Magnolia resources and Spring
> Security to apply security to the non-Magnolia resources. In web.xml I had
> to add (After the Magnolia context listener):
>
> <listener>
>
> <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
> </listener>
>
> <context-param>
> <param-name>contextConfigLocation</param-name>
> <param-value>
> classpath:applicationContext.xml
> classpath:dataAccessContext.xml
> classpath:security.xml
> </param-value>
> </context-param>
>
> <servlet>
> <servlet-name>foo</servlet-name>
>
> <servlet-class>info.magnolia.module.blossom.web.InstallationAwareDispatcherServlet</servlet-class>
> <load-on-startup>1</load-on-startup>
> </servlet>
>
> <servlet>
> <servlet-name>blossom</servlet-name>
>
> <servlet-class>info.magnolia.module.blossom.render.BlossomDispatcherServlet</servlet-class>
> <load-on-startup>1</load-on-startup>
> </servlet>
>
> <servlet-mapping>
> <servlet-name>foo</servlet-name>
> <url-pattern>/foo/*</url-pattern>
> </servlet-mapping>
>
> <filter>
> <filter-name>springSecurityFilterChain</filter-name>
>
> <filter-class>info.magnolia.module.blossom.web.InstallationAwareDelegatingFilterProxy</filter-class>
> </filter>
> <filter-mapping>
> <filter-name>springSecurityFilterChain</filter-name>
> <url-pattern>/*</url-pattern>
> </filter-mapping>
>
> The blossom-servlet.xml and foo-servlet.xml files also had to be added to
> Magnolia's WEB-INF folder. I would have preferred to initialize everything
> inside my module but for reasons I do not yet understand that did not work --
> everything ran but Spring Security didn't protect any URLs. No interest in
> losing even more sleep over this particular dilemma so I moved on.
>
> Next, I had to add two bypasses to Magnolia's CMS filter chain to prevent
> Magnolia from handling requests to my custom dispatcher (/foo/* above) and
> the default Spring Security URLs:
>
> 1) URI Starts With: /foo
> 2) URI Pattern: *spring_security*
>
> These bypasses are configured in Admin Central -> Configuration -> server ->
> filters -> cms -> bypasses. Finally, I extended Spring's JstlView to set
> Magnolia's DONT_DISPATCH_ON_FORWARD_ATTRIBUTE value to "true" when forwarding
> to JSP pages. Magnolia comes standard with a voter to check if this
> attribute is set and if so bypass the Magnolia filter chain.
>
> @Override
> protected void exposeForwardRequestAttributes(HttpServletRequest request) {
> super.exposeForwardRequestAttributes(request);
>
> request.setAttribute(DontDispatchOnForwardAttributeVoter.DONT_DISPATCH_ON_FORWARD_ATTRIBUTE,
> Boolean.TRUE);
> }
>
> I'm using this in my foo-servlet.xml's view resolver:
>
> <bean id="viewResolver"
> class="org.springframework.web.servlet.view.InternalResourceViewResolver">
> <property name="viewClass" value="com.foo.web.view.FooJstlView"/>
> <property name="prefix" value="/templates/foo/"/>
> <property name="suffix" value=".jsp"/>
> </bean>
>
> Now add about a million JARs to Magnolia's WEB-INF/lib and Bob's your uncle!
>
> Tom
>
> On Mar 8, 2011, at 3:57 AM, Tobias Mattsson wrote:
>
>>
>> Hi Thomas,
>>
>> I have seen this done in a project. As you probably know the Spring Security
>> filter (actually its a whole filter chain) is configured in your root
>> WebApplicationContext. You then configure a DelegatingFilterProxy in web.xml
>> that finds the filter in the context and delegates all requests to it.
>>
>> With Magnolia and Blossom you do it the same way, except instead of using
>> DelegatingFilterProxy you use InstallationAwareDelegatingFilterProxy from
>> Blossom. It will defer looking up the filter in the context until magnolia
>> has installed/updated and your module have created the root
>> WebApplicationContext.
>>
>> HTH,
>>
>> // Tobias
>>
>> On Mar 8, 2011, at 2:03 AM, Thomas Duffey wrote:
>>
>>>
>>> Hello,
>>>
>>> Has anyone successfully integrated Spring Security with Magnolia? I am
>>> working on this now to protect access to parts of our module but hoping to
>>> leave existing Magnolia-based security as-is. Trying to figure out where
>>> to configure the Spring Security filter chain. On another application that
>>> had its own filter chain I initialized the Spring Security filter chain in
>>> web.xml and then added the old filters as Spring Security custom filters
>>> but am not sure exactly how to accomplish something like this with Magnoila.
>>>
>>> Tom
>
> --
> Tom Duffey
> [email protected]
> 414-915-3915
>
>
>
>
>
> ----------------------------------------------------------------
> For list details see
> http://www.magnolia-cms.com/home/community/mailing-lists.html
> To unsubscribe, E-mail to: <[email protected]>
> ----------------------------------------------------------------
----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <[email protected]>
----------------------------------------------------------------
