Error if installed plugin is inside plugins folder

[mamazzol]

If a non directory file is in the plugins folder during installation, there will be a non descriptive error during findBundle, as it assumes everything is a directory. This new preemptive check adds a descriptive error message to avoid this scenario.

Also, for consistency and to not use a deprecated URL constructor, in the download method we now use URI.

Closes #27401

[elasticsearchmachine]

Pinging @elastic/es-core-infra (Team:Core/Infra)

[elasticsearchmachine]

Hi @mamazzol, I've created a changelog YAML for you.

[mark-vieira]

FWIW, is there a reason this isn't allowed? Did we consider simply removing this limitation?

[rjernst]

is there a reason this isn't allowed?

We want to maintain control of what is in the plugins directory. Otherwise we would have to have leniency that could hide an error (eg broken plugin installation, looks like the plugin is there but it's not complete, etc)

[mamazzol]

FWIW, is there a reason this isn't allowed? Did we consider simply removing this limitation?

At the moment it's stopped by the "bug/feature" present here.

findPluginDirs will interpret everything in the plugins directory as another directory, so when the readPluginBundle tries to read properties file from the zip, it fails. This acts as a block for unrecognised things in the plugins directory and the user will get a message like "random-uuid has no properties file".

Perhaps findPluginDirs could validate the retrieved folders in some way and throw otherwise? Or are we happy with the existing behaviour?

[mark-vieira]

Perhaps findPluginDirs could validate the retrieved folders in some way and throw otherwise? Or are we happy with the existing behaviour?

Sounds like we want to keep the existing behavior of preventing folks from installing plugins located inside the plugins dir.