I agree with you - checking if a user is logged in, authorization, validating the request, choosing the right view to handle the response (html, json, csv, redirection if you just did a POST and so on), these all belong in a controller action. The framework can be smart about it, relying on conventions and all that, but if there's one thing I've learned is that the rules are meant to be broken and I never met a project that fit perfectly in the sweat-spot of any framework (which is why I do not think middleware cuts it for specific scenarios).
To me the rules are pretty clear:
* data-processing stuff belongs in models
* business-logic belongs in *business models*,
if said logic is related to the UI (i.e. repeat-password),
although for simplicity you can choose not to bother
* request processing (authorization, choosing the models,
choosing the view) belongs in a controller action
* response processing belongs in a view
Regarding view forwarding, I once had a request that based on a parameter, instead of rendering HTML it would forward to a view that sent an email to the user with a CSV file attached, then redirected to a notification message. But only if the user was properly authorized. So the controller's logic was getting reused, forwarding to multiple views depending on expected output. Now that's a real controller and a real view.
To me the rules are pretty clear:
Regarding view forwarding, I once had a request that based on a parameter, instead of rendering HTML it would forward to a view that sent an email to the user with a CSV file attached, then redirected to a notification message. But only if the user was properly authorized. So the controller's logic was getting reused, forwarding to multiple views depending on expected output. Now that's a real controller and a real view.