Summary

I came here from this issue: https://github.com/spring-projects/spring-boot/issues/6140

I have a problem that is described in comments there: I have configured the web-app to run on 8080 port (basically, the default one), but using SSL. Then, when I plug in Spring Security and try to use OAuth2, it redirects me to 8443 port.

Actual Behavior

The protected endpoint redirects to 8443.

Expected Behavior

The protected endpoint keeps 8080 port.

Configuration

server:
  ssl:
    key-store-type: PKCS12
    key-store: file:${SERVER_KEYSTORE_PATH}
    key-store-password: ${SERVER_CERT_PASSWORD}
  port: 8080

Version

2.2.0.RELEASE

Sample

This is not my code, but one guy from the issue above created a minimal reproducible example for this issue: https://github.com/barrycommins/spring-boot-ssl-redirect-bug

As far as I understand, this issue is somehow related to some IE bug. I wonder if it's still even the case? The issue seems to be quite old (2016 year). It might be that this bug is gone in the recent versions of IE (and there's no point to support the old versions because even Microsoft doesn't support them).

Anyway, I believe that this strange workaround that was made with the PortResolverImpl should be removed, because the attempt to fix some IE bug (basically, some client-originated misbehavior) breaks the normal behavior of the back-end, which looks ridiculous to me...

Comment From: rwinch

This is expected Please see https://github.com/spring-projects/spring-boot/issues/6140#issuecomment-227768583

Comment From: dtitov

@rwinch, sorry, but did you even read my message? I came from that issue and I read all the comments there. I realize that you think (or some other developers) that this is the expected behavior. However, I (and, obviously not only me) disagree. I'm convinced that the backend system shouldn't fix the frontend bug.

Even if you insist, IMHO, there must be provided a workaround (in order to disable your workaround for IE bug) for those people who don't care about IE and want to have their TLS-terminated application working on 8080 port.

Comment From: rwinch

You can configure the PortResolver that is used by the AuthenticationEntryPoint.

@Override
protected void configure(HttpSecurity http) throws Exception {
    PortMapperImpl portMapper = new PortMapperImpl();
    portMapper.setPortMappings(Collections.singletonMap("80","443"));
    PortResolverImpl portResolver = new PortResolverImpl();
    portResolver.setPortMapper(portMapper);
    LoginUrlAuthenticationEntryPoint entryPoint = new LoginUrlAuthenticationEntryPoint(
            "/login");
    entryPoint.setPortMapper(portMapper);
    entryPoint.setPortResolver(portResolver);
    http
        .exceptionHandling()
            .authenticationEntryPoint(entryPoint)
            .and()
        //...
        ;
}

Comment From: dtitov

Thanks, this helped. However, I still think that the necessity to do portMapper.setPortMappings(Collections.singletonMap("8080", "8080")) looks quite weird. But, anyway, it works...

Comment From: theshoeshiner

Does anyone have a recommended workaround for this when using a SAMLEntryPoint? That class has no internal port mapper or resolver, but It appears that the mapper and resolver on the HttpSessionRequestCache are causing the same 8080 -> 8443 issue, and I don't see any way to override those.

It looks like the relevant field is: org.springframework.security.web.access.ExceptionTranslationFilter.requestCache

That cache has an internal port resolver, which would need to be overridden. However I can't figure out exactly where I can control that.

Comment From: sathishkumar294

@theshoeshiner I faced the same issue with the HttpSessionRequestCache using its own portResolver to forward my requests from TLS enabled to 8080 to non-existant 8443. I fixed it for the moment using this code:

HttpSessionRequestCache cache = new HttpSessionRequestCache();
cache.setPortResolver(portResolver);
httpSecurity.setSharedObject(RequestCache.class, cache);

where portResolver was created using the steps given by @rwinch above

Comment From: mkpaz

IE is long dead. I'm surprised this is still an issue.

Comment From: joninous

I came across this behaviour last week when testing some X-Forwarded-* header configurations. I originally thought this was some weird bug in Spring Boot. @wilkinsona pointed me to this issue.

Since I lost some dev time wondering what is going on, I personally would like to see this behaviour changed. As @mkpaz mentioned, I too think that a bug in IE shouldn't be a valid justification anymore.

Comment From: wilkinsona

I had a chat with @rwinch about this and he's opened https://github.com/spring-projects/spring-security/issues/15971 to consider making a change in 7.0