Grails is a simple application for testing spring secure channel security on Heroku

Question

Since the port settings in this question did not solve the redirection problem, I created a bare-bone testing application (grails 2.0, latest spring - security-core 1.2.7.1), so the redirection loop problem can be easily reproduced / hopefully solved: Here are the steps:

1- Created a new application called test and created a controller called simple (also in the test suite), that is:

package test class SimpleController { def index() { redirect action: 'start' } def start() { render "start - not secure" } def middle() { render "middle - secure" } def end() { render "end - not secure" } } 

2- Did grails install spring-security-core , as well as grails s2-quickstart test User Role

3- The following lines are added to Config.groovy, and then run-app -https to test on my dev machine:

  grails.plugins.springsecurity.secureChannel.definition = [ '/simple/middle/**': 'REQUIRES_SECURE_CHANNEL', '/simple/end/**': 'REQUIRES_INSECURE_CHANNEL', '/simple/**': 'ANY_CHANNEL' ] 

RESULT: all checks can enter ../ simple / start URLs, and then .. / simple / middle enter the SSL / https mode as desired.

4- In Config.groovy, I then configured the ports to run on Heroku (guestimate, docs / refs not found):

  grails.plugins.springsecurity.portMapper.httpPort = '80' grails.plugins.springsecurity.portMapper.httpsPort = '443' 

5 After completing the git init steps , add git. , git commit -m "initial commit" and heroku create --stack cedar , I went to Heroku and added PiggyBack SSL to the newly created application there. Then I applied git push heroku master .

RESULT: Received a general "IllegalStateException, no thread-related requests were found", the problem is described here and here .

6. Thus, in BuildConfig.groovy, I made the following 2 changes to the plugins section {}:

  //runtime ":resources:1.1.5" compile ":webxml:1.4.1" 

RESULT: IllegalStateException leaves, and I can access a simple controller (and an input controller). I can prefix these URLs using https and all is well. However, if I enter the URL ../ simple / middle, I get a redirect loop (traces similar to here ).

7- Out of curiosity, I commented on half the changes in step 6, namely: // compile: "webxml: 1.4.1":

RESULT: got the same IllegalStateException

