2012/7/13 Ángel González <keis...@gmail.com>: > The codebase does no global exception handling (because it doesn't throw > exceptions itself), > and also nobody configured the server not to show errors/exceptions > (some say it was > purposely setup to show them). > password_verify() "errors" if the parameters are not strings or the hash > doesn't match a > known hash format. > Which kind of error should you use? errors or exceptions? Provide a > reasoned answer.
Exceptions and a blank page/empty body for the user should be the default. Because: Think of it like a printer: If the printer has an error, it will not continue to work, to avoid any break. The user needs to open all paper trays, look into them and remove eventually the paper before the printer can continue. For a login it's the same kind of logic: If you don't know what happened you need to look into any "tray". If you implement more sensors (better exception handling), you may continue without looking. In detail: - Normally the code has no error here. No real need for fetching exceptions. - So, if there is an error, you don't know why (because you didn't fetch). - Even if I know there was an error (password_hash() returns false): I can not continue with any action, because I don't know why. - If you don't know the reason of an error, it is in this case an error to continue, - which will be done automatically, if you don't fetch. Perfect. - And to make it not obvious for a hacker to get sufficient informations about the type of exception, it is the most secure way to display no information to a possible invader. I know this will break current behaviour completly. But it's the most secure way to do. And security is the reason of this discussion. To implement this we need for example a special type of exception (e. g. "interface non_displayable"), which will remove the error-messages. -- Alex -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
