False positives from PSAvoidUsingInternalURLs

[KirkMunro]

I have a module to manage the DigitalOcean cloud service. All calls to DigitalOcean are made via REST endpoints using fully qualified URLs. No internal URLs are being used. Yet when I run PSScriptAnalyzer against my module, it generates 15 false positives that shouldn't exist.

The false positives all come from the string '/$1'. That is a single quoted string that I use as the second parameter when using -replace with other strings, to ensure that those strings are properly prefixed with /. This generates the relative URIs that I need that then internally are used to generate the absolute URIs that are needed to make the REST API call. Here's an example:

        $internalId = $Id -replace '^([^/])','/$1' -as $Id.GetType()

There is nothing in that command that should cause this warning to appear.

I'm not exactly sure where the error is here, but this is definitely a bug. I don't think PSAvoidUsingInternalURLs should even be looking at a replacement string in a regex -replace call. But that may not be the core issue here.

You can install my DigitalOcean module by invoking Install-Module DoPx and then run Invoke-ScriptAnalyzer against it to see these false positives. Note: it takes about two minutes to process this module, even though it is small, so please be patient while analyzing it and store the results in a variable so that you don't have to do it again.

[dantraMSFT]

I see the same false warning flagged for format strings passed to String.Format; Here's a simple repro:

$msg = [System.String]::Format("1:{0}", "test")

[kilasuit]

This is still throwing issues for file paths like C:\Windows\System32\WindowsPowerShell

Perhaps it should do an initial check to see if it is a Filepath before testing if it is a URL?

[Jaykul]

The whole implementation of this rule is just WRONG.

First of all, there's nothing inherently wrong with "internal" URLS unless the script is being published to a public script gallery.

Second, most strings are not URLs. You shouldn't be tripping on regexes and file paths.

Third, relative paths are ok when they're really paths to files that are part of the module or inherently part of windows.

It appears that the current implementation of this just looks for ANY STRING with a colon or a slash in it, and warns ....

MOST IMPORTANTLY: Rules like this should never have made it into the defaults of a public official release, it's a sign of terrible release planning, and poor quality control.

[raghushantha]

Thanks for the feedback. Investigating to see how we can make this rule less noisy

[raghushantha]

Deprecating the rule - considering the noise and lack of usefulness
#389