3

We are using the Swisscom Application Cloud to run our Spring Boot application. After their "Migration to multi-cloud environment" on 2018-02-22 (Swisscom Status Page), our application completely failed to serve any request.

The problem was found to be the automated redirection of HTTP to HTTPS. We were doing this in the SecurityConfiguration of our application like this:

@Configuration
public class SecurityConfiguration extends WebSecurityConfigurerAdapter {

    // [...]

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        // [...]
        if (env.acceptsProfiles(SPRING_PROFILE_PRODUCTION)) {
            http.requiresChannel().anyRequest().requiresSecure();
        }
    }
}

How can Spring Boot be configured to only allow HTTPS connections while at the same time not fall into a redirect loop using the Swisscom Application Cloud?

ssc-hrep3
  • 15,024
  • 7
  • 48
  • 87

1 Answers1

4

As part of the migration to multi-cloud there was a major change in the used IP ranges.

Due to this the tomcat buildpack has issues with redirection as these IPs are not trusted. We fixed this in the latest version of the system buildpack.

Please restage your application to make apply those changes. Further information can be found in our docs: https://docs.developer.swisscom.com/devguide-sc/buildpacks/java/caveats.html

Update:

Unfortunately, if you're using Spring boot with an embedded Tomcat, our buildpack can not do this configuration for you. You have to configure the internal proxies whitelist in your app config. Please see the instructions in the docs above.

Update 28th Nov: We've updated the config in our buildpacks for the new ranges that CF now uses with Envoy. If you use your own buildpack, please update the ranges.

As described in: https://docs.spring.io/spring-boot/docs/current/reference/html/howto-embedded-servlet-containers.html#howto-customize-tomcat-behind-a-proxy-server

We'll update the documentation right away.

Matthias Winzeler
  • 941
  • 5
  • 5
  • Unfortunately, this does not work. I've redeployed the application, then restaged it with the same result: Each page times out because of too many redirects. I then added this env variable to the Env section in the Swisscom portal: Still no luck. – ssc-hrep3 Feb 23 '18 at 13:19
  • @ssc-hrep3 Try to add "server.tomcat.protocol-header: X-Forwarded-Proto" as well. – Romain F. Feb 26 '18 at 08:59
  • @ssc-hrep3 in the application.yml configuration, you only have to use simple \ characters for regex special instructions. Replace all \\ by single \ in Matthias answer and it should be ok... – Romain F. Feb 26 '18 at 09:40
  • Your solution works. However, I'm still sceptical: Configuring internal IPs of the cloud provider into our application does not seem like a proper solution. What if the IP range changes? How do I get informed about that? Or will the application just be offline again? - Is this the way to go from now on or will this issue get fixed with a better solution? @MatthiasWinzeler – ssc-hrep3 Mar 06 '18 at 17:48
  • 1
    @ssc-hrep3 I completely agree with you, it is not a nice solution. That's why we tried hard to give this fix upstream, both in Tomcat as well as in java-buildpack. For the tomcat use case, we found a solution for users that works out of the box, for spring boot however, we have to live with it. With the whole 100.64/10 range covered (which is standard within Swisscom's cloud), we're pretty confident that it won't break in the future. Keep an eye on the newsletter and status page to receive news about possible breaking changes, even if we try to keep them minimal. – Matthias Winzeler Mar 07 '18 at 20:03
  • @MatthiasWinzeler Today we had the same outage again. It started this morning at ~1 am. Any news about this? – ssc-hrep3 Nov 27 '18 at 10:28
  • 1
    @ssc-hrep3: We're afraid with the latest update, the internal ranges changed again - you have to update your config to also include the 11.x ranges, as documented in our documentation. We're sorry to not have communicated this possibly breaking change proactively and will do better in the future. – Matthias Winzeler Nov 28 '18 at 19:22
  • Yes, it would be best to communicate this beforehand, so we can react on time and do not have to deploy a hotfix release during a productive server downtime. But thanks anyway for your reply! – ssc-hrep3 Nov 28 '18 at 19:30
  • Completely agree, there's no excuse for breaking our user's apps! – Matthias Winzeler Nov 29 '18 at 20:12