Geoserver/Geonode endpoints via Girder plugin

[mbertrand]

@aashish24 Current endpoints for a typical geonode installation:

• WMS: http://<geonode_url>/geoserver/wms
  • GetCapabilities
  • GetFeatureInfo
  • GetMap
  • Filters and other parameters
  • etc
• WFS: http://<geonode_url>/geoserver/wms
  • GetCapabilities
  • GetFeature
  • etc
• WPS: http://<geonode_url>/geoserver/wps
• WCS: http://<geonode_url>/geoserver/wcs
• Geoserver REST API : http://<geonode_url>/geoserver/rest
  • For uploading and other admin functions:
  • Note: this endpoint requires admin authentication

[aashish24]

WMS: http://<geonode_url>/geoserver/wms

GetCapabilities
GetFeatureInfo
GetMap
Filters and other parameters
etc

Sounds good. Can we have:

• http://somethinghere/geo/wms --> internally forwarded to http://<geonode_url>/geoserver/wms
• http://somethinghere/geo/wfs --> internally forwarded to http://<geonode_url>/geoserver/wfs
• http://somethinghere/geo/rest --> Upload data + admin functionality

I think these three would be good enough for now.

[mbertrand]

@aashish24 in terms of authorizing geoserver proxy requests, I can think of a few options, let me know which you prefer:

1. Set a username and password in the gaia configuration file that will be used for authenticating all proxy requests (should be an admin user for REST requests). Advantage: does not require any knowledge or action on part of the user for providing credentials. Disadvantage: allows any user to potentially abuse the admin capabilities of the Geoserver instance.
2. Do not set any specific user and password by default. Instead leave it up to the main application/UI to handle this, such as providing a form for entering these values, then including them as a base64 Authorization in the request header sent to Gaia. Advantage: most secure option. Disadvantage: More work for the UI application (provide the form, process the input, send to Gaia with the modified headers).
3. Allow username and password parameters in the URL request (http://mygirder/geo/rest/wms?request=GetCapabilities&username=admin&password=mypassword). Advantage: user can enter credentials (if known) without the need for a UI. Disadvantage: Less secure due to credentials being in the URL itself.

[aashish24]

Do not set any specific user and password by default. Instead leave it up to the main application/UI to handle this, such as providing a form for entering these values, then including them as a base64 Authorization in the request header sent to Gaia. Advantage: most secure option. Disadvantage: More work for the UI application (provide the form, process the input, send to Gaia with the modified headers).

I would prefer 2) Since the authorization will be maintained by something else. at this this point we don't have how that's going to work. So leaving it open to application or third party seems most viable to me.

[mbertrand]

Pushed a new branch: https://github.com/OpenDataAnalytics/gaia/tree/geoserver_proxy

• Handles GET, POST, and PUT requests
• Geoserver base url is specified in config file
• Authentication is left up to the user/developer (ie adding Authorization header).
• Base url is http://mygirderdomain/geo, but enabling minerva will shift this to http://mygirderdomain/girder/geo.
• This should handle any geoserver URL that is accessible via GET, POST, or PUT: WMS, WFS, WCS, WPS, REST, etc.
• I'll make a PR request soon after doing some more testing.