webapp2 sessions integration with protorpc (python 2.7, appengine 1.7.0)

[Gregory Nicholas]

from my research trying to integrate the source code from some of the webapp2 wsgi application model and protorpc service handlers, i can see why rodrigo dropped the task of keeping support of protorpc back in webapp2 v2.4..

particular design choices that seem to cause the main challenges (scoped to wsgi, and please, please, expand or correct me if i am wrong):

on the service handlers:

• the state of the request is limited to only information about the incoming httprequest: remote_host, remote_address, headers, etc.
• that httprequest information is also read only from within the service handler.
  
• so.. for modifying headers? must be done at the application middleware level..

on the design of the application middleware:

• the application module is completely unaware of the current request object
• very much unlike webapp2's ability to maintain a global to the current request object
• the entire request is executed from within a single closure on wsgi.service.service_mapping
• there are no hooks, or ability to wrap certain execution of the code (something similar to the dispatch method in webapp2)

in trying to follow a small snippet from rafe: https://groups.google.com/forum/?fromgroups#!msg/google-protorpc-discuss/GHJAwtFX_nY/I0H0M1aNUVoJ, and given some of the challenges, i'm coming up a bit short on next steps.. thoughts? suggestions?

[Rafe Kaplan]

What is the purpose of this integration? Have you looked at the
standard wsgi handlers?

protorpc.wsgi.services

The information in the request object that is attached to the handler
is meant to be read-only. There is not a way to change the ProtoRPC
response headers. If you do need to make changes to the header you
should wrap the ProtoRPC wsgi handler using a wsgi middleware.

--
- Rafe Kaplan

[Gregory Nicholas]

i have been using RPC for some unauthenticated endpoints, which my frontend pings. after some time working wit it,  i'm looking to move all of my ajax based handlers to my RPC layer.. however, most of them will require session access. 

i'ts unclear to me however,  to pass data between the protorpc.remote.Service classes that handle a method back to the middleware wrappers..

maybe there is a better way to approach this?

[Rafe Kaplan]

In truth, we have yet to develop solutions to some of the problems
you are raising.

With regards to authentication, if you are running on a system like
App Engine, and use it's authentication system (which admittedly, many
do not) you can get authentication information via the users module.
This means authentication is very separate from ProtoRPC.

I've had ideas about how to support arbitrary authentication
systems, for example, by introducing an arbitrary "user" field to the
RequestState object. This would enable some kind of middleware to
perform auth and pass it through.

A not-so-great solution that I can think of, but one that you can
get working quickly, is that it's safe to use thread-local variables
in a middleware handler. It works something like:

# At top level of a module.
shared = threading.local()

def session_middleware(...):
shared.session = load_session()
...
DO REQUEST
...
store_session(shared.session)

In the handler:

@remote.method()
def my_remote_method(self, request):
session = shared.session
...

--
- Rafe Kaplan

[Gregory Nicholas]

what about mixing in a threadsafe dict that would be allowed for storage through the life of the request? something similar to registry dict rodrigo setup here: http://code.google.com/p/webapp-improved/source/browse/webapp2_extras/sessions.py

also, i think i have something working, by porting a bit of code out of the library: https://github.com/sgammon/apptools/tree/master/services

give it a quick scan, i'm curious to hear your thoughts.. i spent the last two days (cranking through my adderall supply) essentially refactoring some of that and http://code.google.com/p/webapp-improved/source/browse/webapp2_extras/protorpc.py?name=2.3 into my own project.. looks like apptools was in part inspired by rodrigo's prior support, but try to look past the mangling sam gammon did with a much larger "platform" project..

-- Cheers, and thanks for the prompt replies!

- Gregory nicholas