4 ms·
Disabled accounts should be checked in the model. But instead of returning a boolean, it could throw appropriate exceptions (WrongPasswordException, AccountDisa
by bergie 15y ago
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 15y agoThis 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 15y agoReally? Throwing exceptions on known states of your model... hardly exceptional.
- glenjamin 15y agoHow 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 15y agoThat'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 15y agoI 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 15y agoAgreed, 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.