-
Notifications
You must be signed in to change notification settings - Fork 145
Description
If the Flask middleware is configured after another extension, and that extension throws an exception in a before_request method, the Flask middleware throws an exception in its after_request method.
File "/home/sam/.pyenv/versions/3.9.7/envs/flask-test-2-3.9.7/lib/python3.9/site-packages/flask/app.py", line 1508, in finalize_request
response = self.process_response(response)
File "/home/sam/.pyenv/versions/3.9.7/envs/flask-test-2-3.9.7/lib/python3.9/site-packages/flask/app.py", line 2002, in process_response
response = self.ensure_sync(func)(response)
File "/home/sam/.pyenv/versions/3.9.7/envs/flask-test-2-3.9.7/lib/python3.9/site-packages/aws_xray_sdk/ext/flask/middleware.py", line 74, in _after_request
segment.put_http_meta(http.STATUS, response.status_code)
AttributeError: 'NoneType' object has no attribute 'put_http_meta'
cannot find the current segment/subsegment, please make sure you have a segment open
This does not happen if the Flask middleware is configured before other extensions.
The root cause appears to be that when an extension throws an exception in a before_request method, processing of subsequent before request methods is suppressed, but after_request methods are still executed.
I think there's two things needed to do to resolve this:
- Make it clear in https://docs.aws.amazon.com/xray-sdk-for-python/latest/reference/frameworks.html#flask that Flask should be the first extension configured.
- In the after_request handler, handle the current segment or subsegment being None without raising an exception.
Note that even if the after_request handler doesn't raise an exception, having other middleware prevent the Flask middleware's before_request method from executing is a problem, because it means that you will not get X-Ray traces when this happens. I suggest that the after_request handler should log a warning or error explaining the problem if the current segment or subsegment is None.
I've attached a reproduction. This relies on the fact that Flask-WTF throws an exception to indicate a bad request when a CSRF token is missing from a request that requires one. To reproduce the bug:
- Unzip the zip to a directory.
- Install the requirements using pip install -r requirements.txt.
- In one shell, build and run the local X-Ray agent using
docker build -t xray-daemon . && docker run --rm --attach STDOUT -v ~/.aws/:/root/.aws/:ro --net=host -e AWS_PROFILE=PROFILE_NAME--name xray-daemon -p 2000:2000/udp xray-daemon -owhere PROFILE_NAME is a valid AWS profile that can talk to X-Ray (obviously skip this if you have a better way to get a local X-Ray daemon running). - In another shell, run the Flask application using
gunicorn -b 0.0.0.0:8080 app:app. - In a third shell, make a POST command using
curl -X POST http://localhost:8080/post. - You will see the exception in the Flask application.
You can see that ordering matters by swapping the following two lines in app.py:
csrf = CSRFProtect(app)
XRayMiddleware(app, xray_recorder)
If the XRayMiddleware is initialised first, the request will succeed, and you'll see the Bad Request error that you should (because the request does not have a CSRF token).