The patch I have does not modify the existing password support - so when you pass in username/password to the openURL function, a new OpenerDirector is created, configured and used for that one request and immediately thrown away, ignoring the new "opener" field I have added to the various OWS client classes. I'll try and unify these for the final patch, now that I've gotten some feedback on the approach I've chosen.
-- David Winslow OpenGeo - http://opengeo.org/ On Tue, Apr 26, 2011 at 10:45 AM, Dominic Lowe <[email protected]>wrote: > Hi David, > > I'd be very happy to see that patch - I'm sure there are other > circumstances when cookies would be useful in OWSLib. > > Am I right in thinking your current patch does not support http > password/username logon? I think that's pretty important to maintain as that > was a requirement from some other users. > > Otherwise I'm pretty happy for you to suggest a patch. Tom Kralidis may > have more comments as he has been most active on OWSLib recently. > > Regards, > Dominic > > > > On 25/04/11 19:07, [email protected] wrote: > >> Hi all, >> >> I work on GeoNode (http://geonode.org/). We're using OWSLib to fetch >> data from GeoNetwork. Recently I've discovered that due to the way >> GeoNetwork handles sessions, it makes a big difference for us to include >> HTTP cookies on our service requests (without them, GeoNetwork creates a new >> session for each service request and eventually locks up after running out >> of RAM.) >> >> Therefore I would like to modify owslib to use a (persistent) instance of >> urllib2.HTTPCookieProcessor when opening URLs, one which I can get a >> reference to so that I can log in to GeoNetwork and have owslib use the >> session cookie. Ideally, there would be a way to provide my own instance of >> urllib2.OpenerDirector which I can customize as needed. >> >> I am currently using a monkey patch to fix this behavior, but it's not the >> way I'd like to do things (you can see the diff in GeoNode here: >> https://github.com/dwins/geonode/compare/master...csw-cookies ). >> >> For a deeper fix I see basically 3 options: >> >> 1) Use Python's urllib2.install_opener to set a default opener instance to >> use, and be careful not to pass arguments into owslib methods that would >> cause them to create their own openers (for example, including a username >> and password in a call to owslib.util.openURL). >> 2) Create a module-level variable (owslib.util.opener) and modify >> owslib.util.openURL and owslib.util.http_post to reference it exclusively. >> Then client code which needs to modify the HTTP handling behavior can >> simply replace this variable. >> 3) Make each client class (ie, owslib.csw.CatalogueServiceWeb) use its own >> opener instance which may be provided by client code. >> >> The attached patch is a partial implementation of approach #3. (In each of >> these cases there is the question of how to handle the username/password >> arguments to owslib.util.openURL, I haven't addressed this.) >> >> Is this sort of thing something the OWSLib community would be interested >> in incorporating? If so I'm happy to update this patch to incorporate >> feedback etc. >> >> -- >> David Winslow >> OpenGeo - http://opengeo.org/ >> >> > -- > Scanned by iCritical. > _______________________________________________ > Community mailing list > [email protected] > http://lists.gispython.org/mailman/listinfo/community >
_______________________________________________ Community mailing list [email protected] http://lists.gispython.org/mailman/listinfo/community