8- Since I was not sure that the hero support plugins and the clouds included in the main steps described above, I was waiting to add them before this step. Then I did grails install-plugin cloud-support and grails install-plugin heroku , as well as the updated BuildConfig.groovy, so now it looks like this:

  plugins { runtime ":hibernate:$grailsVersion" runtime ":jquery:1.7.1" //runtime ":resources:1.1.5" //compile ":webxml:1.4.1" compile ':heroku:1.0' compile ':cloud-support:1.0.8' compile ":tomcat:$grailsVersion" } 

and then made a clean and updated git repository and clicked on the hero.

RESULT: same IllegalStateException (note that the webxml dependency is commented out).

9- Then I compiled the compilation ": webxml: 1.4.1" and again clicked on the hero:

RESULT: exactly the same as in step 3. Ie, with the exception of .. / simple / middle, all URLs work, including adding the https prefix. Going to the URL ../ simple / middle causes a problem with the redirect content.

Could you advise how to solve this? If there is something for me to try (that is, an unspecified solution), just refresh the comments section and I will reply back with the results. Many thanks.

----------------------------------------------- --- ----------------------------------------

Update using the new spring-security 1.2.7.2.

Now My BuildConfig.groovy:

  dependencies { // specify dependencies here under either 'build', 'compile', 'runtime', 'test' or 'provided' scopes eg. runtime 'mysql:mysql-connector-java:5.1.16' } plugins { runtime ":hibernate:$grailsVersion" runtime ":jquery:1.7.1" runtime ":resources:1.1.6" compile ":spring-security-core:1.2.7.2" compile ":webxml:1.4.1" compile ':heroku:1.0' compile ':cloud-support:1.0.8' build ":tomcat:$grailsVersion" } 

Got a PostGres dependency error deployed to Heroku, although using MySql. So I uninstalled all the applications on Heroku and blew off my git repository and started with a new deployment / update application.

Still getting this PostGres dependency error (below). Note. If you find the transaction manager "No Transactions", if you need a web application, please configure it in advance when MySql was running. Hm.

  12-02-03T07:18:09+00:00 app[web.1]: 2012-02-03 07:18:09.810:INFO:omjr.Runner:Runner 12-02-03T07:18:09+00:00 app[web.1]: 2012-02-03 07:18:09.811:WARN:omjr.Runner:No tx manager found 12-02-03T07:18:09+00:00 app[web.1]: 2012-02-03 07:18:09.852:INFO:omjr.Runner:Deploying file:/app/target/momentum-0.1.war @ / 12-02-03T07:18:09+00:00 app[web.1]: 2012-02-03 07:18:09.869:INFO:oejs.Server:jetty-7.xy-SNAPSHOT 12-02-03T07:18:09+00:00 app[web.1]: [oejwWebAppContext{/,null},file:/app/target/momentum-0.1.war] 12-02-03T07:18:09+00:00 app[web.1]: 2012-02-03 07:18:09.915:INFO:oejw.WebInfConfiguration:Extract jar:file:/app/target/momentum-0.1.war!/ to /tmp/jetty-0.0.0.0-43683-momentum-0.1.war-_-any-/webapp 12-02-03T07:18:14+00:00 app[web.1]: 2012-02-03 07:18:14.500:INFO:oejpw.PlusConfiguration:No Transaction manager found - if your webapp requires one, please configure one. 12-02-03T07:18:18+00:00 app[web.1]: 2012-02-03 07:18:18.361:INFO:/:Initializing Spring root WebApplicationContext 12-02-03T07:18:24+00:00 app[web.1]: 12-02-03T07:18:24+00:00 app[web.1]: Configuring Spring Security Core ... 12-02-03T07:18:24+00:00 app[web.1]: ... finished configuring Spring Security Core 12-02-03T07:18:24+00:00 app[web.1]: 12-02-03T07:18:24+00:00 app[web.1]: 2012-02-03 07:18:24.490:WARN:oejw.WebAppContext:Failed startup of context oejwWebAppContext{/,file:/tmp/jetty-0.0.0.0-43683-momentum-0.1.war-_-any- /webapp/},file:/a /target/momentum-0.1.war 12-02-03T07:18:24+00:00 app[web.1]: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'transactionManagerPostProcessor': Initialization of bean failed; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'transactionManager': Cannot resolve reference to bean 'sessionFactory' while setting bean property 'sessionFactory'; ************************************************************ nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'sessionFactory': Cannot resolve reference to bean 'lobHandlerDetector' while setting bean property 'lobHandler'; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'lobHandlerDetector': Invocation of init method failed; nested exception is org.springframework.jdbc.support.MetaDataAccessException: Error while extracting DatabaseMetaData; nested exception is org.apache.commons.dbcp.SQLNestedException: Cannot load JDBC driver class 'org.postgresql.Driver' ************************************************************* 12-02-03T07:18:24+00:00 app[web.1]: at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:527) 12-02-03T07:18:24+00:00 app[web.1]: at org.codehaus.groovy.grails.commons.spring.ReloadAwareAutowireCapableBeanFactory.doCreateBean(ReloadAwareAutowireCapableBeanFactory.java:126) 12-02-03T07:18:24+00:00 app[web.1]: at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:456) 12-02-03T07:18:24+00:00 app[web.1]: at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:294) 12-02-03T07:18:24+00:00 app[web.1]: at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:225) 12-02-03T07:18:24+00:00 app[web.1]: at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:291) 12-02-03T07:18:24+00:00 app[web.1]: at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:197) 12-02-03T07:18:24+00:00 app[web.1]: at org.springframework.context.support.AbstractApplicationContext.registerBeanPostProcessors(AbstractApplicationContext.java:707) 12-02-03T07:18:24+00:00 app[web.1]: at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:449) 12-02-03T07:18:24+00:00 app[web.1]: at org.codehaus.groovy.grails.commons.spring.DefaultRuntimeSpringConfiguration.getApplicationContext(DefaultRuntimeSpringConfiguration.java:153) 12-02-03T07:18:24+00:00 app[web.1]: at org.codehaus.groovy.grails.commons.spring.GrailsRuntimeConfigurator.configure(GrailsRuntimeConfigurator.java:124) 12-02-03T07:18:24+00:00 app[web.1]: at org.codehaus.groovy.grails.commons.spring.GrailsRuntimeConfigurator.configure(GrailsRuntimeConfigurator.java:165) 12-02-03T07:18:24+00:00 app[web.1]: at org.codehaus.groovy.grails.web.context.GrailsConfigUtils.configureWebApplicationContext(GrailsConfigUtils.java:121) 12-02-03T07:18:24+00:00 app[web.1]: at org.codehaus.groovy.grails.web.context.GrailsContextLoader.initWebApplicationContext(GrailsContextLoader.java:104) 12-02-03T07:18:24+00:00 app[web.1]: at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:111) 12-02-03T07:18:24+00:00 app[web.1]: at org.eclipse.jetty.server.handler.ContextHandler.startContext(ContextHandler.java:643) 12-02-03T07:18:24+00:00 app[web.1]: at org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:233) 12-02-03T07:18:24+00:00 app[web.1]: at org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1213) 12-02-03T07:18:24+00:00 app[web.1]: at org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:589) 12-02-03T07:18:24+00:00 app[web.1]: at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:454) 12-02-03T07:18:24+00:00 app[web.1]: at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:59) 12-02-03T07:18:24+00:00 app[web.1]: at org.eclipse.jetty.server.handler.HandlerCollection.doStart(HandlerCollection.java:224) 12-02-03T07:18:24+00:00 app[web.1]: at org.eclipse.jetty.server.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:167) 12-02-03T07:18:24+00:00 app[web.1]: at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:59) 12-02-03T07:18:24+00:00 app[web.1]: at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:59) 12-02-03T07:18:24+00:00 app[web.1]: at org.eclipse.jetty.server.handler.HandlerWrapper.doStart(HandlerWrapper.java:89) 12-02-03T07:18:24+00:00 app[web.1]: at org.eclipse.jetty.server.Server.doStart(Server.java:261) 12-02-03T07:18:24+00:00 app[web.1]: at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:59) 12-02-03T07:18:24+00:00 app[web.1]: at org.mortbay.jetty.runner.Runner.run(Runner.java:500) 12-02-03T07:18:24+00:00 app[web.1]: at org.mortbay.jetty.runner.Runner.main(Runner.java:639) 12-02-03T07:18:24+00:00 app[web.1]: at org.eclipse.jetty.server.handler.HandlerCollection.doStart(HandlerCollection.java:224) 

