[bergie]

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.

[glenjamin]

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.

[Volpe]

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

[glenjamin]

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.

[Volpe]

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

[glenjamin]

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.

[bergie]

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.