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. 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. 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? >> 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. Thanks -- Deron Meranda -- 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.