Answer 1

It’s probably better not just to accidentally hack things if you don’t know why it is there :)

The IllegalStateException is thrown due to incorrect ordering of the filter-mapping elements in web.xml. Both spring-security-core and resources positioned the filter-mapping elements and attacked each other, so we updated the webxml plugin to support this by convention and made both plugins depend on it. Due to errors when evicting plugins with different dependent versions of plugins, it is important that you use spring-security-core versions and resources that depend on the same webxml version.

New 2.0 applications declare a dependency on resources 1.1.5, which uses webxml v1.4, and spring-security-core 1.2.7+ uses 1.4.1, so you need to either not use resources or use version 1.1 +0.6. Then there is no ambiguity and the correct version will be used, and the order of web.xml will be correct. You must also register all plugins in BuildConfig and not use install-plugin; this will save everything in one place and allow you to define exceptions, etc.

This is all independent of SSL issues, so it’s best to focus on one issue at a time. I have not used SSL on Heroku, so I don’t know which ports they use. I assume that inside the firewall they use something other than 443, and then the requests are routed to 443. But it does not depend on Grails and the spring-security-core plugin, so figuring out how SSL is configured is just a common problem with the documentation.

Update

Ok, so based on a workaround in the link, James posted a new version of the Spring Security plugin (v1.2.7.2) with support for X-Forwarded-Proto. Add grails.plugins.springsecurity.secureChannel.useHeaderCheckChannelSecurity = true to Config.groovy and it will use this approach instead of a more simplified security / insecurity check. And the IllegalStateException exception is due to an error in how Heroku deploys Grails 2.0 applications. Plugin dependencies are not resolved when building a war, so you need to be explicit. Therefore, do not forget to add

 compile ":spring-security-core:1.2.7.2" compile ':webxml:1.4.1' compile ":heroku:1.0" compile ':cloud-support:1.0.8' 

to BuildConfig.groovy to make sure that webxml (spring-security-core dependency) and cloud support (hero dependency) are installed and deployed.