Automatic Image Downloads from URLs Overwrite One Another

[antoinne85]

Describe the bug
When performing an image replacement using a URL, Nexrender automatically downloads the image, but makes some assumptions about filename that can cause undesired output.

Information about environment

• Which version of nexrender are you using? v1.48.5
• What kind of the setup do you have? (server+worker or cli) Invoking the CLI locally (or through server/worker) through a .NET app.
• Are you using pre-built binaries or globally installed npm packages? Pre-built binaries.
• Which kind (and version) of operating system you are running it in? Windows 11
• Any additional information that might be helpful

In my testing, I tried v1.60.9 as well and I believe I saw it there, too.

But what I think is really going on is a kind of niche use case, but it could happen in others, I suspect.

We've got two layers LayerA and LayerB that are both getting their images replaced like so...

{
    ...
    "assets":
    [
        ...
        {
            "layerName": "LayerA",
            "src": "https://drive.google.com/uc?id=FILE_ID_ONE&export=download",
            "type": "image"
        },
        {
            "layerName": "LayerB",
            "src": "https://drive.google.com/uc?id=FILE_ID_TWO&export=download",
            "type": "image"
        }
        ...
    ]
    ...
}

What seems to be happening is that when the assets are automatically downloaded, they're both getting downloaded with the name uc.png, presumably because that's the last path segment. Presumably this could also happen if you were using URLs like https://site.com/images/small/logo.png and https://site.com/images/large/logo.png—they'd both get downloaded as logo.png and the same logo would get used when the user expected two different ones.

If you need to generate one of these Google Drive URLs, you can upload any image to Google Drive, change its sharing settings to make it publicly available to everyone, then copy the sharing link. Once you've done so, you replace /file/d/ with /uc?id and replace /view?usp=sharing with &export=download.

Expected behavior
Regardless of whether or not two images have the same file name, the correct replacements should occur.

Screenshots
None, unfortunately. But probably not necessary in this case.