blocks|key|82762|text|从技术上讲，并没有添加dispatch()方法，它只是覆盖了webapp2.RequestHandler已经提供的方法，并对其进行了扩展以添加会话支持。如果您仔细查看该方法，您会发现它仍然调用原始方法来执行实际调度：|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|82763|++++++++#+Dispatch+the+request.
++++++++webapp2.RequestHandler.dispatch(self)|code-block|syntax|javascript|82764|如果你愿意，它可以被重写为：|82765|++++++++super(BaseHandler,+self).dispatch()|82766|扩展dispatch()所做的全部工作就是从存储中提取会话信息，使其在分派请求之前可供处理程序代码使用(+BTW包括请求处理)，并在请求处理完成后(当对会话信息的更改可能已经完成时)将其保存回去。对于每个请求！这只是一种跨请求持久化信息的方式。|82767|会话支持很简单-支持-你的应用程序仍然负责控制在webapp2的会话字典中存储哪些信息，何时添加/修改/删除这些信息，以及如何使用这些信息。|82768|换句话说，webapp2本身不知道什么是登录/注销/用户会话等(所以不，您在#1、#2和#3中提到的任何事情都不会发生在webapp2本身中)。您的应用程序的职责是：|82769|82770|当会话字典中的信息代表“当前用户会话”时，在会话字典中设置/删除代表“用户会话”(无论这对你的应用程序意味着什么)的信息-通常是在用户登录/注销请求处理程序中，在处理登录和注销请求之间的传入请求时按其认为合适的方式删除该信息。|unordered-list-item|82771|82772|为了存储会话信息，webapp2支持cookie(默认)、memcache和datastore+(ndb)。从会话：|82773|82774|它有三个内置的后端:安全cookie，内存缓存和数据存储。可以添加新的后端来扩展CustomBackendSessionFactory。|blockquote|82775|82776|会话存储可以通过SessionStore.get_session()方法提供使用不同密钥的多个会话，甚至可以在同一请求中使用不同的后端。默认情况下，它使用configuration.中的默认密钥返回一个会话|82777|entityMap|0|LINK|mutability|MUTABLE|url|https://webapp2.readthedocs.io/en/latest/api/webapp2_extras/appengine/sessions_memcache.html|1|https://webapp2.readthedocs.io/en/latest/api/webapp2_extras/appengine/sessions_ndb.html|2|https://webapp2.readthedocs.io/en/latest/api/webapp2_extras/sessions.html#webapp2_extras.sessions.CustomBackendSessionFactory|3|https://webapp2.readthedocs.io/en/latest/api/webapp2_extras/sessions.html#webapp2_extras.sessions.SessionStore.get_session^0|B|A|U|M|0|0|0|0|2|A|0|O|7|0|5|7|1O|7|0|0|0|0|9|7|T|8|0|12|F|1|0|0|14|R|2|0|0|8|Q|3|0^^$0|@$1|2|3|4|5|6|7|1M|8|@$9|1N|A|1O|B|C]|$9|1P|A|1Q|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|1R|8|@]|D|@]|E|$I|J]]|$1|K|3|L|5|6|7|1S|8|@]|D|@]|E|$]]|$1|M|3|N|5|H|7|1T|8|@]|D|@]|E|$I|J]]|$1|O|3|P|5|6|7|1U|8|@$9|1V|A|1W|B|C]]|D|@]|E|$]]|$1|Q|3|R|5|6|7|1X|8|@$9|1Y|A|1Z|B|C]]|D|@]|E|$]]|$1|S|3|T|5|6|7|20|8|@$9|21|A|22|B|C]|$9|23|A|24|B|C]]|D|@]|E|$]]|$1|U|3|-4|5|6|7|25|8|@]|D|@]|E|$]]|$1|V|3|W|5|X|7|26|8|@]|D|@]|E|$]]|$1|Y|3|-4|5|6|7|27|8|@]|D|@]|E|$]]|$1|Z|3|10|5|6|7|28|8|@$9|29|A|2A|B|C]]|D|@$9|2B|A|2C|1|2D]|$9|2E|A|2F|1|2G]]|E|$]]|$1|11|3|-4|5|6|7|2H|8|@]|D|@]|E|$]]|$1|12|3|13|5|14|7|2I|8|@]|D|@$9|2J|A|2K|1|2L]]|E|$]]|$1|15|3|-4|5|6|7|2M|8|@]|D|@]|E|$]]|$1|16|3|17|5|6|7|2N|8|@]|D|@$9|2O|A|2P|1|2Q]]|E|$]]|$1|18|3|-4|5|6|7|2R|8|@]|D|@]|E|$]]]|19|$1A|$5|1B|1C|1D|E|$1E|1F]]|1G|$5|1B|1C|1D|E|$1E|1H]]|1I|$5|1B|1C|1D|E|$1E|1J]]|1K|$5|1B|1C|1D|E|$1E|1L]]]]

Technically the <code>dispatch()</code> method is not added, it's just overwriting the one that <code>webapp2.RequestHandler</code> already provides, extending it to add session support. If you take a closer look at that method you see that it still calls the original one to do the actual dispatching:

<pre><code> # Dispatch the request.
 webapp2.RequestHandler.dispatch(self)
</code></pre>

Which could be re-written, if you want, as:

<pre><code> super(BaseHandler, self).dispatch()
</code></pre>

All that the extended <code>dispatch()</code> does is picking up the session info from the store making it available to the handler code before dispatching the request (which BTW includes the request processing) and saving it back afterwards, when the request processing completes (when changes to the session info may have been done). For every request! Simply a way to persist info across requests.

The session support is simply that - support - your app is still the one responsible for controlling what info is stored in the <code>webapp2</code>'s session dictionary, when is that info added/modified/deleted and how is that info used.

In other words <code>webapp2</code> itself has no clue what's login/logout/user session, etc (So no, nothing that you mention in #1, #2 and #3 happens in <code>webapp2</code> itself). It is your app's responsibility to:

<ul>
<li>set/delete inside the session dictionary the info that represents your "user session" (whatever that means for your app) - typically in the user login/logout request handlers, respectively</li>
<li>use that info as it sees fit while handling incoming requests between the login and the logout one - when the info from the session dictionary represents the "current user session".</li>
</ul>

For storing the session info <code>webapp2</code> supports cookies (default), <a href="https://webapp2.readthedocs.io/en/latest/api/webapp2_extras/appengine/sessions_memcache.html" rel="nofollow noreferrer">memcache</a> and <a href="https://webapp2.readthedocs.io/en/latest/api/webapp2_extras/appengine/sessions_ndb.html" rel="nofollow noreferrer">datastore (ndb)</a>. From Sessions:

<blockquote>
 It has three built-in backends: secure cookies, memcache and
 datastore. New backends can be added extending
 <a href="https://webapp2.readthedocs.io/en/latest/api/webapp2_extras/sessions.html#webapp2_extras.sessions.CustomBackendSessionFactory" rel="nofollow noreferrer">CustomBackendSessionFactory</a>.
 
 The session store can provide multiple sessions using different keys,
 even using different backends in the same request, through the method
 <a href="https://webapp2.readthedocs.io/en/latest/api/webapp2_extras/sessions.html#webapp2_extras.sessions.SessionStore.get_session" rel="nofollow noreferrer">SessionStore.get_session()</a>. By default it returns a session using
 the default key from configuration.
</blockquote>

I wish to implement sessions in webapp2. From research, I have found <a href="https://stackoverflow.com/questions/14078054/gae-webapp2-session-the-correct-process-of-creating-and-checking-sessions">this code sample</a> using <code>webapp2_extra.sessions</code>, and a few articles which mentions deprecated or unmaintained session libraries. 

I currently lack the knowledge of how sessions work conceptually. This is what I understand so far:

<ol>
<li>We can include a <code>dispatch()</code> method to a request handler which allows us to create/update a session object; it is during the login phase of the app, the session is created. (Question: how is session stored? In the app's memory or in datastore?) </li>
<li>When a user makes a request to the app, the dispatch() method checks to see if an existing session exists for the user. (Question: How exactly does this validation work? Is there a token inside the request.body or cookie that sessions look for?) </li>
<li>When a user logs out, the session is deleted.</li>
</ol>

Is my understanding correct? Or perhaps I am missing something important? There seems to be little guidance on this subject on the internet. Thank you for the assistance.

webapp2 Sessions: How do sessions work conceptually?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我希望在webapp2中实现会话。通过研究，我发现了使用webapp2_extra.sessions的，还有一些文章提到了不推荐使用或未维护的会话库。我目前缺乏会话是如何从概念上工作的知识。到目前为止，我的理解是：(问题：会话是如何存储的？在应用程序的内存中还是在数据存储中？)当用户向应用程序发出请求时，dispatc...

webapp2会话:会话在概念上是如何工作的？-腾讯云开发者社区-腾讯云

问webapp2会话:会话在概念上是如何工作的？
EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问webapp2会话:会话在概念上是如何工作的？EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问webapp2会话:会话在概念上是如何工作的？
EN