Enable importing a remote resource from a private WMS service

[sijandh35]

Description

Currently, the GeoNode API supports the upload/import of a remote resource from an external WMS service (e.g., GeoServer). If the service is already registered, it retrieves the harvestable resources from it; otherwise, it creates a new remote resource from the external service.

The corresponding issue is available here

An request example is presented below:

curl --location 'http://localhost:8000/api/v2/uploads/upload' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer <token>' \
--data '{
    "url": "https://<domain>/geoserver/wms",
    "title": "Remote WMS Test",
    "type": "wms",
    "identifier": "xxxx",
    "parse_remote_metadata": true,
    "action": "upload"
}'

However, this functionality does not support importing resources from private WMS services that require authentication.

Proposed solution

To address this limitation, the functionality will be extended. In the case of a private WMS service, the following steps will be added to the current workflow:

• check if the private WMS service is registered in GeoNode as a service (harvester) triggered by the request
• If yes, retrieve the credentials internally and import the resource into the GeoNode catalog (equivalent to triggering “import resource” / harvest via the UI)
• If not, the request is refused.

[giohappy]

@sijandh35 I think you missed one point.

There are two distinct aspects to handle.

1. If the WMS layers can be connected to an existing service, it will be registered as a harvestable resource. This is already covered, nothing to do here.
2. Authentication: If the connected service has a connected AuthConfig, the same config ID will be assigned to the new WMS resource, UNLESS the WMS upload has basic auth credentials inside the request payload. In this case these will be used to record a new AuthConfig, which will be assigned to the resource. This allows registering single private WMS resources, even without a connection to a remote service

The only shortcoming we have so far is in case the Remote service doesn't have credentials assigned. A new WMS resource is registered, and then credentials are assigned to the Remote Service. In this case, the WMS resource doesn't reference the new config.

An option could be to automatically assign the new Remote service auth config to any remote resource connected to its harvestable resources. But I would leave it as an additional improvement, outside this issue.

[sijandh35]

@giohappy PR merged.