BadRequestKeyError no longer contains the missing key from self.form as of 1.0.3

[Roguelazer]

Expected Behavior

When self.form is indexed with a key that isn't present, BadRequestKeyError is raised. Under 1.0.2 and below, the .args property of this exception contained the actual missing key -- great for lightweight error presentation.

Minimal demonstration:

from flask import Flask, jsonify, request
from werkzeug.exceptions import BadRequestKeyError

app = Flask('test')

@app.errorhandler(BadRequestKeyError)
def bad_key(e):
    return jsonify({'missing key(s)': e.args})


@app.route('/')
def root():
    return request.form['foo']

app.run()

Under 1.0.2 and below we see the following behavior:

 % curl localhost:5000
{"missing key(s)":["foo"]}

Under 1.0.3:

% curl localhost:5000
{"missing key(s)":[]}

This occurs independent of $FLASK_DEBUG

Actual Behavior

There appears to be no way to get at the missing key from an error handler.

Environment

• Python version: 3.6.6
• Flask version: 1.0.3
• Werkzeug version: 0.15.4

[davidism]

I can't reproduce the issue when in debug mode, e.args[0] is the key. Out of debug mode, this now fails because we clear the args, since in Werkzeug 0.15 that's what triggers hiding the key, and I didn't think it was good to show the keys and non-standard error messages outside debug mode.

Then again, this "only show the key in debug mode" is a completely made up thing I decided when adding the key to the output, it wasn't ever shown before Flask 1.0. I can just have it show all the time and never remove it?

[Roguelazer]

I don't understand why behavior in a custom errorhandler should ever depend on debug mode...? I agree it's reasonable to hide the keys in the default error response in non-debug mode, but if I'm doing my own error handling (and, say, logging details about the missing key), I should have access to the full args. Also, this behavior is with werkzeug 0.15 both on flask 1.0.2 and 1.0.3... Is there any way to monkey patch around this without enabling debug mode in production? For now I have to pin 1.0.2 in several dozen projects... -- James Brown, currently mobile

…

On Jun 3, 2019, at 10:15, David Lord ***@***.***> wrote: I can't reproduce the issue when in debug mode, e.args[0] is the key. Out of debug mode, this now fails because we clear the args, since in Werkzeug 0.15 that's what triggers hiding the key, and I didn't think it was good to show the keys and non-standard error messages outside debug mode. Then again, this "only show the key in debug mode" is a completely made up thing I decided when adding the key to the output, it wasn't ever shown before Flask 1.0. I can just have it show all the time and never remove it? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[davidism]

It doesn't exactly depend on debug mode, losing the key outside debug mode is an unintended side-effect of the new implementation of the key showing/hiding in Werkzeug 0.15, which gained support in Flask 1.0.

You should set TRAP_BAD_REQUEST_ERRORS = True in your config, since trapping the BadRequestKeyError to handle yourself is what you want. I've confirmed you get the behavior you want in that case.

[Roguelazer]

I can confirm that setting TRAP_BAD_REQUEST_ERRORS to True in config fixes this.

I still am kind of negative on the idea of emptying out .args by default in non-debug mode, but at least there's a workaround...

[davidism]

If you have a suggestion for a better way to only output the information in Flask's debug mode, when the feature itself is part of Werkzeug, I'm open to review a PR to Werkzeug!

[Roguelazer]

Is e.args actually auto-dumped? Would it be sufficient to remove it from e.description but just leave e.args alone?