Menu
I was working on some security checks for my standard env python GAE app and I was surprised to see that the login: admin option appears to be non-effective.
I want to secure a portion of a request namespace to just the app itself, not external requests. The app sends these requests through a push task queue.
This is the respective handler configuration, which I checked in StackDriver to be the actual code that handled the particular request in question:
- url: /ci/ci_msg* # external requests OK
script: apartci.app
secure: always
- url: /ci/.* # internal requests only
script: apartci.app
secure: always
login: admin
This is the handler code, hacked to log an error to check if the request actually hits the app code, also verified in StackDriver to be the actual handling code:
def post(self):
logging.error('in post')
self.handle_post()
I sent the external request to the exact same path that only the internal task queue requests should be accepted, using the Firefox HttpRequester add-on. The request body failed the additional checks in self.handle_post(), but that's irrelevant for this question.
The response I got in HttpRequester (rather irrelevant as well):
<html>
<head>
<title>203 Non-Authoritative Information</title>
</head>
<body>
<h1>203 Non-Authoritative Information</h1>
<br /><br />
</body>
</html>
I checked the app logs in StackDriver. To my surprise I found the logging.error('in post') app log from my handler's post() method attached to the request log, indicating that the request made it to my app:
For comparison - the log from the same request sent from the app itself (coincidentally just ~1 second before the external one and handled by the exact same instance - which contributed to my confusion):
My expectation was for the external request to not make it to the handler code, according to the login row in Handlers element:
admin
As with required, performs auth_fail_action if the user is not signed in. In addition, if the user is not an administrator for the application, they are given an error message regardless of the auth_fail_action setting. If the user is an administrator, the handler proceeds.
When a URL handler with a login setting other than optional matches a URL, the handler first checks whether the user has signed in to the application using its authentication option. If not, by default, the user is redirected to the sign-in page. You can also use auth_fail_action to configure the app to simply reject requests for a handler from users who are not properly authenticated, instead of redirecting the user to the sign-in page.
Note: the admin login restriction is also satisfied for internal requests for which App Engine sets appropriate X-Appengine special headers. For example, cron scheduled tasks satisfy the admin restriction, because App Engine sets an HTTP header X-AppEngine-Cron: true on the respective requests. However, the requests would not satisfy the required login restriction, because cron scheduled tasks are not run as any user.
So my question is why/how did the external request manage to hit the handler code? Am I missing something?
861
Mistery solved: apparently the Firefox HttpRequester add-on is smart enough to automatically pull the google credentials from Firefox and use them. The updated image in the question now has a pointer showing the username info I blacked out but didn't regard as a clue. Those credentials have admin permissions to the GAE app, which explains why that request made it to the handler code.
To confirm this theory I tried the same request but this time sent using curl:
$ curl --request POST --data '{"task": "project_integrity_check_task", "obj_id": 4841240159846400, "ci_proj": 4841240159846400, "obj_cls": "Project"}' [url_redacted]
The response is indeed a 302 and the app error log is missing, indicating that this time the request didn't make it to the handler code, as expected:
75
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
