fix: decode special characters in proxy username and password

[B4nan]

When using newProxyInfo function, the username and password extracted from proxyUrl are now properly decoded.

https://apify.slack.com/archives/C0L33UM7Z/p1727966399183259

[barjin]

The changes seem safe enough to me, so feel free to merge.

My question is: do we know the actual mechanism of where the bug (from the Slack thread) is originating? I cannot find a single use of proxyInfo.username or .password in Crawlee codebase (we always just parse it from the URL with decodeURIComponent).

[barjin]

Btw. if somebody is expecting the username and password to be percent-encoded in their user code (e.g. reading it from context in a router), this could cause issues for them (decodeURIComponent is not idempotent - e.g. %25zzz decodes to %zzz, which is not a valid percent-encoded string, i.e. another decodeURIComponent call will throw).

[B4nan]

My question is: do we know the actual mechanism of where the bug (from the Slack thread) is originating? I cannot find a single use of proxyInfo.username or .password in Crawlee codebase (we always just parse it from the URL with decodeURIComponent).

I guess some custom handling, I am also not entirely sure. I would guess they work with the response of newProxyInfo directly. Also I just noticed we have the very same problem in the SDK.

https://github.com/apify/apify-sdk-js/blob/master/packages/apify/src/proxy_configuration.ts#L267

Btw. if somebody is expecting the username and password to be percent-encoded in their user code (e.g. reading it from context in a router), this could cause issues for them (decodeURIComponent is not idempotent - e.g. %25zzz decodes to %zzz, which is not a valid percent-encoded string, i.e. another decodeURIComponent call will throw).

Yes, if someone was too lazy to report a bug and instead implemented a workaround without telling us, their code will break. Not much we can do about that, to me this is a clear bug.

[B4nan]

Btw. if somebody is expecting the username and password to be percent-encoded in their user code (e.g. reading it from context in a router), this could cause issues for them (decodeURIComponent is not idempotent - e.g. %25zzz decodes to %zzz, which is not a valid percent-encoded string, i.e. another decodeURIComponent call will throw).

Also note that this is inconsistent with the SDK, if you use the proxy config password option, there is no encoding, if you use a proxy URL with the password, it will be encoded. This only confirms that we really should fix it.

I asked for more details about the actual problem, but we should do this regardless of that I'd say.