и журнал ошибок приложения отсутствует, что указывает на то, что на этот раз запрос не поступил в код обработчика, как ожидалось:

отал над некоторыми проверками безопасности для моего стандартного приложения env python GAE, и я был удивлен, увидев, чтоlogin: admin опция кажется неэффективной.

Я хочу защитить часть пространства имен запросов только для самого приложения, а не для внешних запросов. Приложение отправляет эти запросы через очередь задач.

Это соответствующая конфигурация обработчика, которую я проверил в StackDriver как фактический код, который обработал конкретный запрос:

- url: /ci/ci_msg*  # external requests OK
  script: apartci.app
  secure: always

- url: /ci/.*       # internal requests only
  script: apartci.app
  secure: always
  login: admin

Это код обработчика, взломанный для регистрации ошибки, чтобы проверить, действительно ли запрос попадает в код приложения, также проверенный в StackDriver как действительный код обработки:

def post(self):
    logging.error('in post')
    self.handle_post()

Я отправил внешний запрос по тому же пути, по которому должны приниматься только запросы внутренней очереди задач, используя дополнение Firefox HttpRequester. Тело запроса не прошло дополнительные проверки вself.handle_post(), но это не имеет отношения к этому вопросу.

Ответ, который я получил в HttpRequester (также довольно нерелевантный):

<html>
 <head>
  <title>203 Non-Authoritative Information</title>
 </head>
 <body>
  <h1>203 Non-Authoritative Information</h1>
  <br /><br />
 </body>
</html>

Я проверил журналы приложений в StackDriver. К моему удивлению я нашелlogging.error('in post') Журнал приложения от моего обработчикаpost() метод, прикрепленный к журналу запросов, указывающий, что запрос поступил в мое приложение:

Для сравнения - журнал того же запроса, отправленного самим приложением (по совпадению всего за ~ 1 секунду до внешнего и обработанный точно таким же экземпляром - что привело меня в замешательство):

Я ожидал, что внешний запрос не попадет в код обработчика, согласно строке входа вЭлемент обработчиков:

админ

Как стребуетсявыполняетauth_fail_action если пользователь не вошел в систему. Кроме того, если пользователь не является администратором приложения, ему выдается сообщение об ошибке независимо от того,auth_fail_action установка. Если пользователь является администратором, обработчик продолжается.

Когда обработчик URL савторизоваться установка кромепо желанию соответствует URL, обработчик сначала проверяет, вошел ли пользователь в приложение, используя егоопция аутентификации, Если нет, по умолчанию пользователь перенаправляется на страницу входа. Вы также можете использоватьauth_fail_action настроить приложение так, чтобы оно просто отклоняло запросы на обработчик от пользователей, которые не прошли надлежащую аутентификацию, вместо перенаправления пользователя на страницу входа.

Обратите вниманиеадмин ограничение входа также выполняется для внутренних запросов, для которых App Engine устанавливает соответствующиеX-Appengine специальные заголовки. Например,хрон запланированные задачи удовлетворяютадмин ограничение, потому что App Engine устанавливает заголовок HTTPX-AppEngine-Cron: правда по соответствующим запросам. Тем не менее, запросы будутне удовлетворитьтребуется ограничение входа в систему, потому что запланированные задачи cron не запускаются от имени любого пользователя.

Итак, мой вопрос: почему / как внешний запрос смог попасть в код обработчика? Я что-то пропустил?

Ответы на вопрос(1)

Ваш ответ на вопрос