2.0 migration Guide should call out implications for /error

[jzheaux]

It isn't obvious when reading the Boot 2.x Migration Guide that one consequence of this:

The security auto-configuration no longer exposes options and uses Spring Security defaults as much as possible.

Is that, where /error was once public, it is now secured.

The Spring Boot Security 2.0 page does help by saying:

When Spring Security is on the classpath, the auto-configuration secures all endpoints by default.

But, it isn't clear to users who are migrating that this includes /error.

This has caused some confusion and heartburn for users that could be somewhat alleviated by calling it out.

Looks like there is already some of this in the guide:

One noticeable side effect of that is the use of Spring Security’s content negotiation for authorization (form login).

It may be valuable to add to the guide a bit of the rationale behind the change. Some users mistakenly believe that when they are proactively securing /error, that it is an icky workaround instead of the desired practice.

Here is some rationale that we could draw from:

• We should be secure by default. It was surprising that even though Spring Security secures every endpoint by default, somehow /error wasn't included in this. Spring Boot 2.0 is now secure by default, too, in that all endpoints, including /error now respect the Spring Security default.
• Also with /error it was the case that Spring Security wasn't invoked at all, meaning that things like secure headers, https redirects, and the like weren't consulted as part of the response.

I think that the nod to simpification already in the docs is a good one, too.

[rwinch]

NOTE: It is probably obvious, but in addition to /error I think it would be beneficial to list other endpoints impacted too.

[mbhave]

I've added a note here about error and static resources.

[rwinch]

Could we add an example of how to do that? We might provide a way to ignore as was done in Boot 1.x but first propose they use permitAll (which is better because it allows access but enables other security features).

[philwebb]

I added a link in that section to the reference docs which has an example.