On 19 March 2010 03:14, Deron Meranda <[email protected]> wrote: > On Thu, Mar 18, 2010 at 5:41 AM, Graham Dumpleton > <[email protected]> wrote: >> On 16 March 2010 04:15, Deron Meranda <[email protected]> wrote: >>> Yes. However the authn/authz hooks only get invoked when one >>> also uses the Apache Require directive. [...] >> >> It is not that simple. I think the thing many missed was that you >> aren't restricted to the standard require arguments. The whole point >> is that you can define your own arguments for require which your >> authorisation handler would interpret. > > No, this flexibility was not at all obvious to me, and I still don't > know exactly how it works. I did try to use the authn/z handler > phases, but could never get them to work right; probably because > I just didn't know what I was doing. > > It doesn't help that the Apache document can be rather poor > in places. For example, the Apache 2.2 API docs, > http://httpd.apache.org/docs/2.2/developer/API.html > have a big box at the top that effectively says this hasn't really been > updated much since 1.3 ! How useful. I've had to do quite a bit of > code diving into the sources for httpd just to learn some things > I needed to know. But that's not your responsibility. > > > Anyway, I had essentially invented my own "require" mechanism, > by using something like: > > PythonOption Require XXXX > > along with a PythonAccessHandler. Though what I have is not > nearly as simple as just users or groups, my ACLs can get > pretty involved.
One problem even if were to support non content Apache phases is that don't have an equivalent to PythonOption directive for mod_wsgi. One can use SetEnv, but that isn't the same and is just adding stuff to req.subprocess_env, but that addition of them to that table is only done by mod_env in the fixups phase, after the aaa phases. This wouldn't be an issue if using Requires directive properly, but then there still may be valid reasons for having a means of specifying configuration to a custom phase based on context in Apache configuration. I am really not sure how to handle this as yet. One could have a WSGISetExtendedEnv directive which parallels SetEnv with any variable still ending up in the environ dictionary in WSGI but which takes precedence for content phase. Also, although one can put them in 'environ' for aaa providers in mod_wsgi if using WSGI style provider, but in both provider of phases, if you have Apache interface where request_rec wrapper is passed, where do you supply it. In mod_python you could use req.get_options(), but I don't want to start adding additional stuff to the request_rec wrapper and want to be as close as possible to intent of original C version. The only tables in request_rec for key/value sets are req.subprocess_env and req.notes, neither of which is really appropriate in my mind. In C Apache modules the equivalent to this problem is the custom directives the modules provide. For those they are stored in a custom data structure and there are all sorts of merge functions that need to be provided to merge them from different contexts in hierarchy to arrive at the per request configuration. This configuration is accessed using: ap_get_module_config(r->request_config, &wsgi_module); where 'r' is request_rec and 'wsgi_module' is the Apache modules definition structure instance. Since that function can't really be used directly in Python code, one could override its used in custom phase handlers such that doing equivalent from Python world would return a Python dictionary. Thus, if had WSGISetExtendedEnv it could stash values in that dictionary. Being a Python dictionary, although the initial values would be string pairs, in the phases you could stack arbitrary Python objects in there. Thus could serve same purpose as adding extra stuff to request object itself like in mod_python. A problem with this though if allow arbitrary Python objects and not just strings, is that different phases could be executed in context of different interpreters within process. This opens up evil whole of sharing objects between interpreters which might be okay for integral data types, but not high level data types. This was also an issue with mod_python that don't think anyone realised as the request object was cached and if phases got implemented in different interpreters, could get this cross interpreter object sharing. So, it is a bit of a tricky problem as to how to handle passing data between phases but also form configuration file itself. > Also, sometimes, the access control decisions being made > were not just a simple yes or no (the no's resulted in > HTTP 403 Forbidden), but the middle-ground "partial" answers > would result in additional information being passed up to the > content handler, where it could then alter, slightly, how it behaved. > > For me, the authentication portion of my access handler is pretty > simple and small (that is, checking the authentication since I base > it on encrypted cookies which are easy to validate. .... though the > act of "logging in" and creating the cookie to begin with is quite > more involved.) Most of my Access handler is actually doing lots > of access control (authorization) decision making tasks, as well > as initializing many python objects. > > >>> Oh, I should mention that I've also used stacked handlers >> >> Do you use stackable handlers in non content handler phases? > > No. I played with it a bit, but don't actually use stacks in the > other phases. > > I do have a few handler stacks in the content phase; but actually > after looking at it again I'm not really doing all that much with > them any more as much as I used to. I've restructured my own > frameworks over the years, and I could easily enough now get > rid of all my uses of stacked handlers. > > It was certainly a neat capability, but I guess that sort of thing > has now been pushed up into the python dispatcher frameworks > (or even by nesting WSGI protocols), and away from the lower-level > concepts in Apache. > > >>> I also in a few cases have used mod_python's multiple >>> interpreter feature; [...] >> >> You actually have better control over sub interpreter usage in >> mod_wsgi than you do in mod_python > > As I've started playing with mod_wsgi, I've noticed that. > I'm sure I have even more nice discoveries ahead of me. > > >>> Great, I already do use req.subprocess_env for a little bit now; >>> though most of my complex objects just get stuffed into the req >>> object directly as additional non-standard members. I assume I >>> don't need to touch the apswigpy to continue to use the >>> subprocess_env, do I? >> >> If wanting to set it from WSGI, yes you do, as WSGI interface doesn't >> give any access to original Apache request object. It is a special >> extension of mod_wsgi that allow a Python CObject reference to be >> passed as part of environ dictionary. This CObject reference could >> then be used to construct Python wrapper for request object using >> apswigpy. >> >> If you are talking about whether setting env variables in mod_python >> will show up in WSGI, then no, that doesn't require apswigpy. > > Oh, okay. That's a little messy, but it does make a bit more > sense. > > It was just so convenient to be able to have the mod_python > req object that mapped so tightly to the internal Apache request, > and yet that could be poked and prodded pretty much any way > you wished. And which survived throughout the entire life cycle > of the request and could be accessed by all the phases. But as I said could also be dangerous phases operated in different interpreters, because of cross interpreter object sharing, something which is a bit of a no no. > I guess, for me, if I can't actually share the exact same python > objects in the same interpreter; then my data passing would only > need to be one way. So I may be able to avoid apswigpy > for now. > > I really need to take an inventory of all the different things I do > with the req object, and see what is going to survive in WSGI > and what won't. > > You're not aware of any documentation on how to migrate > from mod_python to mod_wsgi that I may have missed, are > you? I have not produced anything. There have been some on list who have been trying to write a compatibility layer so one still gets a mod_python type request object on top of mod_wsgi. >>> Also, this may be more of a question for the mod_python list, >>> but since the development of mod_python is pretty much in a >>> stable leave-it-alone mode [...] >> >> It is extremely unlikely that mod_python will be changed and there is >> some discussion in ASF at the moment as to whether it be shifted into >> the ASF Attic. This will effectively mark it as dead unless a saviour >> comes along and later resurrects it, at which point I believe it has >> to go back through the ASF Incubator program before it can be >> reestablished as a main project. >> >> As it stands, mod_python will not I believe compile on Apache 2.3/2.4. >> It certainly isn't going to work with Python 3.X. I am not even sure >> for mod_wsgi what is going to happen with SWIG bindings for Apache API >> under Python 3.X as don't know how SWIG works under that, but WSGI >> parts of mod_wsgi already work on Python 3.X. > > Oh. That may really change how I approach things. If the > future of mod_python is uncertain, then perhaps its time to > start planning life without it. > > Even if I pulled out as many of the mod_python features as I could > (stacked handlers, low-level req structure access, etc.) and moved > it all inside a standard-ish WSGI application; I would still need > some ability to hook into Apache at a pre-content phase (whether > that's authn/z or access). > > I'm dependent upon customized access control logic that needs to > get called, even for web content that itself may not even come > from python code at all. Thus I can't just push all this into a > WSGI application or framework. > > It would be a shame if we lost any way to write these other non-content > phase Apache handlers in Python, and have to go back to writing C code. > > >> Anyway, I have been having a good think about some things at the >> moment and maybe I might surprise you with some things to try. If you >> can answer the one question for me about what you use stacked handlers >> for and for which phases, will help with one thing I am looking at. > > I'm certainly eager to hear ideas and provide feedback. > > I've got a large complex system built up on mod_python, and it > works great. But, I guess like most technology, things move on. > So if the future of mod_python is dim, I need to start trying > to figure out how to unwind all those dependencies. I am still contemplating various things and not much time to write actual code, so I'll have more to say about all this another time when have worked out what to do. Graham -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en.
