Many of those real-life scenario assertions can be implemented as before/after/around filters, since they apply to many routes.

In Rails, :except and :only are super useful on filters.

Also, another possibility is to noun-ify some verbs. (Some may prefer to call it resource-ification, or REST-ification)

For example, you could create a PasswordResetRequest model, which handles all of the logic for checking the old password, the password confirmation, the new password's complexity, etc. Then it would be responsible for executing the actual password change as well.

As a bonus, noun-ification enables easy logging because you'll already have a data structure to store.

Usually with Node.js/Express we handle stuff like authentication on middleware, so controllers don't need to bother. The route just includes the authentication/authorization middleware if one is needed.

Here is a simple example for hooking in route-specific middlewares: https://gist.github.com/978411#file_express_middlewares.coff...

Disabled accounts should be checked in the model. But instead of returning a boolean, it could throw appropriate exceptions (WrongPasswordException, AccountDisabledException) that you can then handle in the controller.

This would be my preferred approach, you can even just key translations based on the name of the exception, then handle them all with a generic flash message / template.

Really? Throwing exceptions on known states of your model... hardly exceptional.

How else would you achieve it - throwing exceptions for program flow is quite common in Python for example; Iterator.next() throws StopIteration when it reaches the end of the iterable.

That's an exceptional circumstance, the iterator is not responsible for knowing whether you have reached the end of the collection.

You could achieve it by catering for these cases in your logic if user.authorize(email, pass): ... success ... else: ... fail ...

rather than try: user.authorize(email, pass) ... success ... except WrongPasswordException: ... fail ...

I see your point, I didn't notice that the parent mentioned WrongPasswordException, when I implemented something similar previously it looked like this:

User.authorize(username, password) -> Returns true if valid username/password -> Returns false if username/password do not match -> Raises AccountDisabled if username/password valid but account disabled

The normal login failure case is not exceptional - but the others are.

Agreed, that is a better scenario.

Then again, stuff like authentication and authorization (two separate concepts!) are often better handled on some middleware or service layer than in models and controllers.