Use a more general (and faster) method to sanitize URLs with credentials

[wxiaoguang]

As discussed in

• Hide sensitive content on admin panel progress monitor #19218

We can use a more general (and faster) method to sanitize URLs with credentials

Benefits:

• Simple and intuitive
  • before: util.NewStringURLSanitizer(opts.Remote, true).Replace(opts.Remote)
  • now: util.SanitizeCredentialURLs(opts.Remote)
• For errors:
  • before: get a remoteAddr; util.NewURLSanitizedError(err, remoteAddr, true)
  • now: util.SanitizeErrorCredentialURLs(err)
• Faster, fast return when no credential, one time allocation for a bytes buffer for most cases.
• The new implemention can remove all credentials in all URLs, while the old one could only remove the only one targeted URL.

[lunny]

We still need this normal cases.

[wxiaoguang]

Which case? I think I have covered most.

[lunny]

I mean why we delete these original test cases?

[wxiaoguang]

All code are rewritten, all new cases cover old ones. If you feel which is missing, please just point out and add it.

[wxiaoguang]

And many cases are indeed the old cases, for example, these github.com cases.

[Gusted]

Seems okay... The current code seems to be indeed faster:

BenchmarkNew-12          3575206               368.0 ns/op           320 B/op          2 allocs/op
BenchmarkOld-12           373596              2956 ns/op            3288 B/op          9 allocs/op

A relative minor issue that comes with this, is that the current code will "handle" URL's like ://@ into -> ://sanitized-credential@ whereby the old function would return a error that it is a incorrect URL, but like I said relative minor issue.

[wxiaoguang]

Seems okay... The current code seems to be indeed faster:

BenchmarkNew-12          3575206               368.0 ns/op           320 B/op          2 allocs/op
BenchmarkOld-12           373596              2956 ns/op            3288 B/op          9 allocs/op

A relative minor issue that comes with this, is that the current code will "handle" URL's like ://@ into -> ://sanitized-credential@ whereby the old function would return a error that it is a incorrect URL, but like I said relative minor issue.

Thank you for the benchmark!

In my mind the major purpose is to make code more simple and intuitive, the performance is just a bonus.

And the edge case ://@ is fixed now, the minimal pattern is "s://u@h" now

[Gusted]

Why the skip-changelog?

[wxiaoguang]

Why the skip-changelog?

this PR is just a refactoring, it doesn't change the expected output, and doesn't improve performance obviously (because the sanitizer isn't called too much), so I think it's not necessary to mention it in the changelog, it doesn't provide useful information to end users.

feel free to adjust the labels.

[zeripath]

This code only removes the credential from the first URL it finds in the string

If we want to strip out credentials from all urls in the string we're gonna need to do something else. (Possibly iterate across all "://" in the string however see below...)

One other issue is that there are URLs which do not have the ":", for example //username:password@www.google.com which says use the current protocol. I think /\username:password@www.google.com also works.

IMO I don't think we need to necessarily sanitize these - we should probably just make it clear that we're not going to do this.

[wxiaoguang]

OK, I will add it to comment. IMO "//xxxx" couldn't be treated as a valid URL in strings. It's only valid in a context with scheme already (say, inside a browser)

And /\ is not standard, it's just a browser's dirty hack. Golang's url.Parse doesn't support /\ either.

[wxiaoguang]

Suggested change

	// SanitizeCredentialURLs remove all credentials in URLs for the input string: "https://user:pass@domain.com" => "https://sanitized-credential@domain.com"
	// SanitizeCredentialURLs remove all credentials in URLs (starting with "scheme://") for the input string: "https://user:pass@domain.com" => "https://sanitized-credential@domain.com"

[wxiaoguang]

"This code only removes the credential from the first URL it finds in the string"

No, it removes all. See the test case

		{
			"URLs in log https://u:b@h and https://u:b@h:80/, with https://h.com and u@h.com",
			"URLs in log https://" + userPlaceholder + "@h and https://" + userPlaceholder + "@h:80/, with https://h.com and u@h.com",
		},