Webapp2安全

Question

我正在编写一个运行在Google上的REST应用程序，它使用webapp2_extras.auth和webapp2_extras.security提供的cookie来验证对特权数据的API请求。

整个站点和所有点都使用HTTPS。

Webapp2运行在一个“请求上下文”中，我认为这意味着每个请求都有自己的线程，但是我想知道一些可能非常特定于代码的东西，即使我深入到代码中去理解，我也不确定我是否能够消除所有的恐惧，因此我在这里问。

情况是:我将http补丁请求配置为“批处理”请求，以放置、获取和删除方法，以保存客户机-服务器往返。如果客户端有很多对象要保存到服务器，它可以使用jsonified的"sub“请求创建一个补丁

/user/dame_edna/objects

修补程序将迭代该列表，然后向不同的点发出应用程序内的请求，例如，一个请求可能是：

method:delete point:/decorative_fans/small_dog_design

补丁方法将构造一个webapp2.Request对象，该对象指向

/user/dame_edna/objects/decorative_fans/small_dog_design

它将填充各种字段(但是，对于这个问题至关重要的是，不是cookie或auth字段)，然后它将实例化请求处理程序，在本例中，

user.objects.decorative_fans.crud.responder

并在应用程序中执行该请求，而不需要客户机-服务器往返。

这里是我迷路的地方，也是我发现有趣的地方：

新请求的cookie字段为空，但请求不知何故知道原始请求的auth令牌和会话。注意，最初的补丁请求来到了/user/dame_edna，为了在这里提出补丁请求，我们需要有一个为用户"dame_edna“进行身份验证的会话，但我关心的是--我在应用程序中发出的子请求如何知道它们被验证为"dame_edna”呢？

但他们有。我为DELETE请求转储了auth令牌，它显示为相同的auth令牌，例如，将dame_edna身份验证为原始修补程序请求，即使我没有以任何方式复制或设置它。

我觉得奇怪的是，webapp2会复制这些身份验证基础，或者它们只会被新创建的请求对象访问，因为像我一样在应用程序中创建请求是，根据文档，主要用于单元测试。

在我继续使用这个应用程序之前，我想澄清对此的任何疑问，因为这是一个非常关键的领域，我不想把它搞砸，而且我不能忽视它而不知道到底发生了什么。

感谢您解释应用程序中的子请求如何知道原始的状态，以及以这种方式使用子请求是否像webapp2_extras提供的原始签名会话一样具有“防弹性”。

Answer 1

脑海中浮现的一些东西。

tcp会话( HTTP请求的基础)由IP:sourceport标识为IP:destinationport，并被视为“会话”。HTTP请求没有什么不同，并且基于这些参数与会话相同。

如果您指示要尝试保存客户端服务器往返，则这是一个真正的语句。只要客户端不发送TCP或TCP，则IP:port对的会话标识符将继续被重用。或者，直到连接超时，服务器发送回TCP。只有这样，会话处理才会被更新。

最重要的是，应用服务器和框架也可以保持自己的会话状态。

因此，基本上，只要不重置连接，tcp、http和更高的会话状态就会保持不变。它(高度)取决于您的具体设置和配置到位。

您应该编写一些代码来验证实际发生的情况。