Merge lp:~ev/canonical-identity-provider/error-messages into lp:canonical-identity-provider/release

Proposed by Evan
Status: Work in progress
Proposed branch: lp:~ev/canonical-identity-provider/error-messages
Merge into: lp:canonical-identity-provider/release
Diff against target: 20 lines (+4/-4)
1 file modified
src/api/v20/handlers.py (+4/-4)
To merge this branch: bzr merge lp:~ev/canonical-identity-provider/error-messages
Reviewer Review Type Date Requested Status
Ubuntu One hackers Pending
Review via email: mp+299254@code.launchpad.net

Commit message

Hand error messages up to the response

Description of the change

Pretty straightforward. We were writing helpful little error messages and then throwing them away.

To post a comment you must log in.
Revision history for this message
Thomi Richards (thomir-deactivatedaccount) wrote :

Ev and I discussed this on IRC.

I'm -1 to this approach because it has the potential to leak information that we may not want end users seeing. Programmers raising these exceptions have a somewhat-reasonable expectation that the exception messages won't get seen by end users, but will instead end up in sentry. For that reason, exception messages often contain as much information as possible in order to aid debugging. The risk of exposing private information in this fashion is high.

The actual problem in ev's case was that:

"I was handing it a bound discharge rather than the original discharge for refreshing and in that case it was [raising] AuthenticationError"

As discussed on IRC, a better solution here is to find the code that handles that specific case and raise a different exception (probably derived from AuthenticationError), so we can catch it in the API handler and give the user a more descriptive error message.

The API handler would now look something like:

except AuthenticationBoundMacaroonError:
    return errors.INVALID_CREDENTIALS("You gave us a bound discharge macaroon rather than the original discharge macaroon, you dolt!")

...which neatly solves both problems: give users more specific error message, AND avoid leaking private information.

Revision history for this message
Natalia Bidart (nataliabidart) wrote :

I agree with the outcome of the discussion, and wanted to add that tests were missing, so please consider adding the proper suite for the new approach :-)

Unmerged revisions

1495. By Evan

Actually pass the exception message up to the response.

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
1=== modified file 'src/api/v20/handlers.py'
2--- src/api/v20/handlers.py 2016-06-08 00:55:13 +0000
3+++ src/api/v20/handlers.py 2016-07-06 00:53:40 +0000
4@@ -565,12 +565,12 @@
5
6 try:
7 new_discharge = method(*params)
8- except ValidationError:
9- return errors.INVALID_DATA()
10+ except ValidationError as e:
11+ return errors.INVALID_DATA(message=e.message)
12 except AccountDeactivated:
13 return errors.ACCOUNT_DEACTIVATED()
14- except AuthenticationError:
15- return errors.INVALID_CREDENTIALS()
16+ except AuthenticationError as e:
17+ return errors.INVALID_CREDENTIALS(message=e.message)
18
19 response = rc.ALL_OK
20 response.content = dict(discharge_macaroon=new_discharge.serialize())