[receiver/sqlquery] Interpolating from a provider can lead to unescaped characters in datasource URL

[braydonk]

Component(s)

receiver/sqlquery

Is your feature request related to a problem? Please describe.

If you have a datasource URL where you want to embed a secret like ${env:PASSWORD}, if that embedded password has URL-unsafe characters there is no way for them to be escaped.

Describe the solution you'd like

A config option like url_encode_datasource (name up for debate) that will URL encode the resulting datasource before creating a NewPool. Correctly noted below that this solution is infeasible. I've adjusted the description and removed the feature request. This needs a deeper solution.

Describe alternatives you've considered

No response

Additional context

My silly reproduction is as follows:

Patch:

diff --git a/receiver/sqlqueryreceiver/receiver.go b/receiver/sqlqueryreceiver/receiver.go
index 54f0834b2b..50955fba4d 100644
--- a/receiver/sqlqueryreceiver/receiver.go
+++ b/receiver/sqlqueryreceiver/receiver.go
@@ -6,6 +6,7 @@ package sqlqueryreceiver // import "github.com/open-telemetry/opentelemetry-coll
 import (
        "context"
        "fmt"
+       "log"
 
        "go.opentelemetry.io/collector/component"
        "go.opentelemetry.io/collector/consumer"
@@ -39,6 +40,7 @@ func createMetricsReceiverFunc(sqlOpenerFunc sqlquery.SQLOpenerFunc, clientProvi
        ) (receiver.Metrics, error) {
                sqlCfg := cfg.(*Config)
                var opts []scraperhelper.ControllerOption
+               log.Fatal(sqlCfg.DataSource)
                pool := internal.NewPool(sqlOpenerFunc, sqlCfg.Driver, sqlCfg.DataSource, sqlCfg.MaxOpenConn)

Config:

receivers:
  sqlquery:
    collection_interval: 60s
    datasource: oracle://sys:${env:PASSWORD}@myhost.domain:1111
    driver: oracle
    queries:
    - metrics:
      - attribute_columns:
        - DATABASE_ID
        - GLOBAL_NAME
        - TABLESPACE_NAME
        - CONTENTS
        data_type: sum
        description: The size of tablespaces in the database.
        metric_name: oracle.tablespace.size
        monotonic: false
        static_attributes:
          db.system: oracle
          state: free
        unit: by
        value_column: FREE_SPACE
        value_type: int
      sql: "Robert); DROP TABLE Students;"

exporters:
  nop:

service:
  pipelines:
    metrics:
      receivers: [sqlquery]
      exporters: [nop]

Result:

braydonk@bk:~/Git/opentelemetry-collector-contrib$ PASSWORD="my&p|a/s@s" ./bin/otelcontribcol_linux_amd64 --config config.yaml
2025-05-16T13:13:09.923Z        info    service@v0.126.1-0.20250515040533-97a6accbc082/service.go:199   Setting up own telemetry...     {"resource": {}}
2025/05/16 13:13:09 oracle://sys:my&p|a/s@s@myhost.domain:1111

[github-actions]

Pinging code owners:

• receiver/sqlquery: @dmitryax @crobert-1

See Adding Labels via Comments if you do not have permissions to add labels yourself.

[XuechunHou]

I can pick this up. Thanks

[quentinmit]

The password needs to be URL-escaped before it is interpolated. If you URL-escape the entire URL you will also escape @, /, etc. and will completely break the URL.

Perhaps the best way to handle this is to introduce a new secret provider called uriescape, so the user could use ${uriescape:env:PASSWORD} if they have a string that needs escaping. Or they can just put an escaped string into the environment variable.

[jinghan-ma]

I do agree that the "ideal" solution is to have a way to have a sharable component that can be called to URL encode or escape sections of the configuration. We'll need to figure out if these providers can be nested though (i.e. apply the uriescape provider to the output of another provider)

From a "where this belongs" perspective, I think it's closer to the sql receiver than the secret manager. This escaping issue is not specific to the case of wanting to use the secret manager. It also applies to using env variable (in the example Braydon provided), or any other provider in the future.

The sql receiver also knows exactly what type of escaping it needs to do (in this case URL encoding).

[quentinmit]

This isn't a question of the "ideal" solution - the proposed solution here can not work. Once the string is already concatenated into a single URL, it's no longer possible to know which part of that string needs encoding applied to it.

The only way to fix this is to perform the encoding upstream of the SQL receiver. I'm not suggesting it should happen in an existing secret provider - it needs either a new secret provider, or a change to how secrets are interpolated, or just the user needs to put a pre-encoded string into their secret.

[VihasMakwana]

+1 @quentinmit.

[braydonk]

I've adjusted the title and description of the issue to reflect that my initial idea was infeasible.