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 :
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