Redirect to 8443 if using SSL on the 8080 port

[dtitov]

Summary

I came here from this issue: spring-projects/spring-boot#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...

[rwinch]

This is expected Please see spring-projects/spring-boot#6140 (comment)

[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.

[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()
		//...
		;
}

[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...

[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.

[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

[mkpaz]

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

[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.

[wilkinsona]

I had a chat with @rwinch about this and he's opened #15971 to consider making a change in 7.0