[Community] cookies and OWSlib

[Dominic Lowe]

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, dwinslow at opengeo.org 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.