Uploaded image for project: 'Moodle'
  1. Moodle
  2. MDL-29276 META- Web service improvements for 2.2
  3. MDL-29498

Obfuscate all exception messages from token.php + return some debug info

    XMLWordPrintable

    Details

    • Type: Sub-task
    • Status: Closed
    • Priority: Minor
    • Resolution: Deferred
    • Affects Version/s: 2.1.1
    • Fix Version/s: None
    • Component/s: Authentication
    • Labels:
    • Testing Instructions:
      Hide

      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 occurs

      Show
      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 occurs
    • Affected Branches:
      MOODLE_21_STABLE

      Description

      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.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              jerome Jérôme Mouneyrac
              Reporter:
              jerome Jérôme Mouneyrac
              Participants:
              Component watchers:
              Adrian Greeve, Jake Dallimore, Mathew May, Mihail Geshoski, Peter Dias
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: