blob/azureblob: validate URL endpoint overrides

[huynhtrungcip]

This change restricts endpoint overrides supplied through azblob:// bucket URLs.

domain URL overrides are now limited to known Azure Blob service domains, and protocol=http is rejected in bucket URLs. Custom endpoints and local emulators remain configurable through trusted ServiceURLOptions or environment configuration instead of URL query parameters.

The patch also updates the Azure Blob URL example and regenerated website example data.

Tests:

• go test ./blob/azureblob -count=1
• go test ./blob/... -count=1
• (cd internal/website/gatherexamples && go test -count=1)
• internal/website/gatherexamples/run.sh | diff -u internal/website/data/examples.json -

[vangent]

Can you explain why you think this change is needed?

[huynhtrungcip]

Thanks for taking a look.

The reason for this change is that the registered azblob:// opener combines endpoint selection from the bucket URL with credentials loaded from the environment/default Azure configuration.

Today, if an application accepts or composes an azblob:// URL from lower-trust configuration, the URL can set domain and protocol while the opener still applies credentials from AZURE_STORAGE_SAS_TOKEN, shared key, or default Azure credentials. That means a bucket URL can choose the service endpoint that receives credential-bearing Azure Blob requests.

This PR keeps custom endpoints available through trusted ServiceURLOptions or environment configuration, but stops the bucket URL query string from selecting arbitrary service domains or downgrading the endpoint to HTTP. I used that boundary because blob.OpenBucket URLs are commonly treated as configuration strings, while ServiceURLOptions/environment setup is controlled by the application deployer.

I rechecked the patch locally:

• go test ./blob/azureblob -count=1
• go test ./blob/... -count=1
• go test ./... -count=1
• (cd internal/website/gatherexamples && go test -count=1)
• internal/website/gatherexamples/run.sh | diff -u internal/website/data/examples.json -

If you prefer a narrower compatibility-preserving approach, I can adjust the patch so the restriction only applies when the default registered opener is using environment/default credentials.

[vangent]

I'm not sure I'm convinced this belongs here.

If applications are accepting arbitrary config URLs and passing them to this library, they can/should do some verification of them before that. I would expect most applications to have control over both the configuration and the environment.

[vangent]

In particular, I don't like hardcoding the list of valid domains; this seems fragile and doesn't belong here.