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

    Details

    • Type: Sub-task Sub-task
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Deferred
    • Affects Version/s: 2.1.1
    • Fix Version/s: DEV backlog
    • 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
    • Rank:
      19053

      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.

        Issue Links

          Activity

          Hide
          Jérôme Mouneyrac added a comment -

          finally I'm not sure about it. It's kind of useful information for clients. As nobody raise any opinion about it, I'm going to close it.

          Show
          Jérôme Mouneyrac added a comment - finally I'm not sure about it. It's kind of useful information for clients. As nobody raise any opinion about it, I'm going to close it.

            People

            • Assignee:
              Jérôme Mouneyrac
              Reporter:
              Jérôme Mouneyrac
              Participants:
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: