2

I wish to implement sessions in webapp2. From research, I have found this code sample using webapp2_extra.sessions, 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:

  1. We can include a dispatch() 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?)
  2. 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?)
  3. When a user logs out, the session is deleted.

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.

puoygae
  • 573
  • 7
  • 19

1 Answers1

3

Technically the dispatch() method is not added, it's just overwriting the one that webapp2.RequestHandler 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:

        # Dispatch the request.
        webapp2.RequestHandler.dispatch(self)

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

        super(BaseHandler, self).dispatch()

All that the extended dispatch() 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 webapp2's session dictionary, when is that info added/modified/deleted and how is that info used.

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

  • 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
  • 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".

For storing the session info webapp2 supports cookies (default), memcache and datastore (ndb). From Sessions:

It has three built-in backends: secure cookies, memcache and datastore. New backends can be added extending CustomBackendSessionFactory.

The session store can provide multiple sessions using different keys, even using different backends in the same request, through the method SessionStore.get_session(). By default it returns a session using the default key from configuration.

Dan Cornilescu
  • 39,470
  • 12
  • 57
  • 97
  • Thank you @Dan. Would you recommend any further resource/guide/tutorial where one might learn the 'recipe' of rolling out a session system using the tools you have mentioned? It seems like webapp2 is saying "here are the tools you need, you know what do to". It is assuming us (me at least) to already have an established knowledge of how it all comes together. – puoygae Sep 13 '18 at 02:43
  • I found sufficient (for my use) the webapp2 ones: https://webapp2.readthedocs.io/en/latest/index.html#tutorials – Dan Cornilescu Sep 13 '18 at 09:12