Detailed error statuses

[azmeuk]

I met a professional situation where several team from several companies were responsible for several pieces of software intended to work together: a client app implemented by a company A gets a token from an identity server administrated by a company B, and pass it to another client app implemented from a company C and deployed from a company D (I am not kidding, this was today).

The software developed by the company C (my company) uses flask-pyoidc, and this bunch of people struggled to debug the full flow. Is our problem due to a bug in software A? In software C? Due to a misconfiguration from the identity server? Due to a misconfiguration of the software C?

In the end we solved our problem (an issue with audience and token introspection endpoint authentication method) but we thought our life would had been easier if flask-pyoidc provided more debug logs.

The token_decorator method uses flask.abort to raise some 401 and 403 errors. I would love to be able to catch those errors and return a JSON message with details about the error causes (token missing, token expired, bad audience, bad scope).

I can think of several ways to achieve this, I am not sure which one is better:

• make flask-pyoidc raise custom exceptions instead of simple aborts (for example TokenExpiredException), in the client app implement custom flask errorhandlers and provide the desired debug message
• make flask-pyoidc pass arguments to abort (for example flask.abort(403, error="The token has expired"), in the client app implement a generic flask errorhandlers that would put the error message in a json dict.

I suppose this would not leak security information, but if this is an issue maybe this whole thing could be an option.

What do you think?

[infohash]

make flask-pyoidc pass arguments to abort (for example flask.abort(403, error="The token has expired"), in the client app implement a generic flask errorhandlers that would put the error message in a json dict.

I agree.

make flask-pyoidc raise custom exceptions instead of simple aborts (for example TokenExpiredException), in the client app implement custom flask errorhandlers and provide the desired debug message

flask.abort raises HTTPException and the auth decorators raise it on behalf of the view function, I don't think abort can be replaced with custom exception. errorhandler can take care of abort messages.

Thanks for looking for improvements.

[azmeuk]

flask-wtforms does raise custom CSRFError exceptions inheriting from HTTPException, that can be catched with @app.errorhandler(CSRFError) for instance. But in the end this is mostly a design choice, and both options would be fine to me.