I am coding a REST web application that runs on Google App Engine, it authenticates API requests to privileged data using sessions by cookies provided by webapp2_extras.auth and webapp2_extras.security.

The entire site and all points use HTTPS.

Webapp2 runs in a "request context" which I believe means each request that comes through has its own thread, but I am wondering something that is probably quite code specific and even if I dug into the code to understand, I'm not sure I would be capable of putting all my fears to rest, hence I am asking here.

The situation is : I rig the http PATCH request to "batch" requests to PUT,GET and DELETE methods to save on client-server roundtrips. If say the client has a lot of objects to save to the server, it can make a PATCH with the jsonified list of "sub" requests to


And the patch will iterate that list and then make in-app requests to the different points, for example one request might be :

method:delete point:/decorative_fans/small_dog_design

And the patch method will construct a webapp2.Request object which points to


It will fill in various fields (but, crucially for this question, not the cookie or auth fields), and then it will instantiate the request handler, in this case,


and execute that request in the application, without a client-server round trip

Here is where I get lost and what I find interesting :

The cookie field of the new request is blank, but the request somehow knows about the auth token and session of the originating request. Notice that the original PATCH request came to /user/dame_edna, and to even make that PATCH request here we needed to have a session that was authenticated for user "dame_edna", but my concern is -- how do the subrequests that I make in the application know that they are verified as "dame_edna" ?

But they do. I dumped the auth token for the DELETE request, and it came up as the same auth token that authenticated, say, dame_edna to the original PATCH request, even though I did not copy or set it in any way

It seems weird to me that webapp2 would copy across these authentication fundamentals, or that they would simply become accessible to the newly created Request object, since creating Requests in-app like I did is, according to the docs, mostly used for unit testing.

I want to clear up any doubts about this before I move forward with the application, since it's a pretty key area I don't want to mess it up, and I can't ignore it without knowing exactly what's going on.

Help is appreciated for an explanation of how the sub, in-app request knows about the original, HTTP requests authent state, and whether using sub-requests in this way is going to be as "bulletproof" as the original signed sessions provided by webapp2_extras

  • I don't understand the question. If, as you say, this additional request is in the application, then what's to stop it accessing global registers of the main (or same?) thread that were filled with the initial request that did include session data in the request headers? I'm not sure what's being asked here. Is it why is any new request object created within the same web application's instance linked with the session data of the original request?. If so, then the answer is probably that you're creating a subsequent request object as the child object of the initial request ( = inheritance).
    – TildalWave
    Apr 21, 2013 at 20:58
  • It's not a childclass of the initial request. It goes back to the webapp2 module and webapp2.Request.blank(path=...) is called. I don't understand how the information comes across, and because it's not clear, I'm worried it might break, or not be secure. Apr 21, 2013 at 21:39
  • The declaration of the Request class starts at the line 114 of webapp2.py. I'm not too familiar with webapp2, or Python for the matter, but the way I read it class method blank creates a new instance of the superclass and fills it's environ with the POST request data (lines 273-285) or empty, if it wasn't created on POST request (data = kwargs.pop('POST', None)...). If that's true, it does seem to be a reason for concern you can leak original request data in a new request. You could create a new class handler tho
    – TildalWave
    Apr 21, 2013 at 22:39
  • Okay, thanks I'll have a closer look at the code and may make some changes to my question. Apr 22, 2013 at 3:25
  • 3
    Could I bother you for a status update on this issue you're presenting? It's been awhile since your last comment and the question still doesn't have a proper answer. If Webapp2 is really written to default to transparent proxying requests, then this is clearly a case for concern, and an answer about it might help someone else, too. Thanks!
    – TildalWave
    Jun 7, 2013 at 22:57

1 Answer 1


Some things which came to mind.

A tcp session ( which is the base for the HTTP requests ) is identified by IP:sourceport to IP:destinationport and considered a 'session'. The HTTP request is no different and identies the sessions based on these parameters.

Given you indicated you try to save client-server roundtrips this is a true statement. As long as the client does not send a TCP-RST or TCP-FIN the session identifier for the IP:port pair will continue to be reused. Or, until the connection times out and the server sends back a TCP-RST. Only then the session handling will be renewed.

On top of this, applications servers and frameworks also may hold their own session state.

So basically, as long as you do not reset the connection the tcp, http and higher session states will remain intact. It is (highly) dependent on your specific set-up and configuration in place.

You should write some code to validate what is actually happening.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .