Description

Source: https://twitter.com/matthiasnoback/status/1503652556186206211 by @matthiasnoback

I think it's interesting to see if and how we can reduce the magic (i.e. remove it or make it more obvious by providing helper classes/methods?)

• As a developer you wouldn't expect to have to deal with expressions. It's easy to get a disconnect between the actual controllers, their routing paths, and the regular expressions in the firewall. It's also very easy to break things: when you change a routing path, you can accidentally move a controller outside the firewall, making it unprotected or broken because it relies on a logged in user to be available. Instead, you'd expect to be able to mark controllers, not request URI patterns to be behind a firewall. That way, if you change the routing path, the controller still remains behind the controller.
• The template gets access to the authentication exception itself and the docs say, don't show getMessage(), use getMessageKey(). It would be better to pass some other type of object to the template/controller; one that only has the getMessageKey() method.
• Other aspects you wouldn't expect are a login controller that only shows the login form (login happens in a kernel event subscriber), and a logout controller that doesn't do anything.

Example

No response