Affects Version/s: 2.1.1
Fix Version/s: DEV backlog
Make YOURMOODLE/login/token.php?username=USERNAME&password=PASSWORD&service=moodle_mobile_app fail to see if you don't receive too much information when an error occursShowMake YOURMOODLE/login/token.php?username=USERNAME&password=PASSWORD&service=moodle_mobile_app fail to see if you don't receive too much information when an error occurs
Three points I'd like to discuss:
- Currently /login/token.php returns plenty of different exception messages (YOURMOODLE/login/token.php?username=USERNAME&password=PASSWORD&service=moodle_mobile_app). I think there are two kind of generic exceptions that could be created and returned to give a clue to the end user:
1- one related to the authentication ('noguest', 'usernotconfirmed', 'passwordisexpired', 'restoredaccountresetpassword', 'usernamenotfound') => it's an issue that the user can resolved - so actually we could even consider to throw it clearly to the client.
2- one related to the web service configuration ('enablewsdescription', 'cannotcreatemobiletoken', 'invalidtoken') => it's an issue that only the admin can resolve. We should not bother the client with it. Information return in $debuginfo could be useful for debugging.
- All the current exception messages should go into some debug info. This token.php script can be called by any clients, not only the "My moodle" app. That was the point of having a 'service' parameter, so third party plugins can call it for different services. imo $debuginfo would be useful to these thirdparty clients.
- Also Moodle core functions could throw different exceptions than the one raised by token.php. They are currently displayed to the client. It's a similar issue.
I didn't go further that understanding the define('AJAX_SCRIPT', true); transforms the thrown exceptions into JSON code. Maybe in this "transformation" could be the solution to handle core exceptions.